Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

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

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.


advertisement
Coding the GameManager
Now, you need a generic program to find and make available these plug-in modules. This GameManager must, in some way, detect the DLLs available and make use of them so that the games can be played without the user having to be aware, in any way, of the underlying files.

Things have been made considerably easier by the consistent naming convention. Just search for plug-in files that match the pattern "GM*.dll." With all filenames that match, the program then tries to instantiate an object of the form GM*.Game. If this creates a valid object, then it is one of your plug-ins and you can assume the required functions—getName, getVersion, playGame—all exist.

Here's the code to achieve this:



Public colPlugIns As Collection Public Sub FindPlugIns(ByVal PlugInPath As String) Dim strFileName As String Set colPlugIns = Nothing Set colPlugIns = New Collection strFileName = Dir(PlugInPath & "\GM*.dll", vbNormal) Do While strFileName <> "" If PlugInExists(strFileName) Then colPlugIns.Add strFileName End If strFileName = Dir Loop End Sub Private Function PlugInExists(strFileName As String) As Boolean Dim strCreateString As String Dim vDummy As Object On Error Resume Next strCreateString = MakeObjectFromPath(strFileName) Set vDummy = Nothing Set vDummy = CreateObject(strCreateString) If vDummy Is Nothing Then PlugInExists = False Else PlugInExists = True Set vDummy = Nothing End If End Function Public Function MakeObjectFromPath(strFileName As String) As String MakeObjectFromPath = ExtractFileName(strFileName) & _ ".Game" End Function

 
Figure 9: Running the Game Manager.

Notice the code above looks for DLLs in a specified plug-in path. I've simply used the application's own path (App.Path), meaning the DLLs need to be copied into the same directory as the application itself. However, they need not be constrained in any way. The code above is also a segment from the GameManager project accompanying this article.

Simply add the DLL names to a list and display these back to the user. Running the GameManager.exe program yields—predictably and happily—two results.

The buttons to the side test the functionality of the DLLs, ensuring that the methods and properties work as expected. The code behind each button is almost identical, and essentially invokes a new instance of the appropriate DLL and calls the appropriate method or property. The "Play" button, for instance, is implemented thusly:

Private Sub bPlay_Click() Dim vObj As Object Set vObj = TheSelectedObject vObj.playGame Set vObj = Nothing End Sub Private Function TheSelectedObject() As Object Dim strCreateString As String Dim vObj As Object strCreateString = MakeObjectFromPath _ (lstPlugins.List(lstPlugins.ListIndex)) Set vObj = CreateObject(strCreateString) Set TheSelectedObject = vObj End Function

Again, due to naming convention consistency, all the plug-in DLLs have a class named Game with a "playGame" method that can be called for the purpose of playing the game contained in the DLL.

A close inspection of the GameManager code reveals not a single reference to any specific DLL. Thus, the code has no built-in knowledge of the Reversi or Breakout games. Nor does it possess any built-in limits to the number of DLLs that may exist.

Elegant Programming
The concepts presented here are simple, yet completely transferable to any other purpose.

By carefully considering just what each of your plug-in DLLs have in common and by enforcing a consistent naming strategy, you can easily detect all your plug-ins and write generic code to call their methods and properties.

You can also easily remove or add DLLs with new games and the GameManager program still works as expected. It needs no recompilation or redistribution. DLLs can be replaced with enhanced features and all that is required is to just "drop" the plug-in DLLs into the appropriate directory.

You can add solid functionality to the main front-end program without placing any extra burden on the plug-ins. For instance, to sort the list of games based on the player's preference, shift those more frequently played to the top of the list. Again, this requires absolutely no built-in intelligence regarding the games or plug-ins being used. Just provide code to maintain a list of names and increment a counter each time the "Play" button is pressed (and code to save these counters, whether to a database, the registry or even an .INI or some other configuration file).

One very important thing to keep in mind is that Visual Basic registered the ActiveX DLLs with Windows when you compile them. So if you copy the DLL onto another computer, you must register it manually. You can do this with the REGSVR32 DOS command or with a deployment tool like InstallShield.

Apart from this one restriction, adding plug-ins to your application is really no more complex than basically dropping DLLs into a disk directory.

To be honest, I think this is a tremendous example of very simple programming used to achieve highly professional effects.



David M. Williams is an Australian I.T. writer, trainer, and consultant. He is the author of Win32 Font Lister and other shareware programs. Reach him by e-mail at ap_dmw@bigpond.com.
Comment and Contribute

 

 

 

 

 


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

 

 

Sitemap