Tutorial

Active Server Pages (ASP) is a well known server side scripting technology. We will explain how this web technology can be emulated entirely on a Windows client machine from within Internet Explorer (IE) and Internet Explorer ActiveX webbrowser controls (IEX controls) using custom IE pluggable protocols and Windows Scripting to turn IE into an interactive programming environment. We will also examine how we can use content storage files for use with HSP.

The use of embedded Internet Explorer ActiveX controls (or IEX for short) can enhance Windows programs very powerfully. The ability to easily add multi-media content to your Windows programs is quite compelling. trying to place graphics and tabular data using C++ or even VB is quite a bit of effort. There are many issues with placement, resizing and a range of other messy problems. Using the IEX webbrowser control to easily display HTML content can be quite compelling. Furthermore, HTML content can be changed without recompiling your program. This can be quite advantageous indeed. Microsoft uses IEX with HTML content in limited amounts in products and tools such as Outlook (and Express), and MMC.

One of the major drawbacks to using embedded web browser controls is that they can only display static content. That is, until now. HTML Scripting Pages, or HSP for short, is the first and only product to actually run ASP pages on the Windows client machine in a plug-in DLL. No longer are webpages doomed to only display static webpages. With HSP, webpages can be seamlessly generated on the fly within either the Internet Explorer webbrowser or embedded IEX webbrowser controls. You can actually run "browser applications" (analogous to a web application) right inside Internet Explorer entirely on the Windows machine with no Internet connection. This ability has tremendous implications for Windows programmers. Suddenly, an entire new programming/display methodology is opened up. We will explain HSP thoroughly in the paragraphs below.

But even with HSP, there two other issues which may stop someone from embedding IEX controls and ASP/HTML content in their Windows program. The following identifies the problems and how EzTools' products solve them.

Problem 1: File Proliferation

File proliferation is simply when the file count of your application distribution gets too high. Typically, a webpage is not simply a single file, but many files (such as graphic files), that are referenced by the webpage. Shipping several "raw" HTML files with your product is potentially a bad idea because: 1) it can dramatically increase the "file count" of your product. 2) if any of these files are accidentally deleted, it may be difficult to ascertain which they are, and 3) raw files can be tampered with or viewed by end users thus exposing your intellectual property. All of these are good reasons not to use them. But there is a perfect solution to this problem. That is, the use of content storage files and pluggable protocols. We will also deal with content storage file security.

Problem 2: Webpages Can't Interact with Application

You should be able to detect mouse clicks on the webpage links and buttons and be able to pass them through to the containing application code (in the form of COM events) so you can respond to them outside the scope of the IEX control. This is necessary so your webpages can reach outside the scope of the webbrowser control. You would also want to be able to disable the right-click Context Menu and accelerator keys as well. We will see how we can detect mouse-clicks (and other HTML events) in webpages and pass them through to the containing application. We will see how to put all of these new technologies together to form a new and unique programming paradigm.

Besides the fact that IE doesn't natively pass through HTML events, amazingly you cannot set the window border to be on or off, nor can you set the style to be 3D or flat - its always 3D! We will show you how EzTools' products solve all of these problems, letting you to "have it your way". To write Windows programs that make effective use of embedded IEX controls, you will need all of these features.

Pluggable Protocols

IE uses pluggable protocols to obtain all of its content. Whenever you type a URL such as

http://www.microsoft.com

IE looks up the http pluggable protocol Registry entry and loads the appropriate COM object to go get the content. It is entirely the job of the pluggable protocol to get the specified content resource, the way it knows how according to its protocol. Once the resource data has been retrieved, the pluggable protocol feeds it back to IE. The HTTP pluggable protocol uses HTTP to get the resource. The FILE pluggable protocol uses the file system to get the resource. FTP uses the FTP pluggable protocol, and so on. We will see you can use a custom pluggable protocol to read content from a special file called a content storage file.

EzWeb Compiler and Content Storage Files

EzWeb Compiler is an application program that provides a User Interface (or UI) for creating content storage files. A content storage file is a sort of file database for storing multiple files in a single file. You create a content storage file by dragging and dropping your HTML content files from Windows Explorer onto a treeview in the EzWeb Compiler app. As you drop files and folders onto EzWeb Compiler, they are copied into a storage file, maintaining the same hierarchy as your file system. You can create your own hierarchy as well. EzWeb Compiler has an embedded IEX control that displays the content files as you select them. To do this, it uses its own pluggable protocol developed for it. The EZSTOR pluggable protocol knows how to read the EzWeb Compiler content storage file. When you select a file, EzWeb Compiler tells its IEX control to navigate to the file using the EZSTOR pluggable protocol.

So now you can specify the EZSTOR protocol to load a WebPage stored within an EzWeb Compiler file. It has the following syntax:

ezstor://drive:\filepath\filename.ezs/internalpath/htmlfilename

Example:

ezstor://c:\myezhfile.ezs/myhtmlfile.asp

You can do this either programatically (using the Navigate method of IEX) or type it in the address bar of IE.

OK, at this point you have two tools that enable you to safely store your HTML/ASP/graphic content in a single content storage file (EzWeb Compiler files) to be able to be read by embedded IEX controls in your Windows programs. You can stuff all of your content files into a single file to be shipped with your product, along with the EZSTOR pluggable protocol DLL.

