Tuesday, 07 September 2010
PicoSearch

DHTML Designer

This column appeared in the July 2000 edition of EXE. It discusses the general approach to developing with the DHTML Designer..


Last year I wrote a couple of columns concerning WebClasses, which was one of two new technologies within Visual Basic 6 concerned with the development of Internet applications. For completeness I would like to cover the other tool, the DHTML Designer. Although both technologies are concerned with the Internet, from one point of view they can be considered as having contrasting tie–ins to Microsoft architecture. WebClass–based applications require the presence of Internet Information Server (IIS) technology at the server end, although any decent front–end browser is capable of hosting the resultant output. DHTML Designer applications on the other hand are really targeted at using the Internet Explorer browser version 4 or above. Therefore if you are writing a DHTML–based application you will be more concerned with ensuring that your target audience has a standard browser. For this reason applications built around this technology are more likely to be developed for corporate intranets instead. Of course there is no reason why you can’t combine a DHTML front–end with a WebClass–based back–end from which you will gain the best of both worlds.

Getting started

The process starts by selecting New DHTML Application from the New Project dialog. Within the project window you will see that a Modules folder exists and contains a file called modDHTML.bas. This file contains a couple of useful routines called GetProperty and PutProperty which I will come back to a little later. Also in the Project pane you will see a Designers folder, a concept to which I gave some coverage last month. Finally, looking at the References dialog for the project itself you will be able to see that references have been set to Microsoft DHTML Page Runtime Library and to the Microsoft HTML Object Library.

Putting together a DHTML web page is a bit different to the traditional method of designing forms, but is close enough to be fairly intuitive to a Visual Basic developer trying this out for the first time. There is a one–to–one relationship between a single DHTML Designer page and a single web page. The DHTML Designer page consists of two panes laid out in a standard explorer–like manner. The left hand pane provides a tree view of all of the elements that exist on the page, while the right hand pane provides a design view on the page itself. If you open the Toolbox window you should find that the context is automatically set to display the relevant HTML controls. One of the main differences between this approach and the form–based method is that straightforward text is manipulated in a rigid manner similar to that offered by a text–editor, whereas other controls – known as elements in this scenario – will float wherever you plop them.

For the purposes of demonstration I’ve made up a fictitious page that could be found on the EXE website asking for feedback on my column, as shown in figure 1. This page includes several standard controls from the Toolbox.

Figure 1: DHTML Designer in edit mode

As with form–based applications you can press the Run button (or F5) at any time to start the application; in this case of course the results will be browser–based as shown in Figure 2.

Figure 2: The resultant web page

With regards to the actual HTML page itself you can either link to an external, pre–created page or you can work with the new blank page presented to you within the designer. If you choose to work from a blank page then the definition of the file is stored within the designer project files so you don’t get the chance to tweak the HTML. However, you can subsequently save a file to an external location by providing a value for the SourceFile property.

Add a little code…

Code wise, things are very familiar, and yet they are different. You can still access the code window for a control by double–clicking it, but the event names tend to be prefixed with “on” as is the convention with Java. Therefore, where we would normally be used to a click event perhaps being called Button1_Click, it is now Button1_onclick. Some names change completely, for example Button1_LostFocus is now Button1_onblur.

The Dynamic HTML object model is the means by which the resulting web page is manipulated. At the logical root of the programming model is the BaseWindow object, which is really a representation of the browser itself. This isn’t normally of too much use. The BaseWindow instance will itself contain an instance of a Document object, which is the point at which we are likely to become more interested. The Document object exposes a whole host of “on” events, such as onclick and onmouseover. I said logically just now because the actual implementation is slightly different in order to merge the expectations of Java developers with those of Visual Basic developers. Microsoft has chosen to implement a base object called DHTMLPage. This provides the Initialise, Load, Unload, and Terminate events as would be found in traditional Visual Basic development. The DHTMLPage object contains a top–level reference to both the BaseWindow object and, in fact, the Document object, although the BaseWindow object itself also exposes the Document object for conformity to the logical object model design.

