|
|
|
 |
Magazine |
| | Community |
| | Workshop |
| | Tools & Samples |
| | Training |
| | Site Info |
 |
 |
||||||||
|
|
||||||||
|
|||||||||
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, protocol support, rendering power, 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. The end result is that HTAs are treated like any executable (.exe) written in C++ or Visual Basic. In short, the user is asked once, when it is downloaded, whether to trust the application; thereafter, it simply runs on demand.
HTAs are suited to many uses, whether you are prototyping, making wizards, or building full-scale applications. In other words, 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 dialogs 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. Its 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 application icon to system 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 system menu (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). See HTA Reference for a full list of attributes and more information about each.
<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>
Some of the HTA-specific attributes are interdependent. For instance, disabling the System menu or setting the border to none disallows use of the Minimize and Maximize buttons—see the minimizeButton and maximizeButton properties. By the same token, setting the CAPTION or the BORDER attribute to no disables not only Minimize and Maximize buttons, but also the System menu and border. 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.
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 TRUSTED attribute for frames and IFrames. This HTA-only attribute is not the sole security precaution available. HTAs are designed such that untrusted frames and IFrames have no script access to the HTA containing them. Access is blocked because they comprise their own top window, with no referrer or opener URL. In this way, no unsecure content is allowed into an HTA through an untrusted window.
In applications where all content should be safe, frames and IFrames can safely be marked as trusted. Wizards and control panels are examples of safe content. Its trusted status enables the IFrame example below to pass information back to its parent window.
<IFRAME SRC=sURL TRUSTED="yes">
By contrast, an IFrame that allows browsing to unsecured content must be marked as untrusted. The following IFrame can be used when embedding HTML.
<IFRAME SRC=sURL TRUSTED="no">
Content in the IFrame example above is subject to the security setting for its zone. And the IFrame is unaware of the containing HTA as the parent window. In an untrusted frame or IFrame, window.top and window.self are one in the same, so the page has no script access to the parent HTA.
Note The TRUSTED 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.
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 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. See the Active Channels overview for pointers to more information.
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 applications 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.
Does this content meet your programming needs? Write us!
© 1998 Microsoft Corporation. All rights reserved. Terms of use.
Back to top