Typical running instance of comm script (in a DOS window)
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.
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.)
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.)
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.
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.
In the future, the drop-down lists may be replaced with grids.
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.
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.)
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.