Guidelines for Writing Applications |
DEVELOPER |
 |
|
Guidelines for Writing Applications |
DEVELOPER |
|
This section provides some general guidelines to assist you in the effective use of PROIV and to ensure that applications work well in GUI and non-GUI environments. In some cases, the guidelines given here are simply restating what may be regarded as good PROIV design practice, irrespective of platform, while others are specific to this version. A few of the latter may be regarded as 'work-arounds' - backwards compatibility with previous versions of PROIV (text mode) was an important design requirement during the development of PROIV Version 4, but the special characteristics of the Windows operating environment are such that some applications inevitably port better than others.
Make use of the new system variable &#@GUI-MODE, which is set when PROIV is running in GUI mode. This can be interrogated in logic and used to determine action taken.
Try to keep response strings short - remember that users of dumb terminals will have to enter them manually.
Crowding – Avoid crowded fields. This is obviously good practice under any environment, but the use of field borders makes crowding more apparent. Use pop-up windows to reduce the amount of information displayed at any one time.
Length – Define fields long enough to accommodate their display codes. If this is not done trailing characters will not be displayed. (In the text mode environment, trailing characters are not lost provided there is a blank space following the field.)
Overlapping – Be aware that overlapping may result in unexpected mouse navigation behaviour, particularly if an input field is completely overlaid by a read-only field, in which case it will not be possible to navigate to it by a mouse click. Keyboard navigation will still function as normal.
Leave at least two spaces between fields. This allows edit boxes to be increased in size where proportional font input fields would otherwise not fit.
Hidden – Set the hidden property rather than suppressing echo in logic to implement fields which do not display their content (for example, password fields).
Dummy Length – Set the length of dummy fields to zero. It is sometimes necessary to create dummy fields on the screen which serve as place holders for logics but are not intended to display a value. Under the text mode environment no special action was necessary, but in the Windows environment frames are displayed around each field, making the presence of such dummies obvious. Setting the field length to zero (0) avoids this problem.
Specifying – Specify an LSupdate with ENABLE (&#@LSUPDATE) in Default Logic as this is more efficient.
Grouping – Group multiple file updates under a single LSupdate wherever possible. The use of many LSupdates can lead to performance problems.
Valid Mode – Specify only one valid mode (Add, Change, Delete or Lookup) for LSupdates. This avoids toolbar icons flickering.
Use a screen resolution of at least 800 x 600 if possible. In standard 640 x 480 VGA mode, use caution in font selection; many are almost unreadable.
Topic ID: 730064