Using EzWeb Compiler and and the EZSTOR pluggable protocol DLL we have solved problem number 1 - file proliferation. But the EZSTOR pluggable protocol will only display static webpages. If your application only requires static pages, then this solution is all you need.

Dynamic Webpages with HTML Scripting Pages

Displaying static HTML webpages in your apps is pretty good. You can do quite a bit with static webpages. But we can take it a huge step further and have dynamic webpages using a new technology named HTML Scripting Pages, or HSP for short. HSP is a client-side, ASP work-alike. Think of HSP as IE + pluggable protocols + Windows Scripting. HSP is implemented in its own pluggable protocol DLL, so it works seamlessly with IE. It uses Windows Scripting (aka Active Scripting) to execute script code embedded within HTML pages, just like server-side ASP. The difference is that it all takes place on the client machine - there is no webserver involved.

The HSP pluggable protocol works the same as the EZSTOR pluggable protocol, except that it runs ASP pages as well.  It read from EzWeb Compiler files the same way.  By convention, we name EzWeb files with .hsp extension, and EZSTOR files with .ezs extension. This graphic shows HSP being used by IE:

HSP uses most of the same objects as ASP (eg. Session, Request and Response, Server). Each object has most or all of the same properties and methods of its ASP counterpart. The reason not all objects, methods and properties are implemented is simple: They are not needed in a client-only, single user environment.

HSP works with any Windows Scripting engine that supports scriptable COM objects (IDispatch). HSP only looks for script in files with the .asp extension.

Hello World

Suppose you have an HTML file with the following line in it:

Hello <% Response.Write "World" %>

When loaded by IE, this would be displayed:

Hello World

If you had a QueryString or Form value passed with a user name, you could write:

Hello <% Response.Write Request("UserName") %>

or just

Hello <% = Request("UserName") %>

HSP and EzWeb Compiler

HSP's pluggable protocol is HSP. You load an HSP resource in the same way as any other pluggable protocol:

x-hsp://c:/myproj/myfile.hsp

When IE sees the HSP protocol specified, it loads the HSP DLL and calls a COM object to retreive the specified resource. The HSP protocol knows how to read EzWeb Compiler files just as does the EZSTOR protocol. Although HSP will open and execute "raw" files files from disk, that is not the way it is used in your deployed applications. Rather, you should stuff all of your HTML, graphics, ASP and other content files into an EzWeb Compiler file (using the EzWeb Compiler tool). We do this for the reasons outlined above. But now that we have executable program code in our files, it becomes even more important that end users don't tamper with them.

Note: You can take advantage of the new VBScript Classes - COM classes implemented entirely in VBScript - to write reusable classes in your HSP code. Quite a powerful feature.

WOW

So we are now displaying static or dynamic HTML content in our Windows programs, and, thanks to pluggable protocols, the content is retrieved from neatly bundled content storage (EzWeb Compiler) files. That's a big step forward. Now suppose you wanted to activate program functions from mouse-clicks on the webpage - a function that is outside the scope of IE. For example, when you open Microsoft Outlook, and click "Outlook Today", you are shown a webpage in the right-hand window pane, with links and graphics on it. Clicking on a link activates the corresponding program function. The IEX event model doesn't pass through mouse-clicks, so how is your application code going to know when a link is clicked? The WOW control (WOW is for Web On Windows) handles this by wrapping the IEX control to pass these events through to your program as a COM event. WOW can actually trap any HTML event. Now, when the user clicks on a link you could activate an internal program function such as displaying a dialog window, or changing forms, or whatever. WOW lets you use the IEX more as a classic ActiveX control that interacts with its container program.

This feature is very important. There are situations where you just can't do without it. Besides this feature, WOW gives you the ability disable the Context Menu and any or all accelerator keys, another important feature.

Security

EzWeb Compiler has built-in security features that can make it impossible for unauthorized or unlicensed persons to open, execute or examine the contents of your EzWeb Compiler files. Without security, anyone would be able to run your HSP application. Also, anyone with the EzWeb Compiler Viewer could view the contents of your HSP EzWeb Compiler files, including your source code. EzWeb Compiler's licensing feature allows you to copy protect your HSP files so that they can only be run on licensed machines.

EzWeb Compiler has two levels of security: Password and Machine License. EzWeb Compiler allows you to set a password on your storage file, so that it cannot be opened unless the correct password is supplied. You can also set a Machine License, so that the file cannot be opened or run unless a license key is detected on that machine. To do this, the EzReg product is required. You might require a password or machine license if you sell your HSP program (for example if you produce educational courseware) that you need to copy protect to guard your content, product and revenue.

Conclusion

These technologies introduce a totally new programming paradigm that, though Windows centric, can be used in a variety of applications on a large installed base of computers. All Windows machines have Internet Explorer installed, and the latest version can be obtained from Microsoft for free. The Windows Scripting DLLs are also free and readily available from Microsoft. Being able to write a secure, copy protected executable program that can run in the IE browser or in your own custom programs is quite an interesting prospect. The web browser actually becomes a sort of programmable whiteboard for a wide variety of uses, using HTML and VBScript. Only EzTools' integrated products give you the ability to do it.

This article is copyrighted by EzTools - 2000-2002. All rights reserved.