EDX Full Screen Application Library.
EDX Full Screen Application Library
by Stuart D. Gathman
Last updated Nov 02, 2000
Overall Design Goals
Seamless EDX/Java Integration
While a TUI AWT implementation
can be used for the user interface to Java applications with EDX/UNX,
our users are confused by
user interface changes. For instance, the tab order on 4978 screens is
always by physical location. In Java AWT, whether TUI or GUI, it is
defined by the application within each AWT container. With multiple
frames and panels, the result seems illogical to a user expecting
physical tab order.
Our solution is to give Java programs access to the emulated EDX 4978
terminals. The basic operations (read/write the screen and waitkey) are
provided by the EDX4978 class. The
terminal user cannot tell whether EDL or Java or a mixture is controlling
the screen.
High Level Application Framework
Programming BMS applications in EDL is efficient despite the primitive
language because of the high level event driven framework provided by
the BMS library. The EDL library has 2 principal layers:
The FS layer
displays stored screen designs and provides screen reading/writing and
cursor positioning by field. Fields are sequentially numbered
unprotected (input) areas.
The FCB (Field Control Block) layer groups the fields into logical
sections and distributes pfkey events to the appropriate FCB based
on the cursor position. An FCB may also be configured as a scrolling
table or grid.
This package aims to be a Java version of the FS/FCB library. We
cannot, of course, resist attempting to improve it in the translation.
Migration path to Swing/AWT
The public API should also be implemented with a GUI client. Both
4978 and GUI clients should be able to operate with the same application
server JVM.
Overview
The FSPanel class represents
an EDX screen. Only one FSPanel may be active at a time, but
multiple instances may be kept for rapid switching between
screens. An FSPanel may be initialized programmatically, or from
a stored image. An FSPanel may define 0 or more unprotected data
input fields which are numbered sequentially from 0. Fields
are added automatically from stored images, or manually with the
addField()
method.
FSComp is an abstract base class
for the equivalent of an FCB. Derived classes implement tables,
groups of fields and other specializations. FSPanel
is
itself an FSComp
. An FSComp
must be
added to an FSPanel
to be active.
The FSPanel.fprocess()
method reads
PFKeyEvents and sends them
to the appropriate FSComp
based on the row and column
at which the event occured. Changes to data input fields are
also detected and signaled with the special
PFKeyEvent.FIELD_MODIFIED
pfkey.
The FSTextArea class provides
a scrollable and editable text area which is available to the application
as a String[]
. The DBField
class links a screen field to a database field. The
FSGrid class forms the base of components
that deal with multi line controls, for example FSTextArea
.
DBTable links a scrollable and
editable multi line table to a database table.
BUGS
- In DBTable, a locate where the field is not modified needs to scroll
forward and back again to keep the screen within the Dataset buffer.
- In DBTable, rdline() depends on FSPanel having called contains().
This means that you must attach any PFKeyListeners which call
rdline() to the DBTable, not its FSPanel.
Send comments to
Stuart D. Gathman.