Login | Register   
RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX

By submitting your information, you agree that devx.com may send you DevX offers via email, phone and text message, as well as email offers about other products and services that DevX believes may be of interest to you. DevX will process your information in accordance with the Quinstreet Privacy Policy.


Scalable Programs: Making and Using "Plug-ins" for Your VB Apps : Page 2

One common feature of professional, scalable programs is the ability to include a range of optional modules, or "plug-ins." This article demonstrates how you can include such functionality in your VB6 apps—using some clever thinking and some simple code.




Application Security Testing: An Integral Part of DevOps

The Steps to Modularity
To convert these two disparate programs into plug-in modules, consider precisely what the requirements are, then modify the original programs to conform to a consistent implementation of these requirements.

Say you had a generic program that could launch games—with no pre-determined knowledge of those games. What sort of information would it need to retrieve from the games? What sort of commands would it need to issue to the games?

There's no need to rework the games themselves in any way. There will be nothing different between the plug-in versions of the games and their stand-alone equivalents.

In this case, it seems self-evident that you'd want a method to play a game. You'll also want properties to return the name of the game and its version.

Assign names to these, as follows:

  • playGame: method to invoke the game, displaying its user interface
  • getName: property returning the name of the game
  • getVersion: property returning the version of the game
Now, convert the two stand-alone programs into plug-ins by changing them into ActiveX DLLs.

Figure 4: Create a new ActiveX DLL project.

Firstly, start Visual Basic. Elect to create a new project of type ActiveX DLL. Visual Basic brings up a blank class file, where it implements the methods and properties of the DLL. You're not rewriting the game, you're simply adding a front-end to it that adds extra facilities.

To inspect the existing code of the existing executable versions, click File/Add Project. Select an existing project, and open the Reversi.vbp project. Visual Basic sets up a project group in the IDE containing both the new and existing projects, simultaneously. That way, the existing code and filenames can be seen easily. You need to know the files that make up the game, and also where the entry point to the game is (that is, which is the main form, or where is the main subroutine).

Expand all the nodes in the project inspector so all the files of the Reversi stand-alone .exe project are listed.

Figure 5: Using a project group.

Right-click on the new project (Project1) and select Add Form and Add Module respectively, adding the existing form and module into this new project. One body of code is being used for both projects (and hence, should the game code be updated, then both projects benefit simply by recompiling).

Figure 6: Adding existing code to a new project.

It's important to put some consideration into your project's name, because the name given to the project and to the class are used to instantiate that class from another program.

For instance, if the project is called Project1 and the class Class1, as is the default, then another program would need to use code like so:

Dim obj as Project1.Class1 Set obj = new Project1.Class1

Another reason for careful name consideration is that a consistent naming scheme helps the main program determine just which DLLs belong to it and which do not.

Figure 7: Give the project sensible names.

Here, I've used a naming scheme where the plug-in modules go by the name GMgamename.Game—that is, the class is called "Game" for each ActiveX object, and the project is called GMgamename where "GM" might stand for "Game Manager."

Rename the project in this case to GMReversi and the class to Game, as illustrated in Figure 7.

Now, turn your attention to the class module to implement your methods and properties. These are all very simple:

Public Property Get getName() As String getName = "Reversi" End Property Public Property Get getVersion() As String getVersion = "Reversi v" & Str(App.Major) & "." & Str(App.Minor) End Property

The two properties—returning the Name and Version—should be read-only at runtime, so only implement the Get accessor methods. Omit the Let accessor methods that would otherwise allow a value to be assigned to the properties.

Public Sub playGame() frmXReversi.Show End Sub

Figure 8: Check the DLLs are registered with Windows.

There is absolutely nothing complex about this code. The playGame method simply invokes the main form for the game—just as if it had been the startup form as it is in the normal .exe file.

Click File/Make GMReversi.dll to build and compile the DLL. You've just made an ActiveX DLL containing a playable Reversi game.

Follow these very same steps again with the Breakout game. I've already produced the necessary code, available here.

Test to see if the ActiveX DLLs have been compiled correctly (and registered with Windows) by using the Project/References menu item.

Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date