This page is aging out but. Archived here for further processing
everal years and employers ago, I worked for a school of information technology in Australia. At one point, administrators, frustrated by a confusing and distributed collection of tools for testing and grading, decided they needed a single program that could manage lists of students and subjects, generate tests, grade submissions, and upload results to the central university system?without being constrained in any way by the actual software being assessed in the exams themselves.
By creating an ActiveX/DLL library, with test generators and markers for each product merged together, I was able to rework the system in just that way. A main program was constructed to perform all the necessary housekeeping functions and to search for the DLLs. Menus were dynamically constructed based on the DLLs present. All the logic to make and mark tests for specific products were bundled into these DLLs.
To support a new product became a matter of simply generating a new DLL and dropping it into a disk directory on each computer that was using the system. The main program needed no recompilation or reworking whatsoever.
There are countless ways that you can apply this kind of extensibility. In this article, I’ll show you how to make your own expandable system using ActiveX/DLLs as plug-ins?in this case, a menu to manage a library of games.
Accompanying this article is the code for two VB6 projects implementing computer games?one being the familiar and popular Reversi game, and the other a version of the classic Breakout.
Each of these projects is completely stand-alone, and both compile to a single .exe file.
Through this example, you’ll learn the steps needed to convert your stand-alone programs into plug-in DLLs, and to write a generic program that detects these at run-time.
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
Figure 4: Create a new ActiveX DLL project – figure lost to time but not indispensible
………more
