Main Index
PREV
NEXT
|
The computer system that this manual describes has been written in accordance with the following documents:
Here is a summary of the main points:-
The system is comprised of a large number of small, simple functions rather than a small number of large, complex functions. Thus there are separate modules to List, Create, Read, Update and Delete an object, rather than a single function which can perform all these operations.
The logic behind this philosophy is discussed in a separate document titled Component Design - Large and Complex vs. Small and Simple.
Each function (transaction, or form) name is in the format AAAnnnnX
where:-
AAA
is the system identifiernnnn
is an identifying numberX
is a letter that identifies the dialog type (see below)Dialog types can be one of the following:-
Screen (form) layouts contain the following areas:-
Transactions are usually grouped together in families, starting with a parent form. The parent form is usually found on a menu, and as there is some form of communication between the parent and its children it is not usually possible to gain access to a child form without passing through its parent. In some circumstances it is possible for a child form to be the parent of its own family of forms.
With modal forms only one child form can be active at any one time. Once a child form has been activated focus remains with that form until it either exits and returns control to its parent form, or it activates a child of its own. If, after activating a child form the user moves the cursor out of the area encompassed by that form it will not have any effect.
With non-modal forms it is possible for the user to activate a child form, then switch focus back to the parent form by clicking the cursor within the boundaries of that form. The user can continue working within the parent form, and may even activate another child form. The title bar of the form that has focus will be highlighted - all others will be greyed out.
Using the example above the user may activate the ADD form from the LIST form, then click the cursor back onto the LIST form in order to activate another child form. This may be repeated until all child forms have been activated. All these forms will be available in the application window, but only one will have focus at any one time. The user will be able to switch focus from one form to another just by clicking the cursor within the boundaries of the required form.
Non-Modal forms have the following characteristics:-
It could be assumed that an entire application could consist of non-modal forms so that the user could switch focus from any form in the system to any other. However, in real life it is not practicable to have more forms active than can fit comfortably within the application window (or the PC's memory) at any one time. |
The abilities of non-modal forms, coupled with the ability of components to send messages from one to another, provides an interesting choice of possibilities when dealing with a family of forms.
An example would be use the forms families from the previous section. The LIST form displays multiple occurrences, with the details of a single occurrence summarised on each line. The ADD, UPDATE and DISPLAY forms each deal with a single occurrence, with the details expanded to fill the screen. Using these forms, the following scenarios are possible:-
refresh_children=false |
There are now two copies (instances) of the DISPLAY form, but each contains the details for a different database occurrence. This is possible because when a form component is activated it can be given a different instance name each time, which allows a separate copy to be created for each occurrence in the parent form. This allows the user to have multiple copies of the same form visible at the same time so that data from different occurrences can be compared more easily. In a modal environment this would be much more difficult. |
refresh_children=true |
There is only one copy (instance) of the DISPLAY form, and each time the user selects a different occurrence in the LIST form this same instance is re-activated with the primary key of the selected occurrence instead of a new instance being created. This allows the user to activate the child instance only once, then change its contents by simply selecting another occurrence in the parent form. In a modal environment the user would have to exit from the child form back the parent, make another selection, then press the navigation button again to invoke the child form. |
The choice between these two scenarios does not have to be fixed in the design of the application. The user has the ability to switch between these two options at run time by selecting one of the entries on the pulldown menu bar. The APPLICATION menu contains an option called REFRESH CHILDREN which can either be ON/TRUE (displayed with a tick) or OFF/FALSE (displayed without a tick). The initial value for this option can be set in the assignment file.
This ability is available between parent and child forms where the parent is of dialog type LIST. The ability to communicate between grandparents/grandchildren, other sibling instances, or unrelated instances, would have to be specifically built into the design and coded accordingly. |
http://www.tonymarston.net |