 |
Updated: 8/2/2001
|
The SCGUI demo is a free Windows utility that can be used to experiment with basic SCGUI concepts. It is not meant for production projects. It is only an experimental concept exploration tool.
It is written in Microsoft Visual Basic (CCE edition) and Python 1.52. These two development tools are available without charge on the web. The VB portion implements the GUI and parsing, while the Python part implements the communication with the web. The source code comes with the demo kit.
A description of the source files in the kit is included below.
Ricky Chilcott is also conducting some SCGUI experiments at his website.
I used polling to communicate between the VB and Python portion. A more integrated approach would be to purchase a web communications control for VB. But, this would limit free distribution of the various parts.
Both the "original" and "Chilly" SCGUI XML formats are supported. (See Version 2 Draft for examples of both versions.) The original format starts all XML statements with "scgui". However, the server only generates the original format, with one exception: an "event" statement. The event statement is used to sandwich an event into a unit. This allows the SCGUI browser to know when a given event is answered. When an event is sent to the server, it resembles this:
<EVENT EVENTID="4">
<SCGUI ...../>
<SCGUI ...../>
</EVENT>
If it is a "wait" event, the SCGUI browser
displays an hour-glass until it receives
EVENTID="4" from the server (in a
SCGUI statement). The server
sends this as soon as it processes the
</EVENT> statement from the browser.
(It remembers the event ID from the beginning
of the data packet.)
The "@" symbol in XML statement names is not supported.
The number of widgets and forms is limited because I could not get much dynamism out of VB widgets. I could have used control-arrays, but then I would have to manage an array for each widget type. Instead, I picked a fix number of each widget type, and made them hidden by default. This allowed me to manage them via one collection instead of about 5 (per form). Ideally, it would be nice to manage a table of widget assignments and/or an event table, but no readily available language supports that kind of thing that I know of. A sophisticated collection management engine would have saved me much coding and complexity.
One of these days I might implement a "form reclaimer" command by executing a SCGUI "script" against a form rather than put it all in code.
An interesting project would be to make a VB-to-SCGUI converter as far as form layout goes. This would reduce the need to manually key in coordinates. One could make the from layout in VB, then run the form source code through the converter to get SCGUI XML. Of course, event handling still has to be programmed.
A workaround to the large text-box problem (above) may be to have a right-click option to pop up a large edit window. This would be implemented on the browser, and not server controlled. My original plan was to have multi-line and scroll-bars appear automatically if the height/width was past a quota.
I noticed after the fact that I forget the "formid" attribute in some of the XML. The browser can often use the most-recently-mentioned form ID if a given statement references a widget, but not a specific form. Although it works here, implied form ID's are not a recommended practice. On second thought, it can reduce the XML code size, shortening the transfer time a tad.
| File | Description |
|---|---|
| console.frm | VB console form code |
| data1.mdb | Database with sample data |
| fetch1.py | Python communications script |
| parse1.bas | VB subroutines |
| pars_inc.asp | ASP subroutines include file |
| proto.frm | VB form module |
| scgui.vbp | VB project file |
| scgui1.asp | Demo server application |
| sc_mod1.bas | VB modules |
| startup.bat | Batch file to run comm. script |
| test1.xml | Sample XML GUI file (Chilly fmt.) |
| test2.xml | Sample XML GUI file |
| textVW.frm | VB modules |