SCGUI over a network - A demonstration

Updated: 6/20/01

You can run SCGUI over a network. (After all, SCGUI means "server-controlled GUI".) The demonstration program uses a Python script to give HTTP access to the SCGUI browser (VB). Ideally, an HTTP control (OCX or Active-X) would be installed into the browser to increase response time, but I wanted to keep the demo free of charge.

These instructions assume some programming background and familiarity with the Windows operating system. They also assume knowledge of Windows web servers.

A server application called "scgui1.asp" is the server-side script that is used to run a demonstration application. This script uses an include file or two, and an "MDB" database file called "data1.mdb". The script assumes they are all in the same directory.

Hypothetical Spam-A-Matic

The sample application is a hypothetical junk-mail (spam) service provider application. (Somebody has to automate that stuff :-) It has a database containing companies that want to send mail or e-mail messages, and a table with details about their targets (spammees).

I originally planned to use two grids to list the spammers and their corresponding spammees (a typical header-detail application), but I had to scale back. Instead I use two drop-down pick-lists. The user can use these to bring up the detail fields of any spammee. (Examples shown later.)

Installing the Communications Utility

The communications utility can be started up by running the "startup.bat" file or letting the browser start it. You must install Python first and have startup.bat reference the needed directory or environmental setting to access the Python interpreter on your machine. You may have to alter startup.bat to achieve this. See the download links page for a link to the Python site. (Instructions for installing Python are not included here.)

There are two ways to start the comm script. The first is to directly run "startup.bat". The second is to let the SCGUI browser start it by pressing the "GO" button. You must also have "auto-start comm util." check-marked. Which-ever approach you choose, make sure not to run duplicate copies of the comm utility. (It does a check for an existing instance before launching a new one, but I make no guarantees.)

Typical running instance of comm script (in a DOS window)

The comm utility will poll (ask) the SCGUI browser for message files every few seconds. (You are welcome to adjust the poll frequency in the script via the "sleep" function. However, the faster it is, the more potential for problems.)

If you use the "auto start" feature, you may want to change the settings of your default DOS prompt so that it does not automatically close when execution is finished. Otherwise, you may miss Python error messages. (DOS prompt configuration steps vary per OS version.)

Communication between the web server and the comm utility can be analyzed via the "logfile.dat" file. Avoid "http://" in URL's. The Python libraries don't seem to like it.

When the Web Demo Starts

The loading of the demo will take roughly 8 seconds, depending on your machine.
The Python interpreter and the web-server sometimes take a while to load (if local). You can monitor the steps and messages by looking at the comm utility's DOS window if you want to know where any loading or speed bottlenecks might be.
Note that more is being loaded than just the first screen. Another screen is also being loaded, it is just not made visible until later. The web application does not have to pre-load screens. It is just the way this particular application did it.

Pre-loading forms may save update time later because only the changes (data contents) have to be sent, and not the entire form. This is an advantage SCGUI has over HTML forms. The same "page" can be re-used rather than sent from scratch.

When demo first loads

Picking from 'Company' list

In the future, the drop-down lists may be replaced with grids.

This demo assumes you select company 4, "Dot Gone Domain Sellers, Inc." Pressing "Get Recipients" should result in a hour-glass (wait state) until the bottom list is populated. It gets the recipient list from the server.

A company is selected, resulting in recipient list being populated.

The Detail Screen

Pressing the "Edit" button on the selection screen should result in the "Detail" form after a few seconds.

Detail form

Asynchronous Responses

This demonstration shows of one of the more interesting aspects of SCGUI. We can have it do data validation in the background (non-intrusive) while filling out the form. The browser can send and receive information without interrupting the user if non-wait events are used.

On the detail form, blank out the "City" field and casually move to the next field (or any field besides "City"). In this example, we blank City and move to the State field.

Asynchronous validation

Notice how a warning message appears near the bottom of the screen. This is a "casual message" in that no "OK" nor "Continue?" prompt pops up.

Unlike typical web forms, which sit idle with regard to server communication until "Submit" is pressed, content of fields and event data can be sent to the server during the middle of the data entry stage; and the browser can also receive information. This is "asynchronous communication" in that both sides don't have to stop what they are doing (accepting user input) and wait for a response.

This approach is not meant to be the final validation; for a final check is still done (on the server) when our Save button is pressed.

The warning messages are not cleared in this example when fields are corrected, unless another warning is issued for another field. I will leave the implementation of clearing as a reader's exercise. Remember that this is to be controlled via the web application, and not the SCGUI browser.
You can try this with other required fields. (About half of them are required.) Note that it only sends the contents of a field when the cursor moves out of the field. This is because it is implemented using the "onHop" event. Here is a sample of the XML sent from the server when the form was generated:
  <scgui formid="detail" widgetid="city" widgettype="textbox"
       visible="yes" x=120 y=136 width=80
       onhop="self" wait="no" 
The "self" event tells the widget to send its own contents upon the event. "wait=no" tells it not to go into waiting for a server response. (Actually, the default for textboxes is no-wait anyhow.)

One more screen

If you press the Save button without first correcting the blank State field, you will get this screen:

A message box

This is the 3rd screen (potentially) generated by the server script. It is a message box. It comes from subroutine "hMsgBox" in the server script.


Main | SCGUI-Main | Demo-Intro-and-Downloads | GUI-Experiments | Contact