by Jim Karabatsos - GUI Computing
As I am sure you will see as you peruse this issue of AVDF, Mark has gone totally wild on Active Server Pages, or ASPs. I think that this is a fantastic technology - ASPs truly make the task of creating HTML on-demand really easy and is an important player in the ultra-thin client end of the client-server spectrum.
So I thought that I would look at another technology that fits a little bit further along the spectrum - ActiveX documents. This technology allows you to create very interactive web pages without going near Java.
"ActiveX Document" is actually a really bad name. I do know where the name came from, but it is really dumb from the perspective of the programmer. An ActiveX Document (can we just make up an acronym AXD?) is really just an ActiveX control that happens to be an entire form. The control is registered as the handler for a particular type of document in much the same way that Word registers itself as the handler of .DOC files. When the browser is asked to display the document, it launches the control and negotiates the siting issues for menus, toolbars and so on, and then hands over control of the client area of the browser to that control. That control runs and can do anything that any program can do: it can access files, connect to databases or whatever.
The important thing that you need to keep in mind is that there are actually two parts to an AXD - the "document" and the program that knows how to deal with it. In most cases, the document is used only to cause the browser to launch the required application server for that document and nothing of any permanent value is actually stored in the document itself. This is in marked contrast to a Word document, where your text and formatting is stored in the document file and the application in fact processes the file.
To demonstrate the creation of an AXD, I started with a trivial little application that is used to calculate the repayments on a loan. I have been using this application as an introduction to VB programming since the early days of VB3 and I certainly do not intend to talk you through the creation process; the source code is available for download.
I then just ran the ActiveX Document Migration Wizard on the project and I ended up with an AXD. It really is that simple. I don't want to walk you through each of the wizard forms as they are really quite self-explanatory - just consult the on-line help if you need to. What I do want to discuss is how you move on from there.
You see, once you have created the AXD, you still need to get it to show in a browser. For your own testing purposes, it is quite a straightforward exercise. First you run the AXD project in the VB5 environment (nothing seems to happen). Then you point your browser at the VBD file that VB created in the default directory. If everything goes as expected, you should see your AXD hosted inside Internet Explorer.
What is going on here is that the VBD file contains, amongst other things, the GUID of the server needed to process that document, and that GUID identifies your application (which is currently running in the VB5 environment).
When it comes time to place your AXD on a Web server, you will find that there are three files you need to work with. Obviously, you need to place your application's EXE file on the server. You will also need to put the VBD file on the server. You would think that you could just point your browser at that VBD file to fire up the AXD. You would, however, be wrong. You actually need to run some HTML with some embedded scripting code to launch your application. This is what it looks like:
<HTML> <OBJECT ID="frmLoan" CLASSID="CLSID:75AE0FB2-CD8D-11D0-BD4B-0080C80D0C83" CODEBASE="loancalc.cab#version=1,0,0,0"> </OBJECT> <SCRIPT LANGUAGE="VBScript"> Sub Window_OnLoad Document.Open Document.Write "<FRAMESET>" Document.Write "<FRAME SRC=""frmloan.vbd"">" Document.Write "</FRAMESET>" Document.Close End Sub </SCRIPT> </HTML>
What is happening here is that the HTML is instantiating an object - the loan calculator, and then immediately opening the VBD file. If it seems rather roundabout, that's because it is.
OK, so how do you in fact deploy an AXD? Would it surprise you if I said you used a Wizard? You run the Application Setup Wizard (a separate program launched from the start menu) and it will create a .CAB file for you. This CAB file contains your EXE and any required support files. It also contains references to other CAB files that can be used to install common components such as the VB5 runtime. By default, these are downloaded from www.microsoft.com but, for an intranet deployment you can specify an alternate location that these support CABS can be downloaded from.
You would place a file with HTML similar to that shown above on the server (just make sure that the path to the CAB file is correct) and always link to that file, NOT to the VBD file directly.