[ Go to July 1997 Table of Contents ]

Programming Windows /
Martin Heller
Martin Heller

HOW TO ...

Optimizing Windows / John Woram Going for a (Hard) Drive

Applications/Jim Boyce Every Picture Tells a Story

Power Windows / Karen Kenworthy Steer It Toward the Web

Windows CE / John D. Ruley Make Your CE Connection

Windows NT Workstation / John D. Ruley A Deep Dark Truth About NT

Programming Windows / Martin Heller Serving Up ActiveX Pages

Serving Up ActiveX Pages

This month, let's explore the other side of programming Web applications. The Web server side, that is.

The biggest problem with using client-side tools like ActiveX controls, Java applets and scripting is they won't work on all browsers. I discovered that while testing the Internet Connection Tester Web application I wrote about in my last two columns.

The Internet Connection Tester I built tests the connection between the user's computer and a variety of Internet sites. It runs on the client, so I used client-side ActiveX controls and client-side scripting to make it. You can find it at http://www.winmag.com/people/mheller/pinger.htm. It works if you view it with Internet Explorer 3.0x running on Windows 95 or Windows NT on an Intel CPU. It won't work from the 16-bit America Online browser, a Macintosh, a UNIX box, a network computer or any of the RISC versions of Windows NT. If you run a special conversion, it may also work in Netscape Navigator with the NCompass ScriptActive plug-in installed. Otherwise, it won't even work from Netscape.

The Connection Tester isn't a critical line-of-business application. It's useful for people with the right client software, but hardly mandatory. Suppose, though, that I were writing an application to take subscriptions to WINDOWS Magazine? I can pretty much guarantee that the magazine's management wouldn't buy a line-of-business application that would only work properly for 20 percent of the people who tried using it, no matter how persuasively I argued the glories of ActiveX.

No, the ground rules for an application like that would be that it had to work on the lowest common denominator of browser features. I'd certainly have to make it compatible with browsers that don't support HTML tables, HTML frames, Java applets, JavaScript, VBScript and ActiveX controls.

The only way I know to accomplish that is to do some programming on the Web server side. It could be done with Common Gateway Interface (CGI) programs or scripts, it could be done with Internet Server application programming interface (ISAPI) applications, and it could be done with server-side scripting. Over the last year I've delved into CGI and ISAPI several times in this column; this month I'd like to move on to Microsoft's Active Server Pages (ASP), a feature of Internet Information Server (IIS) 3.0.

ASP is intended to simplify server-side programming by adding support for server-side scripting and server-side objects. It is implemented as an ISAPI filter, which IIS applies to pages with the ASP extension. ASP pages can combine text, HTML tags and scripting commands.

In developing the Internet Connection Tester over the last couple of months, we saw that scripting with Component Object Model (COM) objects can be a viable way to develop client-side applications. ASP takes that same model and applies it to the server side.

Well, almost the same model. As always, there are twists. It's never enough to just translate the model-you have to expand and adapt it for the new environment. For one thing, ASP server-side scripting has to coexist with client-side scripting. The combination is handled in two ways: with a new RUNAT=SERVER attribute for the HTML <SCRIPT>tag, and with the delimiters <% and %>. The latter are what you'll use for most scripting; they mark regions of the default scripting language for the current page. There's a special form of the <% %> delimiters for returning values from the scripting language: <%= value %>.

Let's say I want to put the current viewing date on a Web page. A VBScript Date function can return the value. So I can interleave text with ASP VBScript code like this:

Today is <%= Date %>.

This code will cause the browser to display:

Today is 7/4/97.

That's assuming, of course, that you're browsing the page on July 4.

Maybe we should take a step back. How can we get the user into our ASP application to begin with? On IIS servers, the default document is typically set to DEFAULT.HTM, meaning that a reference to http://www.winmag.com/people/mheller actually brings up the HTML document DEFAULT.HTM in my Web directory. Documents with the HTM or HTML extensions are normally treated as containing pure HTML, are not preprocessed by the ASP filter and will not have their server-side scripting code expanded out.

