How CGI Apps Differ from "Typical" Visual Basic Apps
As I mentioned in the introduction to this chapter, writing CGI applications is a completely different animal than writing most Visual Basic applications. This section discusses some of the major differences that you must keep in mind when writing an application that your Web server will launch. If you forget these differences, your application will probably leave the Web surfer wondering why the browser displays the Document returned no data message when the Submit button is clicked!
Waiting For Response…
One of the most important things to keep in mind is that while your program is executing happily on the server machine, the user is staring at what might as well be a blank screen. The typical Web browser application (also referred to as a user agent), displays a message in its status panel to the effect of Connected to www.xyz.com...Waiting for response.... The cursor is the hourglass cursor, further emphasizing to users that they're on hold. Therefore, CGI applications must do their thing and return control to the Web server as quickly as possible. The program should avoid using any but the quickest methods of accomplishing what needs to be accomplished.
For instance, you should avoid attempting to start a slow OLE automation server. If the application attempts to create an Excel spreadsheet object, stuff data into it, analyze the data, export the spreadsheet to a Word document, and then return the Word document to the user, the client will probably produce a time-out error-unless, of course, your Web server is running on a machine with an ultra-fast motherboard and hard drives. Unfortunately, there are no "rules of thumb" for what you should and shouldn't do. Only experimentation with the application will reveal how fast or slow it operates.
The Sluggish Net
Another item to keep in mind while we're discussing speed is the speed of the user's connection. If your application returns complicated Web pages with lots of graphics on them, you'll want to connect to the server and try the application using a 14.4Kbps modem. This simulates not only the typical user's connection, but also a fast T-1 connection from across the country. As the Internet becomes more and more crowded, even fast access points slow down as the user traverses the continent, hopping from network to network before finally reaching your server.
This is not a concern for CGI applications only-when designing a Web site, you should attempt to design for the lowest common denominator. If you can afford separate sets of pages for users with fast and slow connections, the effort is usually very much appreciated.
Do Not Allow for Interactivity
Perhaps the most important item to keep in mind is this: No one is there to click the OK button on a message box that a CGI application might open. This is particularly true on Windows NT Web servers that run as a system service. For debugging on a Windows 3.x or Windows 95 Web server, such interactivity might work. However, unless you want to sit by the machine while the Web server is operating and click OK, make sure you remove all possibility of having a message box appear.
If you're running a Windows NT Web server, such as the Microsoft Internet Information Server, the problem is even more severe. A CGI application that causes a message box also more than likely causes a time-out error on the client or returns no data if the server realizes the app is effectively dead in the water and times out first.
If you use common code modules, comb through them to make sure they contain no user interface code.
Use Tighter, Centralized Error Control
Make sure error trapping is turned on in the Sub Main routine and that, if errors are trapped separately in procedure and function calls, that no message boxes will display! It is best to use a central error trapping mechanism: The only ON ERROR... statement should be in the Sub Main procedure. This provides you with the ability to control exactly what code is executed when an error occurs. It also helps eliminate the possibility of an object requiring interaction being opened. The examples you'll build later use this type of error trapping.
Tip
