Fog Creek Software
Discussion Board




HTAs..Tell me more

Li-fan Chen mentioned HTAs in a previous thread. Ive never heard of those before. Ive read through the intro and reference on MS homepage and I must say that it looks like a very usefull thing, for smaller apps anyway.

Ive searched the web for tutorials, but there doesnt seem to be alot of info out there about this, which is kind of weird. Is there some major drawback I should be aware of besides a cetain lag with some operations?

What Im wondering right now is:
1. What objects are accessible besides the standard scripting objects? Can I use an activeX grid control or rich text box?

2. Can I open a direct ADODB.connection to a remote database?

3. Can I use res dlls or something to bundle the graphics?

4. Can I compile or ecode a HTA in some way to make the source inaccesible.

5. Can I make it look like a regular exe?


Im very grateful for any info.

Eric DeBois
Friday, July 11, 2003

An HTA is a "web page" which runs without any of the security restrictions that web pages "from the web" run with. 

That's pretty much it.  There's no compilation model -- it's just a web page that's not actually from the web. 

Eric

Eric Lippert
Friday, July 11, 2003

I believe that Microsoft expected HTAs to be more widely used than has turned out to be the case (similar to the lack of interest in their vector graphics language, VML).  Partly this may be due to the implication of HTAs in some computer virus hacks--as mentioned, html applications are trusted once they are installed on your hard drive.

Like exes and other trusted apps, users are not alerted when activeX objects are present, and there are many activeX controls available for such uses as web graphics, spreadsheets, etc. at reasonable cost.  Checking with Google or some other search engine will enable you to find what you want.

The controls already installed in Windows, such as the Windows Shell and WSH FileObjectSystem, have been very useful to me for maintaining state of applications by read/write access to text files, and for launching other apps from html pages.  I prefer not to use HTAs as such, however, because so many administrators are wary of them; instead, I use a so-called html compiler which saves the html pages as a packaged exe file, and has the added advantage of being encrypted and compressed.  For a look-see check this link:

http://www.x2net.com/webcompiler/index.htm

My application is for e-learning; I'm not actually a programmer, but have learned enough Javascript and html to understand how to put the application together.

Best wishes in your endeavors.

Jim McCarty
Friday, July 11, 2003

Oops! That's FileSystemObject.

Jim McCarty
Saturday, July 12, 2003

HTAs are very useful. Interestingly many of the little control panel wizards in Windows XP are actually HTAs. eg, The "User Accounts" applet is an HTA. If you look in Task Manager you'll see the mshta.exe process which is the host for HTAs. In fact you can attach a script debugger (such as the one in VS.NET) to mshta.exe and then peruse the HTML JavaScript etc that makes up the User Account applet, etc (look at the Running Documents pane).

We use them for our setup program. Currently I just have a 3 line C++ app called Setup.exe that calls ShellExecute() to lauch the actual guts of the setup which is an HTA in a subdirectory. Each of the steps of the wizard is a plain old HTML page, which is hosted inside an <IFRAME> in the HTA. So that the code in the IFRAME is trusted and can do stuff with FileSystemObject, ADODB, WScript.Shell etc make sure the you do <iframe ... application="yes"... >.

Now then next thing I'm doing is packaging all these pages into the EXE itself. This is easy because you can store HTML, GIFs etc within the payload of the setup.exe as resources and access them via the res:// protocol (you might have seen this when you get error pages in IE). So the HTA and html pages that make up my wizard, are launched using something like this in setup.exe:
  ShellExecute(..."mshta.exe", "res://<path>setup.exe/setup.hta"...)
So now the setup wizard is just a single exe without having all of the pages "out in the open" in a folder.

If I need to do stuff for which there isn't a readily-available, OS-installed COM object then I can put custom C++ code in the setup.exe and communicate by using command-line arguments via WScript.Run() and it (rather crudely) returns data via temp files in the %TEMP% directory. I didn't want to faff around with registering COM objects on the target machine in order to do some simple RPC.

Duncan Smart
Saturday, July 12, 2003

Hey Duncan, if you want quick-and-dirty-no-need-to-register COM objects, you can use Windows Script Components.  A WSC is a dispatch object written in a combination of script and XML.  You can either register one like a regular COM object, or you can cocreate it via its moniker.  Creation via moniker doesn't hit the registry.

Eric

Eric Lippert
Monday, July 14, 2003

Interesting idea Eric - I'll give it a go.

Duncan Smart
Monday, July 14, 2003

Actually, just thought - what I want to do is actually call C++ code which in turn makes API calls, ie I want to be able to do a couple of things that scripts and the standard COM components can't.

Duncan Smart
Monday, July 14, 2003

Thanks for the info everyone. Just what I needed.

Eric DeBois
Monday, July 14, 2003

*  Recent Topics

*  Fog Creek Home