If you use only ASP applications, you can change the default document for the server to DEFAULT.ASP. Even then, you won't catch people who have bookmarks to DEFAULT.HTM. So ASP authors usually set up a DEFAULT.HTM that contains little more than a REFRESH meta-tag:


This will cause most browsers to "pull" MYAPP.ASP as soon as they can. By the way, the directory tree an ASP file is in must have Execute permission, because the server executes the file each time a browser requests it. Generally, most sites set both Read and Execute permissions in the directories so that other files such as GIFs or Java applets can be placed there as well.

When a client first views an ASP page in a directory, the server opens a session and fires a Session_OnStart event. If this is the first session for this application since the server started, an Application_OnStart event occurs first.

The server looks for code to process these events, and their matching _OnEnd events, in the file GLOBAL.ASA, located in the application's root directory. The GLOBAL.ASA file can also contain <Object> tags for server-side COM objects that you wish to have application or session scope-in other words, objects you'd like to persist until the server shuts down (application scope) or until the user leaves the application (session scope). There's a time-out to determine when the user has really left the application.

Once the _OnStart events fire, the execution flows to the ASP file requested-in this case, MYAPP.ASP. At this point, a Session object exists with a unique session ID, and a Request object exists with fully parsed collections of the values the client browser passed to the server during the HTTP request along with the server environment variables. Having all the information you need in the Request object is a lot more convenient than having to parse URL-encoded queries, as you would in a CGI program.

ASP and forms

Like all Web pages, ASP pages can contain HTML forms. What's different is that ASP pages can also process form output. You can set the action of a form to be the page it's on or another page-whichever is more convenient and maintainable. If the form's method is POST, the form's output will be parsed in the Request.Form collection; if the form's method is GET, the form's output will be parsed in the Request.QueryString collection. These collections can be addressed by variable name, so that the value of a posted form variable called lname can be retrieved into a VBScript variable by:

<% LastName = Request.Form("lname") %>

Most often, you'd like to add the parsed output of a form to a database. ASP includes a Database Access component, which uses ADO (ActiveX Data Objects). ADO works with any OLE DB or ODBC database and also takes advantage of ODBC 3.0 connection pooling. The implementation of ADO for OLE DB is the ADODB object.

ADO revolves around the Recordset object. You can create a fully functional, scrollable Recordset bound to an ODBC data source in just a few lines of VBScript code:

set rs = Server.CreateObject("ADODB.Recordset")
rs.Open "SELECT * FROM authors", _
adOpenKeyset, adLockBatchOptimistic

Once you have an open Recordset, you can traverse its records with the MoveFirst, MoveLast, MoveNext and MovePrevious methods. Within a record you can retrieve and set field values by field name or ordinal from the Fields collection, and write to the database with the Update method. For instance, displaying the author name from the current record in the rs set is no big deal:

Author: <%= rs("authorname") %>

Recordsets work over connections to the database and rely on SQL database commands. In the sample above, the command is "SELECT * FROM authors", and the connection is created implicitly when the Recordset opens. You can also create connections explicitly and create Recordsets implicitly by executing commands on the connection.

It's time for you to look at an example. If you already have ASP installed, try playing with the Adventure Works Catalog sample and viewing the ASP source for each page. You'll find the sample on your Active Server Pages Roadmap. If you don't have your own Web server installed, you can find Adventure Works at http://iisb.microsoft.com/AdvWorks/default.asp. If you have some version of IIS installed, you can download the IIS 3.0 update to ASP from http://www.microsoft.com/iis.

What are you waiting for?

Martin Heller writes about and does Windows programming from Andover, Mass. Contact Martin in the WINDOWS Magazine areas on America Online and CompuServe, or at the e-mail addresses here.

Back to Top

Windows Magazine, July 1997, page 263.

[ Go to July 1997 Table of Contents ]