If you look at Figure 1 you can see that I’ve added a piece of text labelled “Date” which is transformed in Figure 2 into the actual date on which I ran the page. I’ve done this to illustrate a simple way in which the page can be dynamically configured at run time. In order to perform this operation there is nowhere convenient within the Document object to perform this task, which is where the DHTMLPage object comes in. As with normal forms the Load event allows us to set the initial properties of the page, which is done like this:

Private Sub DHTMLPage_Load()
  txtDate.innerText = Format(Now, "Long date")
End Sub

The innerText property allows for a text field to be altered as would normally be found with the Text property for form–based development. However, for the purposes of web development the innerText property has a companion in the shape of innerHTML. This allows for a string to include HTML tags which will be parsed by the browser to apply whatever properties you specify, such as:

Private Sub DHTMLPage_Load()
  txtDate.innerHTML = "<I>" & Format(Now, "Long date") & "</I>"
End Sub

I mentioned earlier that there are definitions provided for a couple of routines called GetProperty and PutProperty. Because a DHTML application only needs to work on a client machine (as opposed to a stream of HTML coming from a server) the maintenance of state data has to be handled locally. This task is achieved through the use of a property bag, which is the Visual Basic name for a cookie. Cookies are temporary files that are managed by the file system. Designed to be repositories of small amounts of data they have a slightly different set of attributes to conventional files, such as an expiry date after which they can be automatically deleted. To provide an illustration of how to use a property bag we can consider the case of a user providing his or her name on one web page and then expecting to see it again on a subsequent page. This would be achieved by initially stashing the data with the PutProperty routine, as in

PutProperty "UserName", txtUserName.value

And subsequently retrieving it thus:

txtUserName.innerText = GetProperty("UserName")

These two functions actually do their work through the cookie property of the Document object so the naming and management of the file that contains the temporary data is completely handled behind the scenes using standard Internet functionality.

How it works

Earlier I mentioned that you can save the HTML file internally, or you can make a reference to an external file. Unless you are writing an application that will itself be called from another web application it is better to save your HTML files externally so that you can call them directly from a desktop shortcut, the Start menu, Windows Explorer, or whatever. To do this click on the Properties button on the Designer’s toolbar and click the “Save HTML in an external file” radio button. At this point you will be able to provide a suitable file name. Once you have finished your coding cycle and you compile the project the core HTML will remain within the file that you specified, as you would expect. However if you examine the file with a text editor you will see that Visual Basic has inserted a block of metadata similar to that shown in Listing 1. This metadata is declaring that the code for this page is of a type that will be supported by the MsHtmlPageDesigner component. The code itself is a COM object as denoted by the GUID, and as implemented by the ActiveX DLL that you have just created.

<!--METADATA TYPE="MsHtmlPageDesigner" startspan--><object id="DHTMLPage1" classid="clsid:49F59A74-5569-4408-A93E-193666F0B08B" width=0 height=0></object><!--METADATA TYPE="MsHtmlPageDesigner" endspan-->

Listing 1: HTML code providing link to DLL

With regards to the deployment of a DHTML application it is of course necessary to include the resultant DLL itself, together with whatever HTML files are used in the project. You should also include the DSR and DSX files that are generated with each web page. If you are using the Package and Deployment Wizard then these will all be bundled up into the resulting setup kit, but you should be aware that any files that the HTML pages call upon (such as graphics) will need to be added manually. Finally, depending upon how well you know your target environment, you may or may not need to redistribute the standard VB6 runtime file (MSVBVM60.DLL) and the DHTML Designer run–time support file (MSHTMPGR.DLL). The target machine should also be running Internet Explorer 4.01 SP1 or later.

The DHTML Designer is a part of Visual Basic that still remains unused by a fair proportion of developers, but as more developers switch over to Internet–related projects its use will be growing. As a tool in its own right it is fairly straightforward to use, but of course being able to use it is only part of the picture. To really get the best out of it you will need to study the Internet Client SDK documentation which can be found in the MSDN library.

Copyright ©2002 Jon Perkins I, Jon Michael Perkins, hereby assert and give notice of my right under section 77 of the Copyright, Designs, and Patents Act 1988 to be identified as the author of the foregoing article.