ActiveX Documents in VBby Peter G. Aitken
ActiveX gives you more than controls. An ActiveX document gives you the power to deliver VB-enabled content over the Web.
One of the fundamental technologies behind Visual Basic development, and indeed behind Windows applications in general, is ActiveX. Most Windows developers know about ActiveX, but when you ask them, it seems that all they really know about are ActiveX controls. There can be no doubt that ActiveX controls are an essential tool for Windows programming, but they are only part of the picture.
For a Visual Basic programmer, there are other powerful ways to use ActiveX technology. In particular, a type of Visual Basic project called an ActiveX document provides some development capabilities that you may find very useful. In this column, I will explain the fundamentals of ActiveX documents and what they can do for you.
ActiveX documents are primarily used for Web programming. Put simply, an ActiveX document is a Visual Basic application that is "published" to a Web site and then downloaded and executed in the users Web browser. An ActiveX document is not a Web page in the usual sense, as it involves no HTML or script. To the end user however, this distinction is moot, as all they really care about is what they see and do on-screen. They usually do not give a tinkers damn about the underlying technology. If you have worked with Visual Basic to any extent, you know its incredible power, and the ability to deploy full-fledged Visual Basic programs as Web-based applications should be a tempting inducement.
To be honest, I find the "document" part of the name ActiveX document a very poor choice. We tend to associate this word with data or content, and not with functionality. A Microsoft Word document, for example, contains the content while the Microsoft Word program contains the functionality. In actuality, an ActiveX document is better thought of as a hybrid between a document and an application. An ActiveX document project is made up of a document that contains the data, and a server, or application, that provides the functionality. After compilation, the document is contained in a Visual Basic Document file (.VBD) and the server is contained in either an .EXE or .DLL file. During development, the project is in a .DOB file, which is a plain text file containing the definitions of the projects controls, source code, and so on. If an ActiveX document project contains graphical elements that cannot be stored in text format, they will be kept in a .DOX file. The .DOB and .DOX files in an ActiveX document project are parallel to the .FRM and .FRX files of a regular Visual Basic executable project.
ActiveX documents run in a container. Three types of containers are available: a Web browser, Microsoft Office Binder, and the Visual Basic development environment tool window. While the last two containers offer some interesting development possibilities, it is on the Web where ActiveX documents are most often used. At present, I believe that only Internet Explorer (versions 3 and later) offer the ActiveX support required to run ActiveX documents. I know that some degree of ActiveX support is available for Netscapes browser, but whether this is sufficient to run ActiveX documents, Im not sure. This browser limitation means that ActiveX document projects are best suited for deployment on an intranet, where you know that all potential users have the required Microsoft browser.
The amount of the ActiveX document that is visible dependsobviouslyon the screen size of the container its running in. If the container is smaller than the document, horizontal and/or vertical scroll bars are automatically displayed by the container to permit other areas of the document to be scrolled into view.
What are the logistics of deploying an ActiveX document? A deployment consists of one .VBD file for each document in the project, plus a compressed CAB file containing the compiled DLL or .EXE file. The CAB file may also contain the Visual Basic runtime and support files, or you can specify that these be downloaded directly from Microsofts site. This latter option reduces the size of your deployment but does not remove the requirement that the Visual Basic runtime and support files must be downloadedonly once, howeverunless the user already has these files on the local system. This requirement for support-file download is another reason why ActiveX documents are more suitable for specific Web-based applications and are less suitable for a general "public" Web page.
When, then, should you choose ActiveX document technology over other Web development approaches? Its not a cut and dried answer, as there is so much overlap in the capabilities of various Web development tools. Generally, because ActiveX document technology is a "heavy hitter," it should be reserved for those situations where its additional capabilities justify its greater overhead. If you can accomplish your goal with DHTML or an ActiveX control, then by all means you shouldyou do not need an ActiveX document.
The Users View
Using an ActiveX document is very simple. All that is required is to navigate to the corresponding .VBD file using a compatible Web browser. You can also link to a .VBD file from an HTML page using the standard hyperlink tag:
<a href="sales.vbd">Click to open Sales</a>
When a user navigates to an ActiveX document for the first time, heres what happens:
The second and all subsequent, only step 4 is required, times a particular user navigates to an ActiveX document. Hence, the download overhead associated with this technology is a one-time event. If you deploy an updated version of the application to the server, the new version will be downloaded the next time a user navigates to it.
The UserDocument Object
The UserDocument object is at the heart of any ActiveX document project, just like the Form object is the basis for standard .EXE projects and the UserControl object is the basis for ActiveX control projects. In fact, much (but not all) of what you know about Visual Basic forms also applies to UserDocument objects. This is in keeping with the container model that is so prevalent in Windows programming. A Visual Basic form, for example, serves as a container for the controls and code that you put in it. The form provides the wrapper, or interface, between its contents and the next higher level of "containerness"; in this case, the Windows operating system. Likewise, a UserDocument is a container for controls and code that you add and provides an interface between these elements and the container (a Web browser, for example) in which the ActiveX document is running. The same analogy can be extended to the UserControl object that serves as the basis for creating ActiveX controls in Visual Basic.
When you start a new ActiveX document project, it contains a single UserDocument. You add controls and code to the UserDocument in the usual manner. A project can contain multiple UserDocuments, and can also contain a code module where you can put shared procedures, type declarations, global variables, and so on. A UserDocuments events are important in putting an application together, and it is here that youll find some differences from the standard Visual Basic form. A UserDocument detects many of the events youre used to working with on forms, such as KeyDown, MouseMove, OLEDragOver, and Click. Missing, however, are Activate, Deactivate, the various DDE-related LinkXXXX events, Load, QueryUnload, and Unload. Instead, the UserDocument detects other events, including those listed in Table 1, that are appropriate for the way it is used.
Table 1. Some important UserDocuments events.
There are a few other UserDocument events that we will deal with as needed.
An ActiveX document project can also contain standard Visual Basic forms. Unlike UserDocuments, forms are not displayed in the container but rather as stand-alone "pop-up" windows. In most cases, an ActiveX document application is designed so the main part of the application runs in the container, and therefore is programmed as one or more UserDocuments. Regular forms are used more often as dialog boxes. However, this approach is not required, and the potential combination of UserDocuments and forms provides a great deal of flexibility when designing your application. Be aware, however, that some containers (including Internet Explorer) do not permit a modeless form to be displayed by a DLL. A modeless form, you may recall, is one that can be left open when you switch to another window in the application and that contrasts with modal forms that must be explicitly closed before you can make another application window active. To use modeless forms in an ActiveX document application, therefore, you will have to deploy it as an .EXE.
The UserDocument object also has a set of properties, of course. There is some overlap with Form properties, but as with events, there are also some important differences. Table 2 describes the most important UserDocument properties.
Table 2. Some important UserDocuments properties.
Of these properties, only HyperLink requires some explanation. While provided by the container, HyperLink is a property of the UserDocument and provides a way to navigate to a different URL. The most important method of the HyperLink object is NavigateTo. The syntax (assuming the UserControl is named "UC1") is:
UC1.Hyperlink.NavigateTo(Target [, Location [, FrameName]])
Target specifies the destination location. It can be a URL or a local document. Location specifies the location (bookmark) in the target to display. FrameName specifies the target frame to navigate to. If either of the last two arguments are omitted, the targets defaults are used. Here are two examples of using NavigateTo, one of which navigates to a remote URL and another which opens a local file (an ActiveX document):
The HyperLink object also has GoForward and GoBack methods that navigate forward and backward in the history list. These methods take no arguments. If the container does not maintain a history list, or if the list is empty, these methods generate an error, so you must use error trapping.
There is an additional consideration when navigating between ActiveX documents. The NavigateTo method requires the full path to the VBD file you are going to. During project development, you know where the VBD files are located: They are placed in the Visual Basic folder when you run the project from within the Visual Basic development environment and are placed in the project folder when you compile the project. Once the project is deployed on the Internet, however, you cannot predict where the downloaded files will end up on the users machine.
How, then, can you navigate? For a multiple document ActiveX application, all the VBD files will be downloaded to the same folder. By querying the path to the initial document (which loads automatically), you can determine the path to the other documents. This initial document path is obtained from the browsers LocationURL property, which returns the fully qualified filename of the currently loaded document. Strip off the filename part to obtain the path information, and youre all set. To simplify this task, you can use the function GetPathFromFullFileName, which is presented in Listing 1. This function is passed a fully qualified filename and returns the path portion. Its operation is straightforward: It looks for the last / or \ in the fully qualified file name; anything up to and including that character is the path.
Given this function, heres how to navigate to UserDocument2.vbd:
Dim p As String
Most ActiveX document applications require some way to save data between sessionsspecifically, data that has been entered by the user. An ActiveX document has all of Visual Basics file reading and writing commands available, but its not recommended that you use them. Rather, data should be saved in a property bag. As the name implies, a property bag (represented by the PropertyBag object) is intended for storing properties, and thats exactly what it is used for when creating an ActiveX control. In an ActiveX document, by treating your user data as properties, you can also use the PropertyBag object to store the data. There are several advantages to this approach, compared with standard file reading and writing commands:
To use the property bag, you need to know about a couple of UserDocument events. When an ActiveX document is first opened in its container, the first event to fire is always Initialize. The second event depends on whether there are saved properties for this document. If there are none (and this is determined automatically by the container), the second event is InitProperties. If there are saved properties, ReadProperties fires instead. You put code in InitProperties to set initial default values for the properties (data); these values will be in effect if there are no saved properties. You put code in ReadProperties to read property values from the PropertyBag object when they are available.
The WriteProperties event procedure is called when the application is closing, but only if the container has been notified that one or more properties were changed by a call to the PropertyChanged method. You put code in the WriteProperties event procedure to actually write the properties to the property bag. The PropertyChanged method is usually passed the name of the changed property, but this is not really necessary. Which properties are saved is determined by the code in the WriteProperties event procedure. Calling PropertyChanged, whether once or a hundred times, serves only to tell the container that WriteProperties needs to be called when the application closes. The PropertyBag object itself is automatically created and handled by the container, and a reference to it is passed to the ReadProperties and WriteProperties event procedures.
To write data to the PropertyBag object, use the WriteProperty method:
PropBag.WriteProperty(DataName, Value [, DefaultValue])
Here, DataName is the name to be associated with the data, and Value is the data itself. DefaultValue is an optional default value to associate with this data item. Properties are read from the property bag using the objects ReadProperty method. Its syntax is:
PropBag.ReadProperty(DataName [, DefaultValue])
DataName is the name associated with the data when it was saved in the property bag. DefaultValue is the value to return if the specified data item is not found in the property bag.
To save data in the PropertyBag object, the data does not have to actually be a property. In other words, you do not have to create Property Let and Property Get procedures for it. Make the item a property only if you need to use it as a property. (The use of public properties in ActiveX documents will be covered below.)
Note that the property bag works properly only when you run a compiled project outside the Visual Basic environment. When you run an ActiveX document project within the Visual Basic environment, the property bag persists data only as long as the browser remains open.
There are quite a few more details left to cover with regard to ActiveX documents, but at this point, you can put together a useful (if not terribly exciting) demonstration. This ActiveX document program will show you the nuts and bolts of creating a two-document application, navigating between documents, and persisting user data. The application has a main document that provides two boxes where the user can enter information. Another button navigates to the second UserDocument. This second document contains nothing but a button for returning to the first document. Youll see that user data entered in the text boxes is saved between visits to the first document.
To begin, fire up Visual Basic and create a new ActiveX Document DLL project. Open the UserDocument and place one large and one small text box on it. For the large box, change the Name property to txtUserComment and the Multiline property to True. Change the small boxs Name property to txtUsername. Add two labels to identify the text boxes, as shown in Figure 1. Finally, add a command button and change its Name property to cmdNext and its Caption to Next. Save the UserDocument under its default name of UserDocument1.
Figure 1. The first UserDocument.
Select Add User Document from Visual Basics Project menu to add a second UserDocument to the project. Place a single command button on this UserDocument, with the Name property set to cmdGoBack and the Caption set to "Go Back." Save this item under its default name as well.
Next, select Add Module from the project menu to add a code module to the project. Add the code from Listing 1 to this module, and then save the module.
The final steps to completing this project are to add the required code to the two UserDocument objects. The code for UserDocument1 is given in Listing 2, and the code for UserDocument2 is in Listing 3.
Figure 2. Executing the ActiveX document in Internet Explorer.
The application is shown executing within Internet Explorer in Figure 2. Note how the two data items were treated differently. The user comment is defined as a public property, with the corresponding Property Let and Property Let procedures. In contrast, the user name is not a property at all, with no Get and Let procedures. Yet, as you can see, both can be persisted in the property bag. There are differences, however, in that the user comment will be available outside the document as a public property, as youll see below.
This application is deceptively simpleboth simple to create and simple in appearancebut this belies the potential power of an ActiveX document application. On the one hand, you have the power of Visual Basic to create sophisticated, complex applications. On the other hand, you have the flexibility and interactivity of the Internet. Its a dynamite combination, as I hope youll agree. And you have only seen some of the tricks an ActiveX document can do! Tune in next issue for more cool stuff. v
Listing 1. GetPathFromFullFileName
Listing 2. Code in UserDocument1
Option Explicit Private Sub UserDocument_InitProperties() ' Initialize the document's two data items. txtUserName.Text = "Enter your name" UserComment = "Enter your comments" End Sub Private Sub cmdNext_Click() Dim path As String path = GetPathFromFullFileName(UserDocument.Parent.LocationURL) Hyperlink.NavigateTo path & "UserDocument2.vbd" End Sub Private Sub txtUserName_Change() ' Tell the container than a property has changed. PropertyChanged "UserName" End Sub Public Property Get UserComment() As Variant UserComment = txtUserComment.Text End Property Public Property Let UserComment(ByVal vNewValue As Variant) txtUserComment.Text = vNewValue End Property Private Sub txtUserComment_Change() 'Tell the container that a property has been changed. PropertyChanged "UserComment" End Sub Private Sub UserDocument_ReadProperties(PropBag As PropertyBag) ' Read the document's two data items from the property bag. txtUserName.Text = PropBag.ReadProperty("UserName", "") UserComment = PropBag.ReadProperty("UserComment", "") End Sub Private Sub UserDocument_WriteProperties(PropBag As PropertyBag) ' Write the document's two data items to the property bag. PropBag.WriteProperty "UserComment", UserComment PropBag.WriteProperty "UserName", txtUserName.Text End Sub
Listing 3. Code in UserDocument2
Private Sub cmdGoBack_Click() Hyperlink.GoBack End Sub
We started looking at one of Visual Basics powerful Internet technologies, ActiveX documents. An ActiveX document is, in effect, a full-featured Visual Basic application that is deployed over the Internet and run inside a container, usually a Web browser. Despite the "document" part of its name, an ActiveX document is better described as a hybrid between an application and a document, containing both executable code and data. ActiveX document technology offers you the full power of the Visual Basic language and its visual interface design tools coupled with the capability for Web-based deployment and updatingsomething that is become more and more important these days.
There are tradeoffs, of course. The technologys hefty download requirements and limited browser compatibility limit its usefulness primarily to intranets. Still, that leaves a huge number of places where ActiveX document technology may well be your best bet for Web development.
At present, ActiveX documents can be "run" in three different containers: Internet Explorer versions 3 and greater, Microsoft Office Binder versions 1 and later, and the Visual Basic development environment tool window. While ActiveX document applications are often written with a particular container in mind, the possibility exists for applications to be written for multiple containers. This is, I believe, an exciting possibility, particularly as more and different containers become available.
That said, it does complicate programming to some degree. While a container capable of hosting an ActiveX document must, of course, meet a minimum set of capabilities in order to do so, the different containers will differ unavoidably in various ways that are potentially relevant to an ActiveX document that is running in them. One example is navigation. In Internet Explorer, you navigate using the Hyperlink objects NavigateTo method, whereas the Binder requires that you add a new Binder section, and the code is completely different. This means that your ActiveX document applications need to check which sort of container theyre running in. Even if your application is intended to run only in a particular container, you may want to have start-up code that checks the container and, if it is not the proper one, displays a message to the user and terminates.
To determine which container type an ActiveX document application is running in, use the TypeName function, which returns information about the variable passed as its argument. If the variable is a reference to the ActiveX documents parent, obtained as UserDocument.Parent, then the function returns a string identifying the container, as shown in Table 3.
Table 3. Document container ID values.
At least, this is what the Microsoft documentation says is supposed to happen. I have noted, however, that when Internet Explorer 5 is the container, TypeName returns the string "IWebBrowser2." My guess is that if the return value includes the text "browser," then the container is some version of Internet Explorer. Then, if your ActiveX document project is intended to run only within a browser, you could put something like the following in each documents Show event procedure:
If InStr(1, TypeName(UserDocument.Parent), "browser", vbTextCompare) = 0 Then
Public Properties, Variables, Methods, and Procedures
A public property, variable, method, or procedure is one that is available throughout the entire ActiveX document project, and not just in the document where it is defined. Once you go beyond the basics with ActiveX documents, youll find that multiple-document projects are often the easiest way to accomplish your task, and these multiple documents often need to "talk" to each other. Well get to why they might need to talk to each other in a minute, but first the how. If youre familiar with making items public in ActiveX controls, this will all seem very familiar to you.
Making public a procedure or a variable (in a code module) or a method or a property (in a UserDocument) is simply a matter of using the Public keyword in the definition or variable declaration. Public is the default for regular and property procedures, and for methods (which, of course, are just procedures under another name), so these code elements will always be public unless you explicitly make them private. Then, call them from other modules using the procedure name or, for a method, the standard object.method syntax. More important, as well soon see, is creating public variables in code modules. By declaring a variable at the module level (outside any procedures), using the Public keyword results in a variable that is visible throughout the project.
When do public items in an ActiveX document project become available? Itemspublic procedures and variablesin a code module are always available. Things are a bit more complicated when it comes to public methods and properties of a UserDocument. Anything within a UserDocument becomes available when an instance of the document is created, which happens when the document is loaded into a container. Then, the items go out of scopebecome "unavailable"when that instance of the document is destroyed, which usually happens when it is unloaded by its container. I say "usually" because there are differences between containers in terms of when a document instance is actually destroyed. Because some containers do, in fact, destroy a document instance as soon as it is unloaded, you should write your code as if this is always the case.
Perhaps you can already see the potential for problems. The whole idea of public properties and methods in one document is to make them available to code in other documents, right? Thus, Doc1 might contain properties and methods that are accessed by code in Doc2. What happens if Doc2 runs before Doc1 is loaded, or after Doc1 has been unloaded and destroyed? Remember, in an ActiveX document project you do not have the same close control over when things are loaded and unloaded as you do in a regular Visual Basic application. Any ActiveX document can be navigated to independently, and your coding must take this possibility into account.
The best solution is to keep a separate, global reference for each document in the project. These references are created as global variables in the projects code module. For example, suppose your project contains three documents. Then, at the module level in the projects code module, you would place the following public variable declarations:
Public gDoc1 As Object
Then, within each document, you would add code to set the global reference to that document. For example, somewhere in the code in Doc1 would be:
Set gDoc1 = Me
Where exactly this code goes depends on the details of your project. If you always want the reference to the document saved in the global variable, then the code could go in the documents Show or Terminate event procedure. If the reference needs to be set only under certain circumstancessay, when the user navigates away from this document to another specific documentthen the code could be placed along with the navigation code. In either case, since a reference to the document has been saved in a global variable, the instance of the document will not be destroyed when it is unloaded from the container but will be available as long as the application is running. Hence, the documents public properties and methods will remain available.
"But wait," you may be thinking, "What if Doc1 has not been loaded at all when another documents code references it?" Good questionbut the point of this technique is not to guarantee that an instance of Doc1 always exists, but to permit other components of the project to determine whether an instance exists and then take appropriate action. This is done simply by querying the value of the global variablegDoc1 in this case. If its value is Nothing, then an instance does not exist and the code can take appropriate actionincluding creating an instance, if required. If, on the other hand, the value of gDoc1 is not Nothing, then an instance of the document exists and its public methods and properties can be used.
Heres an example. Suppose you want your projects various documents to have a consistent appearance, but also want to permit the user to set the foreground and background colors as desired. When Doc2 is loaded, you want it to use the same background and foreground color as Doc1, but only if Doc1 has already been loaded, which means that the user may have customized its colors. If Doc1 has not been loaded, then Doc2 should use the default foreground and background colors. The following code in Doc2s Show event procedure does the trick.
Private Sub UserDocument_Show() If gDoc1 Is Nothing Then BackColor = DEFAULT_BACKCOLOR ForeColor = DEFAULT_FORECOLOR Else BackColor = gDoc1.BackColor ForeColor = gDoc1.ForeColor End If End Sub
By using this same general technique, with variations to suit the occasion, you can make use of the power of a multi-document project without running into problems trying to reference a non-existent object. It is also possible to use global code module variables to pass data between one document and another. I have found this useful for small bits of data, such as maintaining application-wide flags. Larger chunks of data are better passed between documents using the file system.
Remember that good programming practice requires that you destroy object instances when they are no longer needed. If you are keeping global references, this is particularly important, because you cannot count on your document objects being destroyed automatically when unloaded. To avoid hogging system resources with no-longer-needed objects, while retaining objects you will refer to later, you may need to do a little bit of planning.
What guarantee do you have that the containers viewing area will be big enough to display your entire ActiveX document? None at all. To deal with this situation, container objects provide for scrolling to bring different parts of a too-big document into view. The "window" through which you view a part of the document is called the viewport. When the document is longer and/or wider than the viewport, the container automatically displays a vertical and/or horizontal scrollbar to permit the user to scroll. If the user changes the size of the container, the scroll bars appear and disappear as needed.
The automatic display of scroll bars by the container is controlled by the UserDocuments ScrollBars property. The default setting is for both scroll bars (horizontal and vertical) to be displayed as needed. You can change this property to display only one, or no, scroll bar, but I cannot imagine a situation where this would make sense.
When the application is running, code in the ActiveX document can obtain information about the current viewportits position relative to the UserDocument and its size. In effect, this permits your code to determine what parts of the document are visible, and what parts are not visible, at any given time. This information, in units of twips, is available from the following UserDocument properties:
As with all default coordinate systems in Windows, the top left is the origin, with coordinates 0,0. What can you do with this information? Depending on the nature of your document, you may be able to resize it so it fits perfectly within the container viewport, freeing the user from the need to scroll to see all parts of it. If the document cannot be resizedperhaps it contains a collection of carefully placed controlsyou can scroll the document under program control to bring a particular part of it into the viewport. This code shows an example. When the specified text box gets the focus, the viewport is shifted to move that text box to the upper left corner of the viewport.
Private Sub Text1_GotFocus() UserDocument.SetViewport Text1.Left, Text1.Top End Sub
Note that this works only if the viewport is smaller than the document when the focus is moved.
Asynchronous Data Transfer
Asynchronous data transfer permits an ActiveX document to obtain data from a remote source, whether it be a file or a URL. Because the transfer is asynchronous, it happens in the background while your ActiveX document application is busy doing other things. When the transfer is complete, an event fires, notifying the program. Another event fires as the download progresses, giving the program access to the data as it arrives.
You use the UserDocuments AsyncRead method to initiate an asynchronous data retrieval. The syntax is:
AsyncRead Target, AsyncType, PropertyName, AsyncReadOptions
Target is a string expression that specifies the data to retrieve. It can be a URL or a path to a file.
AsyncType specifies the format of the data being retrieved. Use VbAsyncTypeFile if the data is a file created by Visual Basic, VbAsyncTypePicture if the data is a Picture object, and VbAsyncTypeByteArray if the data type is unknown. (That is, if it is an arbitrary sequence of bytes with no assumptions as to its structure.)
PropertyName is an optional argument by which you assign an arbitrary name to the download. The name you assign has no effect other than to permit you to identify the download process if two or more downloads are ongoing at the same time.
AsyncReadOptions is an optional argument that specifies certain download options, mainly having to do with server versus locally cached copies of the data. Possible settings are explained in Table 4. The identifiers listed are constants, with their numeric values in parentheses after the identifiers.
Table 4. AsyncRead's AsyncReadOptions argument values.
What exactly happens when you call the AsyncRead method? Errors can occur with this method, and they occur synchronously, which means that you should have error trapping enabled when you use this method. Absent an error, the data transfer begins and, assuming you did not specify a synchronous download with the VbAsyncReadSynchronousDownload option, program execution continues with the statements following the call to AsyncRead as the download proceeds in the background. Two events fire in response to the download: AsyncReadProgress as the download progresses, and AsyncReadComplete when it is finished. When the download is complete, the data is available in a disk file for your program to use as needed.
Both of these event procedures receive a single argument, of type AsyncProperty. This is an object whose properties provide information about the download at the time the event fired. These properties are explained in Table 5. The status codes returned in the StatusCode property are listed in Table 6. As with Table 4, the number in parentheses is the constants numeric value.
Table 5. Properties of the AsyncProperty object.
Table 6. Status codes for the AsyncProperty object.
With these two events, you can probably see the basic structure of the code required to perform a data transfer. The basic outline of the required steps is this:
You can see how the ability to asynchronously read data from a URL could be a very powerful tool. But why would you want to use AsyncRead to read data from a remote file on a local network? Visual Basics regular file access statements are suitable for that task. The answer lies in the asynchronous nature of the transfer. Even local networks can experience congestion and delays, and since the regular file access statements operate synchronously, your program will "hang" while a slow file access operation is in progress. With AsynchRead you avoid this potential problem.
Menus in ActiveX Documents
ActiveX documents begin to seem even more like regular Visual Basic applications when you realize that they can have their own menus. When you are working on a UserDocument in the Visual Basic development environment, you use the menu editor to create you menu, just as for a regular Visual Basic form. When the document is loaded into its container, its menu is combined with the containers own menu, a process known as menu negotiation.
When you are using the menu editor, youll see a NegotiatePosition property associated with each menu item. This property is relevant only for top-level menu items, and cannot be changed from its default setting of "0-None" for sub-items. When applied to a top-level menu item, the possible settings and their effect are shown in Table 7.
Table 7. Settings for the NegotiatePosition property.
When the document is displayed in the container, the final menu arrangement depends on both the Caption and the NegotiatePosition properties of the documents top-level menu items. There are three possibilities:
This may seem a bit confusing, so lets look at an example. If your document has a top level menu with the caption Help, with NegotiatePosition set to "3Right", then it conflicts with the Internet Explorer menu and therefore will display as a sub-item on Internet Explorers Help menu (with the caption "XXXXHelp", where XXXX is the name of the UserDocument).
If, however, the NegotiatePosition property is set to "2Middle", there is no conflict, because Internet Explorer does not have a Help menu item in the middle of the menu bar. In this case, the documents Help menu will display separately on the menu bar.
Depending on the container, it may also be possible to manipulate the containers menu, although Im not able to cover it in this column. This provides you with the possibility of completely customizing the container menu so that the user sees only those menu commands that you want them to have access toalways a good idea to keep careless users from getting themselves into trouble!
Converting Existing Applications to ActiveX Documents
In the long-standing Visual Basic tradition of making your life easier, theres an automated way for you to convert existing Visual Basic applications to ActiveX document applications. After all, since an ActiveX document is, in effect, a Visual Basic application in a different suit of clothes, there are many situations where converting an existing application to an ActiveX document makes a lot of sense. The tool is called the ActiveX Document Migration Wizard, and it is an add-in that is accessed from Visual Basics Add-Ins menu. The wizard does not change the existing application, but creates a new ActiveX document project based on it. Some of the things it does are these:
For event procedures, where an exact counterpart exists, the wizard copies the code and changes the procedure name. For example, Form_Click is changed to UserDocument_Click. Where there is not an exact counterpart, the event procedure is copied with its name unchanged. Thus, the Form_Load event procedure is copied with its name unchanged and can be called as a general procedure, if needed.
Note that the process of migrating a standard Visual Basic application to an ActiveX document project is not completely automaticafter the wizard does its work, youll still need to work on the project a bit. However the wizard certainly saves a lot of time.
The Bottom Line
With ActiveX documents, I think we get a glimpse of the future of application development. Even more, we get a glimpse of the direction that computing in general is headed. The Internet has only begun to change things, and as the "wired world" continues to evolve, the distinctions between local and remote, here and there, will blur even further. Developers will have more choices, of course, but equally important is that they will be freed from other choices because they will no longer matter. The dichotomy of whether an application is deployed locally or remotely, and whether it executes locally or remotely, is already losing some of its meaning. ActiveX documents are a reflection of these changes, and its a technology that you can put to work today. v
During daylight hours, Peter is a research scientist at Duke University Medical Center in Durham, North Carolina. Comments and suggestions may be sent to him at firstname.lastname@example.orgCopyright © 1999, 2000 The Coriolis Group, LLC. All rights reserved.