HTML Applications

The previous chapters focused on Web development, but there are times when you don't want your application to look like a Web page with all of the browser components , such as toolbars , exposed. In the past, C/C++, Java, and Visual Basic programmers had the market cornered for traditional Windows applications. With the introduction of HTML applications in Internet Explorer, that has now changed. Now you can use the skills you already have of technologies such as Dynamic HTML (DHTML), Cascading Style Sheets (CSS), and scripting to write fully fledged Windows applications. HTML applications are often referred to as HTAs. This refers to the file extension ( .hta ) that HTML applications use. The full name for the technology is HTML Applications.

What is an HTML Application?

An HTML application is essentially what it sounds like. It is an HTML-based application. The parent process of mshta.exe (the application that actually runs an HTA) is Internet Explorer; so almost anything (we'll talk about exceptions later) that you can do using Internet Explorer 5 or later, you can do in HTA. These functions include scripting, CSS, behaviors, XML, and XSL.

You can control everything that is shown on the screen with an HTA. You don't have to see Internet Explorer menus or toolbars if you don't want them to be present. For example, take a look at the simple application (shown in Figure 16-1) that we'll be using to help us explore HTAs in this chapter. All it does is navigate to a few select sites, but as you can see, this application really doesn't look like it's running under Internet Explorer at all because there are no toolbars or menus present.

You may be thinking that's great, but what about the security warnings that come up when you embed other objects in a browser? The great thing about HTAs is that they are fully trusted applications. All of the restrictions that you worry about with a Web page are not a problem with HTAs. You can, if you want, modify the registry while running an HTA. However, do bear in mind that if you don't have standard security restrictions, you need to be aware of the problems that may arise from your code or another site that is used within the HTA. We'll look into security issues in more depth later in this chapter.

OK, with that covered, the next question you probably have is how do you run an HTA? All you need is Internet Explorer installed (not a problem on most systems as it is built into the Windows operating system), and you're ready. Once you have an HTA created, you can simply double-click on the file and the application will run, just like any other program. Another huge advantage of HTAs is that they can be run from both the server and the client machine, as we'll see later on. This gives HTA technology wide appeal with both client-side and server-side developers.

Figure 16-1: From www.wrox.com . Copyright 2004 by Wiley Publishing, Inc. All rights reserved. Reproduced here by permission.

What Tools Do You Need?

You don't need much to start creating HTAs:

• A text editor-any will do, from the simple but robust Windows Notepad to something more fancy and easier to use, such as UltraEdit32 ( http://www.ultraedit.com )
• The latest version of the script engines (download this free from http://www.microsoft.com/scripting -if you already haven't!)
• Internet Explorer 5 or later (HTAs are supported automatically when you install Internet Explorer 5. Previous versions of Internet Explorer do not support HTAs.)

How to Create a Basic HTA

It's actually very simple to create HTAs. All you need to do is create an HTML file, add the script, and change the file extension of your HTML file to .hta . There are no additional constraints over what you can or can't do.

Let's take a look at an example. We will go through the steps of first creating the HTML file, then a CSS file that controls the formatting of the HTML file, and finally rename the file with the right file extension.

Sample HTML File

We'll start with an HTML file that navigates a frame to a Web site. Since it's a normal HTML file at the moment, it'll have the file extension .htm . There are three < span > elements that, when clicked, navigate the < iframe > (which will act as our viewer).

The three Web sites we'll be using are:

• www.wrox.com
• www. wiley .com
• msdn.microsoft.com

When the page is loaded into the Internet Explorer browser, the Web page will navigate to the Wrox Web site by default and display it.

Sample HTML Application

onclick="Viewer.document.location.href='http://www.wrox.com'"> Wrox

onclick="Viewer.document.location.href='http://www.wiley.com'"> Wiley

onclick="Viewer.document.location.href='http://msdn.microsoft.com'"> MSDN </font> </span> <span style="background-color:#c0c0c0"> <font color="#000000">

Next we have to create the HTA.css file. This CSS file controls the formatting of the HTA file. Here's the code contained in this file.

body { FONT-FAMILY: 'Trebuchet MS'; FONT-SIZE: 20px; POSITION: absolute } span { CURSOR: hand; POSITION: absolute; WIDTH: 15% } iframe { HEIGHT: 95%; LEFT: 15%; OVERFLOW: scroll; POSITION: absolute; TOP: 5%; WIDTH: 80% }

Our style sheet sets the default font as Trebuchet MS with a font size of 20px (pixels). We define positioning as absolute. For our < span > tags, we turn the mouse pointer into a hand.

We refer to a number of size parameters in percentages. This sets the dimension as a percentage of the size of its parent element. If the length of the parent element changes, the length of the child element will be changed as well. Let's say we give the parent element a width of 900px. If the width of the child element is 10%, then the absolute width of the child element will be 90px.

Our completed Web page looks like Figure 16-2.

Although the script may look correct, we do have a few problems. When an HTML file has a < frame > or < iframe >, there are some security restrictions that aren't necessarily obvious right away.

If a frame navigates away from the domain in which the original file is located, the properties and methods of the frame, and the elements within it, are no longer accessible to the parent element. An example of this is once the < iframe > has been navigated to another URL, such as the MSDN site, we can't change the document.location of the < iframe >. In fact the document of the < iframe > is not accessible at all. This is not an error, it is by design.

Figure 16-2: . From www.wrox.com. Copyright 2004 by Wiley Publishing, Inc. All rights reserved. Reproduced here by permission.

Basically, if you try clicking on MSDN or any other link, you will receive an error message. This restriction is there to limit the ability of one site to track your subsequent navigation.

This might not seem reasonable, but let's think about it a little bit more. Let's say that you have search results in one panel of a page, generated from a search engine. The search panel can know where you are going from the < iframe >, but once you get to the site in the opposite frame, the search engine can't track anything else. It's all revolves around privacy issues-do you really want a search engine site to know about everything that you do on the Internet? Probably not!

Turning an HTML File into an HTML Application

Let's try renaming our file from HTA.htm to HTA.hta . This small change now gives our application an entirely different look (as shown in Figure 16-3).

By default, we have a title bar and minimize, maximize, and restore buttons , but we don't have any of the Internet Explorer toolbars. The title bar of the application even picked up the title that we put in.

Figure 16-3: . From www.wrox.com. Copyright 2004 by Wiley Publishing, Inc. All rights reserved. Reproduced here by permission.

Also, you can now navigate to other sites through the main application. That was a quick fix to some painful issues.

Now, that looks great. All we needed to do was change the file extension, and our file is recognized as an application. We don't have to deal with all the security issues any more. But we might want to get rid of the title bar, or have the application launch in full screen.

Well, we can solve those problems, too. Let's look at the HTA:APPLICATION element.

The HTA APPLICATION Element

We want to modify the look of our application even further. Fortunately, there is an HTML element called HTA:APPLICATION . With this tag we can choose not to display a caption, or to maximize the window, as well as a few other things. In our sample application, let's try some of these options.

You can embed the HTA:APPLICATION tag anywhere within the document, but for performance reasons, it's recommended that you embed it within the head of the document. Since the browser parses information in the order that it is found on the page, if you place the HTA element at the end of the document, the browser won't recognize the HTA attributes you've set until it has completely parsed the document. For example, let's say you've sized elements by percentages-by doing this, the browser will now need to calculate these parameters over again.

The HTA:APPLICATION element requires a closing tag.

Because the HTA:APPLICATION element is an empty tag, it can also be closed using the following shortcut.

We'll set the Caption attribute to no and the windowState attribute of the HTML tag to maximize . Now our application loads in full screen mode without a title bar. We can close the application using the Windows task bar.

Sample HTML Application Caption="no" windowState="maximize" />

Wrox

Wiley

MSDN

Do File Extensions Still Matter?

If you use an .htm file extension, but an HTA tag is embedded, will the application act like an HTML application? The answer is no. Without the .hta file extension, the HTA:APPLICATION tag will not be recognized by the browser. The file extension is the only thing that truly defines an HTML application.

Changing Parameters from the Command Line

We will now try launching an HTA from the command line. First, we need to have an ID for our HTA to be able to access attributes of our HTA through script. We are also going to put our caption back in, but we'll discuss that further in the next section.

We'll also create a script that creates an array from our commandLine property. The commandLine property is only available through scripting. It returns the location of the HTA launched and any other parameters specified on the command line. It cannot be specified within the HTA:APPLICATION tag.

You can use this in your existing HTA if you simply replace the existing HTA tag with the following one, and add the script under the new HTA tag.

ID="MySampleHTA" Caption="yes" windowState="maximize">

You'll also need to change your HTML < body > tag to read

Now, when we launch the application from the command line with

d:wroxhtahta.hta www.kingsley-hughes.com

the site will be displayed in the < iframe >. If a specific Web site is not specified at the command line, the default will be MSDN.

Let's just see how we did that. First, this line:

cmdLineArray = Split(MySampleHTA.commandLine)

This creates an array that accesses the commandLine attribute of our HTA and splits it into separate pieces wherever it finds a space. Then, we check to see if the first element of the array is the same as the commandLine attribute of the HTA. If it is, that means that the string had no spaces, which in turn means that no Web site was specified. So we go to the Wrox site.

If cmdLineArray(0) = MySampleHTA.commandLine Then WebSite = "http://www.wrox.com"

Otherwise, we know that a Web site has been specified, so we need to see if it is properly formatted. If we don't find "://" in the second element of the array, we'll add "http://" .

ElseIf InStr(1, cmdLineArray(1), "://") = 0 Then WebSite = cmdLineArray(1) WebSite = "http://" & WebSite

Finally, what if the URL is formed correctly? Here, we assume that if the Else statement is reached, then the command line must contain a properly formatted URL that we can use.

Else WebSite = cmdLineArray(1)

After we've done all that, we send the < iframe > to the Web site we specified.

Viewer.document.location.href = WebSite

And that's it-all done! You have a fully completed and fully functioning HTA file. What you should notice is how the actual representation of your code in the browser changed by simply changing the file extension from .htm to .hta . With a .htm file the browser displays the file as a Web page, but using the .hta extension changes this and the page is displayed as a more stand-alone application.

All HTA APPLICATION Attributes

There are a number of other properties that we can access for the HTA:APPLICATION element. The full list of properties for the HTA:APPLICATION element appears in the following table.

Interdependent Attributes

A number of attributes are dependent upon each other. If the border attribute is not set to thick, the HTA cannot be resized. If the ID of the application is not specified, other attributes of the HTA cannot be accessed.

• If the caption is set to no , then the minimize and maximize buttons aren't displayed, the system menu is not available, and the program icon is not seen in the title bar.
• If the system menu is turned off, then the minimize and maximize buttons are not visible. The icon in the title bar won't be visible either.
• If you choose not to display a border, there is no title bar, and so the minimize and maximize buttons (along with the title bar icon in the title bar) are not visible.

This may seem a little confusing, but the goal is to match the current Windows user interface.

Examples of Interdependency

Let's look at a few examples. We'll start by setting the minimize and maximize buttons, and then add an icon, a caption, a border, and a system menu. We can also see the system menu from the task bar. This is all done by changing the HTA:APPLICATION element as seen next.

Sample HTML Application ID=MySampleHTA icon="hta.ico" caption="yes" minimizeButton="yes" maximizeButton="yes" sysMenu = "yes" border="thick" windowState="maximize" />

This page contains the ActiveX control FileSystemObject.

Let's look at what happens when we try to load this page into the browser. We get a security warning (shown in Figure 16-7) that asks the user if they want to download the ActiveX control.

Figure 16-7

After we answer yes, our page looks like the one shown in Figure 16-8.

Figure 16-8

Let's try adding this page into our HTA and see what happens. We'll add a fourth span that is linked to our new page. For now, everything else will stay the same. Just add these lines under the other three spans .

onclick="Viewer.document.location.href='ActiveXControl.htm'"> Control

When we click on our new span, we see the same security warning. But now let's set our < iframe > APPLICATION attribute to yes .

</font> </span> <span style="background-color:#c0c0c0"> <font color="#000000">

Now when we navigate to our new page, we don't see any security warnings. The resulting HTA should look like the one shown in Figure 16-9.

Figure 16-9

Nested Frames

What if you want to have nested frames? Let's add an < iframe > into the body of ActiveXControl .htm . The source for the < iframe > will be NestedFrame.htm .

ActiveX Control </font> </span> <span style="background-color:#c0c0c0"> <font color="#000000">

Let's create NestedFrame.htm . This file also creates the FileSystemObject . The body of the document contains text. When we try to load the file ActiveXControl.htm , we receive two security warnings, one for each frame.

Now let's try loading the frame from the HTA instead. Since we already changed the APPLICATION attributes of the < iframe > in the HTA to yes , we'll only see one warning; if we hadn't, we'd have seen two. Interestingly, if we set the APPLICATION attribute of the < iframe > in the HTA to no , and the one in the ActiveXControl to yes , we still get two sets of security warnings. This is because the APPLICATION attribute isn't recognized by Internet Explorer unless the parent element is an APPLICATION . For nested frames, the APPLICATION attribute will not be recognized, and will mean the frame is untrusted, if its parent window is not trusted.

Now if we set both APPLICATION attributes to yes , we won't have any security warnings at all, which is a far more desirable outcome.

HTA Deployment Models

HTAs are very exciting, but by now you're probably wondering how you can distribute them.

HTAs can be accessed in a couple of ways, including via the Web and as a package with all of the referenced files in the HTA (in much the same way that you would install a standard Windows application). You can even create a combination of the two. Let's look at all these models in more depth.

Web Model

In a Web model, an HTA can be referenced just as you might reference any other file with a URL. The user is asked to verify that they want to download the file, and no further security warnings occur. The application, and any other relevant files, are downloaded by the browser and cached.

Since the files live on the server, the user will always receive the most recent version when they download it. If the user elects to run from the current location, they don't even need to install or configure anything because the browser will do all of the work. The application doesn't even need to be uninstalled afterwards.

The server does need to have the MIME type ' application:hta ' registered for the file to be successfully downloaded through the http: protocol. Bear in mind that the client machine must also be running Internet Explorer 5 or later to run HTAs, as these are the only browsers that supports HTAs.

Web Model Issues

When you are thinking about running the application from the server, there are a few things to consider:

• Since you have to go to the server to retrieve the application, the application isn't available when the user isn't connected to the Internet. If your network isn't that reliable, that is certainly going to be an issue.
• If you aren't on a high-speed network, and particularly if your application is large, the speed of your application is going to suffer. While DSL and ADSL are starting to replace standard modems, the new technology hasn't reached everyone yet.
• Every time the application is run, the user is prompted with a screen about downloading the file. This can get pretty frustrating if the application is started frequently.

However, on a high-speed corporate intranet where all users have the latest Internet Explorer, the Web model is extremely useful. Changes can be made to code without any of the hassles that are seen with traditional Windows applications.

Package Model

An HTML application doesn't need to run through the Web. In many cases, that's not necessary at all. All that is required is to have Internet Explorer 5 or later installed. Since an HTML application is a set of files, the files can be installed on a user's local drive or even at a network location. If your application doesn't contain custom ActiveX controls, you can use a simple zip file to place the files on the client's machine.

If you do have custom Active X controls, you will need to register them. You could use applications such as Wise or InstallShield to register controls and create an installation process.

The advantages of this model are that you don't need to be online, the application will run faster, and you don't need to deal with security warnings after the initial installation.

Package Model Issues

The disadvantage of using a package model is that the updates are not automatically transferred to the user like they are in the Web model. You would need to manually update the files on the local machine.

Also, if you do have ActiveX controls to register, you will need to provide a way to uninstall the controls. If you choose to install controls, you will probably want to use programs that have uninstall utilities, such as Wise or InstallShield.

Hybrid Model

You can also combine the two models, forming a kind of 'hybrid' model. You can install part of the application locally, and part of the application on the server. Anything that you want to reference on the server, such as images, style sheets, sources for frames , XML data, and so on, can be referenced from the HTML application on the client machine.

Our example application could be seen as a kind of hybrid-model HTA, as it accesses URLs on the Internet, while the application and corresponding style sheet are stored locally. Using an approach such as this one may better meet your needs.

For example, if your concern is speed, you might choose to store larger files locally. If you want to limit the number of updates that are manually sent to the user, you might choose to make the HTA file itself a fairly simple file, possibly by using frames that have their sources on the server. That way, any content changes can be made to the frame files in their central location.

What Isn t Supported with HTAs?

Many of the references on HTML applications state that all of the features available in Internet Explorer 5 or 6 are also available in HTAs. This isn't entirely accurate. For example, the HTA doesn't know anything about the application or site that launched the HTA. As a result, there are a number of properties and methods of the window object that aren't available within the HTA.

The Window Object

The window object's opener property is not available to the user . The external property (which normally allows the window access to its referring window) is also unavailable, as is the menuArguments property.

Most of the methods that aren't available are those that would give the HTA unreasonable access to other programs, like Internet Explorer. Since an HTA is in fact an application, it makes sense that the user wouldn't have access to another application, even Internet Explorer.

Here's a list of the unavailable methods in HTAs.

Default Behaviors

There are also a few default behaviors in Internet Explorer that are not available within an HTML application. As in the previous section, they are related to browser modifications and involve data storage by the browser.

These include saveFavorite , saveHistory , saveSnapshot , and userData .

Summary

I'm sure by now you will feel pretty good about using HTML applications. They provide a simple way to get the most out of HTML and script, and they give you even more control over the user interface of your application.

HTML applications are a powerful technique for quickly developing Windows applications. They provide a great way for HTML and other programming languages to come together. HTAs are also a good way for you to use your skills on both the server and client machines. The problems that surround standard security warnings that are usually encountered with browsers are now a thing of the past.

In addition to creating full-blown Windows applications, HTAs are an excellent tool for prototyping. Application designers can easily build an interface, and demonstrate the interactions that they want built without having to learn a complex programming language like C++ or VB.