ere's a genuine "real-world" problem: a particular company has a Web-based intranet for their document and content management. This system stores many hundreds of documents. Some of these are on related topics, such as organizational division constitutions, job descriptions. Sometimes the same document appears in different locations on the Web server, and often as different revisions of the same document.
What the client needs is a Web page where an administrator can enter the names of two documents, and get a new document that contains the text of the original two documents with any variations highlighted in some way. This way, users can inspect different versions of the same document, as well as different documents that deal with related matter.
This can be achieved by writing an ActiveX component in Visual Basic. The component is given the paths and names of two source documents, and a compare method turns out a brand new Word document that the administrator can save and deal with at leisure.
The data passed to the component is read from a simple Web form, which prompts the user for these source documents. This in turn calls an Active Server Page that invokes the component. However, ASP is not a requirement for this method. By coding the program logic within an ActiveX DLL it can be called from any Windows development environmentincluding "fat client" Visual Basic programs.
Here's how this DLL works and how you can call and use it from within both Visual Basic and ASP.
Creating Your ActiveX DLL
The steps to create an ActiveX DLL are:
- Start the Visual Basic IDE.
- From the File menu, select New Project.
- Choose ActiveX DLL from the dialog box.
The IDE presents a blank window, with a new class module. Unlike a typical Visual Basic program or control, an ActiveX DLL has no GUInor does any server-side component. The class module is where the DLL's functionality is implemented.
Visual Basic names the project Project1 and the class module Class1. In the case of an ActiveX DLL, it is especially important to change these names. The names are used when instantiating the object from any programming environment. For example, within an ASP page, you would use code like this:
set myObject = Server.CreateObject ("Project1.Class1")
This creates an object based on the Project1 project and Class1 class module.
Hence, not only is it good practice to change the project and class name, it is sensible. This changes the instantiation code. I called the project DWLib and the class WordComp:
Set myObject = Server.CreateObject ("DWLib.WordComp")