Forms

Forms need to be as easy to create and maintain as possible. It should be possible for them to maintained by non-technical persons.

The approach under consideration is inspired by Adrian Smith's galleries and illustrated with Eric Lescasse's function ConferenceDemo5. This function puts up a somewhat complicated and certainly attractive Windows form using his Objects. Adrian's "gallery" approach suggests we can separately store reference data saying that when this "field name" (or "control name") is used, we'll handle it in such and such a way.

All properties can be overridden, so our controls are both highly efficient and also highly flexible. The function qkeFN handles this in a preliminary way using Windows Objects. This has been discussed with EricL. He says this is a higher level of abstraction than he has attempted thus far, but he see no reason why it can't be done. Form specifications are generalized so they can be rendered in any desired environment (Windows, HTML, javascript (jscript), Excel, Access).

It seems that we can write a general facility which will have the following properties. (To allow searching in a workspace, a "q" is placed in front of each of these properties.)

• control ---- control name, field name &/or aplname (case insensitive)
• wherelc ---- controls form layout (not in ePMSTD, i.e. there is no standard value)
• attach ---- controls form layout (not in ePMSTD, i.e. there is no standard value)
• caption ---- (default is ProperNameCase of aplname)
• object ---- Object type from Eric Lescasse's Objects
• must ---- boolean, 1=required field
• check ---- validity check
• type ---- integer, date, time, text, boolean, currency, floating point, etc.
• subname ---- control name, e.g. ".ed1" (is generated)
• list ---- as for options in a combo control
• value ---- provides "checked" for combo control (not yet implemented)
• colwidth ---- for text area field this must be width----height (not yet a function)
• format ---- as in quad----fmt format string (not yet a function)
• align ---- left, center right (not yet a function)
• bgcolor ---- background color, e.g. all inputs might be green (not yet a function)
• editable ---- (boolean)
• helpref ---- reference to help system topic
• aplname ---- var to be defined (default is field name all caps except first letter is lower case)
• handler ---- syntax for handler

Specifications for the form can be unique to the form as in delta-SS in FORM.w3 (except that delta-SS has fixed columns which must be variable).

Or, specifications can be obtained from (READS 8100 58). Same property specs are shown below. A field named "drug" has valuetype "text". A field called "dose" is right aligned. A field called "sex" has two options, "female" and "male" and female is checked.

drug	valuetype	text
dose	align	right
units	align	right
price	valuetype	currency
price	format	$0.00
price	align	right
desc	valuetype	text
description	valuetype	text
check	valuetype	text
date	valuetype	date
date	colwidth	80
date	format	MM/dd/yy
coa	valuetype	text
amount	valuetype	text
vendor	valuetype	text
client	valuetype	text
text	valuetype	text
number	valuetype	text
sex	celltype	combo
sex	options	Female w
		Male    m
sex	colwidth	48
sex	checked	w

Thus it should be possible to create a Windows form with the following syntax.
MakeForm 'Name' 'Fname' 'OKButton' 'CancelButton' 'APL' 'Sport' 'Smoking' 'URL' 'Age' 'WebBrowser'

And it should be possible to create an HTML form with exactly the same syntax, or perhaps with a left argument to MakeForm. (MakeForm is presently implemented with the name "qkeFN". GugScript & qkForm are a highly developed implementation).

Other characteristics of this process include....

1. the right argument of MakeForm should be case insensitive
2. aplname values should be special so they can be searched, e.g. fNAME.
3. to the maximum extent possible, everything should be optional. MakeForm will create an apl function, so there are all kinds of possibilities for customizing the form after it is initially created. However, wherever the generated form is sufficient, that is better in terms of future maintenance and in terms of migration to the web.