 | ||
| ||
The power to build HTML Applications (HTA) brings Microsoft® Internet Explorer 5 to the fore as a viable Microsoft® Windows® development platform. HTAs are full-fledged applications. These applications are trusted and display only the menus, icons, toolbars, and title information that the Web developer creates. In short, HTAs pack all the power of Internet Explorer—its object model, performance, rendering power, protocol support, and channel-download technology—without enforcing the strict security model and user interface of the browser.
Historically, programming languages like C++ and Microsoft® Visual Basic® have provided the object models and access to system resources that developers demand. With HTA it is now time to add Dynamic HTML (DHTML) with script to that list. HTAs not only support everything a Web page does—namely HTML, CSS, scripting languages, and behaviors—but also HTA-specific functionality. This added functionality provides control over user interface design and access to the client system. Moreover, run as trusted applications, HTAs are not subject to the same security constraints as Web pages. As with any executable file, the user is asked once, before the HTA is downloaded, whether to save or run the application; if saved to the client machine, it simply runs on demand thereafter. The end result is that HTAs runs like any executable (.exe) written in C++ or Visual Basic.
HTAs are suited to many uses, whether you are prototyping, making wizards, or building full-scale applications. Whatever DHTML and script deliver now—forms, multimedia, Web applications, HTML editors, and browsers—so can HTAs...and then some. Best of all, HTAs make some tasks easier. The simplicity of generating prototypes using HTAs makes it possible for program managers and designers to script dialog boxes and alerts while the C++ or Visual Basic developers program the underlying functionality.
Create an HTA by writing an HTML page and saving it with the .hta file extension. It’s that simple.
This sample demonstrates the simplest possible HTA. It consists of the string, "Hello, World", and is saved with the .hta file extension. Internet Explorer is so forgiving that even the missing HTML and BODY tags do not cause an error.
Hello, World
To launch an HTA, double-click its program icon, run it from the Start menu, open it through a URL, or start it from the command line. Once running, the HTA renders everything within the paired BODY tag and displays the value set in the TITLE tag as the window title.
Where the .hta extension tells the system how to handle the application, the new HTA:APPLICATION tag and attributes tell the window how to behave as an application. This tag exposes a limited set of attributes—attributes that control everything from border style to the program icon and its menu. The majority are read-only and have default values optimized for the average application. To comprise a valid HTA, this tag must appear within the paired HEAD tags.
The HTA:APPLICATION tag in this example specifies application features not available in DHTML. As proscribed by the attributes, this application has neither border (border), nor title bar (caption), nor standard program icon (sysMenu). The application title appears in the Windows task list but not in the taskbar (showInTaskBar), and only one instance of the application is permitted to run at a time (singleInstance). When launched, the HTA is known to the system as "monster" (applicationName) and initially is sized to fill the screen (windowState). For a full list of attributes and properties, and links to more information about each, see HTA Reference.
<HEAD>
<TITLE>My Monster Application</TITLE>
<HTA:APPLICATION ID="oMyApp"
APPLICATIONNAME="monster"
BORDER="none"
CAPTION="no"
ICON="/graphics/creature.ico"
SHOWINTASKBAR="no"
SINGLEINSTANCE="yes"
SYSMENU="no"
WINDOWSTATE="maximize"
>
</HEAD>
Many of the HTA-specific properties that affect the user interface of the window are interdependent. When sysMenu is set to no, not only the program icon, but also the Minimize and Maximize buttons are disabled. When border is set to none, neither the window border, program icon, title bar, nor Minimize and Maximize buttons will display. Finally, when CAPTION is set to no, the Minimize and Maximize buttons, the program icon, and the window border are disabled. These contingencies all make sense in the light of standard Windows graphical user interface design.
As fully trusted applications, HTAs carry out actions that Internet Explorer would never permit in a Web page. The result is an application that runs seamlessly, without interruption.
In HTAs, the restrictions against allowing script to manipulate the client machine are lifted. For example, all command codes are supported without scripting limitations (see command id). And HTAs have read/write access to the files and system registry on the client machine.
The trusted status of HTAs also extends to all operations subject to security zone options. In short, zone security is off. Consequently, HTAs run embedded ActiveX® controls and Java applets irrespective of the zone security setting on the client machine. No warning displays before such objects are downloaded and run within an HTA.
HTA windows can extend the trust relationship to content in other domains. HTAs allow cross-domain script access between window objects and cookies. To address the security risks inherent in cross-domain scripting, HTA enables the APPLICATION attribute for FRAMEs and IFRAMEs. This HTA-only attribute is not the sole security precaution available. HTAs are designed such that FRAMEs and IFRAMEs, where the APPLICATION attribute is set to no, have no script access to the HTA containing them. In this way, no unsecure content is allowed into an HTA through an untrusted window.
HTAs are designed such that untrusted HTML FRAMEs and IFRAMEs have no script access to the HTA containing them. In the case of FRAMEs that are not HTA-enabled, the highest level frame comprises the top window for all FRAMEs it contains. For that FRAME, window.top and window.self are one and the same. In addition, unsafe FRAMEs and IFRAMEs receive neither a referrer nor an opener URL from the parent HTA. The end result is that they are unaware of the containing HTA as the parent window.
In applications where all content is safe, FRAMEs and IFRAMEs can safely be marked as trusted. Wizards and control panels are examples of safe content. The HTA-enabled status of the IFRAME in the example below permits it to pass information back to its parent window.
<IFRAME SRC="filename.htm" APPLICATION="yes">
By contrast, an IFRAME that allows browsing to unsecured content must be implemented as regular HTML. Content in the IFRAME example below is subject to the security setting for its zone. The following IFRAME can be used when embedding HTML.
<IFRAME SRC="filename.htm" APPLICATION="no">
Note The APPLICATION attribute is ignored if used in HTML rather than HTA.
When running HTAs, users should take the same precautions as with any executable: Only install HTAs produced by reliable sources. HTAs cannot be code-signed. However, they can be installed from signed cabinet (.cab) files or other signed installation formats. Either way, the most accountable sources will be corporate intranets and established software vendors.
The Microsoft implementation of HTA is limited to Windows 32-bit systems running Internet Explorer 5. HTAs do not support the AutoComplete in HTML forms feature, or the external object.
The HTA implementation supports multiple deployment methods: the Web model, the package model, and a hybrid of the two. Application developers should decide how best to meet their distribution needs.
The Web ModelThe Web deployment model consists of an application that can be run and administered just like a Web page. In this scenario, the HTA is launched simply by browsing to its URL or by accessing it from the Internet Explorer Favorites list. Before launch, an Internet Explorer dialog box presents the user with the choice to open or save the application. After launch, ancillary application components are downloaded from the server as needed and then cached. Servers must have the MIME type "application:hta" registered for delivery through the http: protocol to work.
This model boasts some important strengths. It facilitates seamless updates: The intranet administrator need only post the new code or content for the client to receive the latest version. It provides ease of use: The user need never install or uninstall the application. Unused applications are automatically flushed from the cache. One important consideration when evaluating this deployment model is that server-based applications cannot be run offline or when the server goes down. One option is to anticipate this eventuality by implementing the advanced channel (CDF) features in Internet Explorer 4.0 and later. For more information, see the Active Channel Technology Overview.
The Package ModelIn the package deployment model, the installation process for the HTA is the same as for traditional applications. Files are copied from disk or over a network, using any installer or self-extracting executable. The installer places the application in the Program Files directory or in the directory selected by the user. A link to the HTA is included in the Start menu. And the application’s dependency on Internet Explorer 5 or greater is registered. This way the user is warned that uninstalling Internet Explorer will disable that application. Look to tools vendors for vehicles for packaging and delivering HTAs to your specifications.
Like the Web model, the package model has points in its favor. The user is prompted only during the initial installation about trusting the application; thereafter, the application runs as trusted code just as an .exe does. Also, the installed HTA is always available to users, whether they are connected to the server or not.
Hybrid Deployment ModelsAny combination of Web and package deployment models is feasible. The method of delivery is transparent to the HTA. HTA components are always referenced as URLs, absolute or relative, so the applications simply work.
Examine Your PrioritiesWhat are your distribution needs? The following list presents just a few scenarios.
No matter what the delivery model, using Internet Explorer as your development platform is a compelling way to build applications large and small.
Did you find this topic useful? Suggestions for other topics? Write us!
© 1999 Microsoft Corporation. All rights reserved. Terms of use.
Back to top