Inside Technique : Sokoban Level Designer : Client Data Access with HTML Applications : HTA v/s HTML

Even though HTAs share the same DOM and Scripting Languages with ordinary HTML pages, there are two very significant differences between them. The first is that HTAs ignore the users security settings, thus offering a safe platform for ActiveX controls. The second, and this one is a potential minefield, is that HTAs operate in their own window, which is a standard Application window, and not a browser-owned window. In this section we will look at how the following issues affect the design of an HTA :

• Using ActiveX Controls
• Error Handling
• Debugging HTAs
• Application Window
• The javascript: Protocol

Using ActiveX Controls

Using ActiveX controls has always been a thorny issue for Web developers. While there is no denying their ease of use in extending the somewhat limited functionality of a Web Application, OCXs are basically binary executables, and thus enjoy potentially unlimited access to the client machine, including disk and registry access. Microsoft has a rigorous code signing and authentication procedure in place, which - in theory at least - ensures that the users always know where an OCX has come from, and whether it is safe to use. Inspite of this, many users tend to be paranoid about permitting their browsers to initialize these controls, and thus turn off support for ActiveX in their security settings.

This means that developers have no guarantee that their code will function properly on all client machines, even if they are using controls marked as safe for scripting, for example the Common Dialog control, which we had covered in the first article of this series. And if the developer wants to use a control that has been marked as unsafe for scripting, like the ADO Connection object we will be discussing in the next section, then the chances that the user will prevent the control from initializing increase dramatically.

HTAs offer a perfect solution to the ActiveX dilemma - they simply ignore the users security settings, thus ensuring that the controls are initialized properly. HTAs run from the client disk behave exactly like normal Windows executables, the user sees no security prompt - not even the Open-or-Download prompt that they would normally see when attempting to access an HTA on-line. The Level Designer has been implemented as an HTML Application which is run from the client disk.

Error Handling

Another reason why HTAs are perfect for deploying applications that contain embedded ActiveX controls is that error handling is simpler. In the first article of this series, we used a VBScript subroutine to ensure that errors raised by the Common Dialog control were trapped. This was mainly because of the lack of any kind of exception handling in older versions of JScript. However, JScript version 5 implements the try...catch statement, so you need not resort to VBScript just for error handling.

Debugging HTAs

HTAs are difficult to debug, because, unlike HTML pages, they simply crash without warning when they encounter certain types of errors in the page script. This is why we recommend that you design and debug the page as an ordinary HTML page, then convert it to an HTA - by changing it's extension and adding the HTA tag - only when you're sure that your code is bulletproof. This approach is not without it's drawbacks, however, - just because your page runs fine as an HTML document does not guarantee that it will behave the same as an HTA. We will now discuss how you can take steps to ensure that there will be no nasty surprises awaiting you during this conversion process.

Application Window

As we had discussed earlier, HTAs run in their own window, which is an Application window, and not a browser-owned window. This distinction is important because HTAs behave differently from HTML pages when it comes to functions involving windows. A fairly common gotcha is that a browser window opened by an HTA cannot access the HTA using the caller property, because the caller is an application, not a Web page. Also, Anchor tags in HTAs pop up a new window rather than replacing the contents of the current page.

The javascript: Protocol

HTAs do not recognize the javascript: protocol within Anchor tags. This means that if you use <A> tags like this :

<A HREF="javascript:somefunction()">

...you will get a new window with "javascript:somefunction()" in the address bar!

We therefore recommend that instead of using the HREF property of the anchor tag, you instead call it's onclick handler, like this:

<A HREF="#" onclick="somefunction();return false">Some Function</A>.

Since our focus in this series of articles is on Client-side Data Access, we will not focus on other HTA issues like MDI applications, wizards, mouseless navigation, etc. Some of these will be covered in our next series, where we discuss the Explorer Solitaire game. Meanwhile, let us take a look at ADO, the technology that the Level Designer uses for implementing data access.

© 1997-2000 InsideDHTML.com, LLC. All rights reserved.