Conventions

The computer system that this manual describes has been written in accordance with the following documents:

Here is a summary of the main points:-

Small and Simple

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.

Dialog Types

Each function (transaction, or form) name is in the format AAAnnnnX where:-

AAA is the system identifier
nnnn is an identifying number
X is a letter that identifies the dialog type (see below)

Dialog types can be one of the following:-

L = List (browse) a number of occurrences
C = Create (add) an occurrence
R = Read (display) an occurrence
U = Update (modify) an occurrence
D = Delete (remove) an occurrence
S = Select (enter selection criteria) for a List form
M = Multi-purpose (combination of create/read/update/delete)
P = Popup, choose an occurrence (available on a field which has the popup button behind it)

Standard Screen Layout

Screen (form) layouts contain the following areas:-

The DATA area contains application data being manipulated by this form.
ACTION buttons will perform an operation within the current form.
NAVIGATION buttons will pass control to another form. If the button is dimmed it means that the user has not been granted access to the transaction in question.

Form Families

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.

The LIST form will display a list of available entries, in summary form, one to a line.
The SELECT form is used to define selection criteria before filling the LIST screen with entries. This may be defined as the parent of the LIST form instead of its child.
The ADD form will add a new entry to the database, causing the LIST screen to be updated.
The UPDATE form will update an entry selected from the LIST screen, causing the LIST screen to be updated if any of the summary data has changed.
The DISPLAY form will show more details for an entry selected from the LIST screen.
The DELETE form will delete an entry selected from the LIST screen, causing the LIST screen to be updated.

Modal vs Non-Modal 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:-

A non-modal form can only be activated by a non-modal parent.
A modal form can only create child forms that are modal.
Any non-modal form will be automatically terminated when its parent is terminated.

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.

Interaction between Non-Modal Forms

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

The user selects occurrence 1 in form LIST, then presses the navigation button to activate the DISPLAY form to show details of this occurrence.
Without terminating this DISPLAY form the user returns to the LIST form, selects a different occurrence, then activates a new copy of the DISPLAY form for this occurrence.

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

The user selects occurrence 1 in form LIST, then activates the DISPLAY form to show details of this occurrence.
Without terminating this DISPLAY form the user returns to the LIST form, selects a different occurrence, and the contents of the DISPLAY form changes automatically to match the newly selected occurrence.

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