home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
OS/2 Shareware BBS: 10 Tools
/
10-Tools.zip
/
pds.zip
/
PDS.DOC
< prev
next >
Wrap
Text File
|
1994-07-05
|
157KB
|
4,807 lines
Panel Display System (PDS)
Base System and Rexx Application Programming Interface
V1.05
Copyright (c) Rick W. Hodgson 1994; All Rights Reserved;
June 22, 1994
Panel Display System (PDS)
OS/2, Presentation Manager and PM are trademarks of IBM Corporation.
Use of any other copyrighted material without any mention of the owner of
material is unintentional and should be brought to my attention so that I
update this document.
Panel Display System (PDS)
Section Page
1 PDS Overview 1
1.1 Character Based User Interface 1
1.2 Panels 2
1.3 Fields 4
1.3.1 Field Definition and Attributes 4
1.3.1.1 Text Fields 5
1.3.1.2 Output Fields 5
1.3.1.3 Input Fields 6
1.3.1.3.1 Default PDS Input Field behavior 7
1.3.1.4 PDS Output/Input Field Variable Name Substitution 8
1.4 Variables 9
1.4.1 Variable's Attributes 10
1.4.1.1 String Variables 10
1.4.1.2 Floating Point Variables 11
1.4.1.3 Integer Variables 11
1.4.1.4 Right Adjusted Variables 12
1.4.1.5 Left Zero Filled Variables 12
1.4.1.6 Global Variables 12
1.4.1.7 Static Variables 13
1.5 Attention Identification Keys (AID Keys) 14
1.5.1 Field Data Verification Procedure/Routine 15
1.5.1.1 Field Data Verification Procedure/Routine Return Codes 19
1.6 Exit Identification Keys (XID Keys) 21
2 Panel Definition Language 22
2.1 Creating PDL Statements 22
2.2 Order of PDL Statements 23
2.3 Panel Attributes Definition Statements. 32
2.3.1 ")PANEL" Panel Definition Statement 33
2.3.1.1 "NAME=" Panel Name Operand 33
2.3.1.2 "CLS=" Clear Screen Option 33
2.3.1.3 "AID=" Attention ID Option 33
2.3.1.4 "XID=" Exit ID Option 34
2.3.1.5 "ATTR=" Attribute Character(s) Option 34
2.3.2 ")AID" Attention ID Definition Statement 36
2.3.3 ")XID" Exit ID Definition Statement 36
2.3.4 ")VARS" Substitution Variable Name Statement 37
2.3.5 ")COLORS" Field Attribute Colors Statement 37
2.3.5.1 "OUTPUT=" Output Color Option 38
2.3.5.2 "INPUT=" Input Color Option 38
2.3.5.3 "TEXT=" Text Color Option 38
2.3.5.4 "BCKG=" Background Color Option 38
2.3.6 ")PROC" Data Verification Procedure Definition Statement 39
2.3.7 ")PROCEND" Data Verification Procedure Delimiter Statement 39
2.3.8 ")END" Panel Delimiter Statement 39
2.3.8.1 ")BLANK" Blank the Last Row Option 39
Panel Display System (PDS)
Section Page
2.3.8.2 ")NOWAIT" Defer End User Input Option 39
2.3.8.3 ")NODISPLAY" Suppress Panel Display Option 40
2.3.8.4 "FLDS=" Field Definition Option 40
2.4 Panel Row Definition Statements. 42
2.4.1 Current Row Panel Row Definition Records 42
2.4.2 ")NULL" Null Row Definition Statement 43
2.4.3 ")BLANK" Blank Row Definition Statement 43
2.4.4 ")ROW" Explicit Row Panel Row Definition Statement 43
2.4.4.1 Target )ROW Row Option 44
2.4.4.2 Target )ROW Column Option 44
2.4.4.3 Target )ROW "FLDS=" Field Definition Option 44
2.5 Miscellaneous PDL Statements 46
2.5.1 ")REM" Remarks Statement 46
2.6 Defining Panel Rows and Fields 47
3 REXX PDS Application Programming Interface 51
3.1 Defining the REXX PDS, "RXPD", interface to OS/2 51
3.2 Initializing the RXPD environment with rxPDInit 52
3.3 Terminating the RXPD environment with rxPDTerm 54
3.4 Displaying a PDS panel with rxPDDisplay 55
3.5 Saving an image of the display with rxPDSaveScreen 56
3.6 Restoring an image of the display with rxPDRestoreScreen 56
3.7 Setting an error or informational message with rxPDSetMsgText 56
3.8 Setting the target field for the cursor with rxPDSetCursorFld 62
3.9 Defining variable attributes with rxPDVarDefine 64
3.10 Deleting variable attributes with rxPDVarDelete 65
3.11 Querying a panel's field 'MDT' state with rxPDQueryMDT 66
3.12 Querying a panel's modified field names with rxPDQueryMDTFld 67
3.13 Retrieving predefined variable values with rxPDVDefVarRetrieve 69
3.14 Dynamically setting Field colors with rxPDSetFldColors 71
3.15 Dynamically setting Panel colors with rxPDSetPnlColors 73
APPENDIX A - REXX AID/XID Keys and other 'Z' Values 74
APPENDIX B - Color values for PDS fields and background 82
Index 83
Panel Display System (PDS)
Figures Page
Figure 1. - Simple PDS Panel 3
Figure 2. - Example of ")REM" ")AID" and ")PROC" 17
Figure 3. - Example of a "COMPOSITE" display 25
Figure 4. - Example of a "POPUP" panel 28
Figure 5. - Example of a "BASE" panel 30
Figure 6. - Example of the ")ROW" statement 45
Figure 7. - Example of the ")ROW" statement 46
Figure 8. - Example of a "COMPOSITE" display 49
Figure 9. - Example of a "COMPOSITE" display 50
Figure 10. - Example of setting message text 58
Figure 11. - Example of a short message 59
Figure 12. - Example of a long message 60
Figure 13. - Example of a "POPUP" panel 61
Figure 14. - Example of setting a cursor field 63
Figure 15. - Example of retrieving variables 71
Panel Display System (PDS)
╔══════════════════════════════════════════════════════════════════════════════╗
║ 1 PDS Overview ║
╚══════════════════════════════════════════════════════════════════════════════╝
The Panel Display System provides a simple yet powerful method by which an
application developer can create an interactive user interface without requiring
OS/2 Presentation Manager (PM).
The method by which information is presented by the application to the end user
and information from the end user is returned to the application is via a
construct known as a 'PANEL'.
A panel is defined by the developer and displayed by the application thru calls
to the REXX application programming interface (API), herein referred to as the
REXX Panel Display API or rxPD, or thru calls to an optional high level language
interface.
As the end user interacts with a displayed panel, the PD system takes care of
most keystrokes and combinations of keystrokes, known as chords, without the
application having to interpret these keystrokes.
The application can, however, be written to handle any keystroke that might
require special handling other than the PDS default for that key or chord.
The following sections describe various aspects of the PD system at a 'concepts'
level.
Other sections describe the Panel Definition Language (PDL) and the REXX
application interface.
1.1 Character Based User Interface
The PD system uses what is known as a Character User Interface or CUI.
This is in contrast to a Graphical User Interface, or GUI, such as OS/2's
Presentation Manager (PM).
A CUI interface can be used wherever there is a need to interact with the end
user without the requirement for presenting data in a graphical format.
One such interaction would be for a high speed data entry application where the
end user is keying in data collected off line thru non-computerized methods.
Another situation where a quick CUI interface can be used is where a batch job
1 PDS Overview Page 1
Panel Display System (PDS)
might need to present an error message and ask for a response before continuing
the job or cancelling its execution.
More sophisticated CUI applications can be written using the PD system including
the use of popup windows, context sensitive help and accelerator keys.
The PD system is best suited for the porting or right-sizing of current
character based applications from mainframe OSs, DOS or UNIX to OS/2.
The PD system is robust enough for most applications, and continuing
enhancements to PDS will make it even more useful for more applications.
1.2 Panels
A 'Panel' is a collection of 'Fields' which are used to format and create the
display presented to the end user.
The panel can be built from a composite of other panels which, to the user,
looks like a single display of information.
Panels are defined in a library which is processed when the application
initializes an instance of PDS for its use. Normally each library is used to
define panels used only by a single application. A single application however
could use multiple libraries and initialize a library only when a panel defined
in that library is needed.
Creative use of composite panels can lead to some rather sophisticated displays
such as popups and simple animation sequences.
1.1 Character Based User Interface Page 2
Panel Display System (PDS)
Figure 1. - Simple PDS Panel
Figure 1 is a simple PDS panel definition composed of a number of panel and row
definition records each of which defines one or more fields.
)PANEL NAME=DEMO0001 CLS=Y
╔═════════════════════════════════════════════╗
║ My PDS Application ║
║ ║
║ Old Value..:%sOldValue + ║
║ ║
║ New Value..:_sNewValue + ║
║ ║
╚═════════════════════════════════════════════╝
)END )BLANK FLDS="<Press ESC to reset, F3 to cancel or F1 for help>"
Figure 1 - Complete PDS panel whose name is defined to PDS as 'DEMO0001'.
1.2 Panels Page 3
Panel Display System (PDS)
1.3 Fields
There are three types of fields.
1. TEXT - This is the default field which defines the static text that
composes the body of the panel.
2. OUTPUT - This is a field that instead of text, defines a variable that PDS is
to use to retrieve the data necessary to fill in the field where the
variable is defined.
3. INPUT - This is a field that like an 'OUTPUT' field is used to define a
variable to use to fill in the field and it is also the variable
used to store any data the user types into that field.
Refering back to Figure 1, there is one 'OUTPUT' field, one 'INPUT' field and
all of the rest, including blank space and lines, are 'TEXT' fields.
1.3.1 Field Definition and Attributes
Fields are defined for a panel by the use of an escape character.
Each field type has a default escape character.
1. TEXT - All fields are by default 'TEXT' fields and no escape character is
necessary except when an 'OUTPUT' or 'INPUT' field has been defined
and more static panel 'TEXT' needs to be defined. In that case, the
default 'TEXT' escape character is the '+' character.
2. OUTPUT - The default 'OUTPUT' escape character is the '%' character.
3. INPUT - The default 'INPUT' escape character is the '_' character.
As can be seen in Figure 1, the text fields are the box created by the use of
ANSI characters, the phrases 'My PDS Application', 'Old Value...:', 'New
Value...:', the blank line preceeding the box and a special 'FLDS=' operand
declared on the ')END' panel definition statement. The output field is the one
where the word 'sOldValue' is found. The input field is the one where the word
'sNewValue' is found. The words 'sOldValue' and 'sNewValue' are in fact variable
names defined to PDS as the source of data for the both the output and input
fields and the target for any data entered by the user into the input field.
Note also, the end of a field is determined by the beginning of the next field
1.3 Fields Page 4
Panel Display System (PDS)
or the end of the row definition record.
Each field type has a default set of characteristics known as it's attribute.
Other characteristics can be added to an input or output field by modifying the
attributes of the variable defined for that field. This is discussed in a later
section.
1.3.1.1 Text Fields
One characteristic of 'TEXT' fields are that they are static fields whose data
is contained wholey within the panel definition itself. These fields can not be
changed or manipulated in any way by the application.
By default, all fields in a panel are text fields and do not require the use of
the text field escape character. The text escape character is used when static
text needs to be defined in a row at a place following either an output or input
field.
Example:
This is static text followed by %sOutputVar +and more static text.
In the above example of a row definition record, there are two fields of static
text and one output field. The output field is defined to contain data from the
variable 'sOutputVar' and is to be a maximum of 12 bytes in length as determined
by the number of bytes from one escape character to the next.
Another characteristic of a 'TEXT' field is that it can contain any character
except for one of the escape characters that by their very nature define the
start of a different field.
The color of a text field is determined first by the PD system default for
'TEXT' fields, second by the 'TEXT' color defined when the PD system is
initialized to process a panel library and lastly by the 'TEXT=' operand of the
')COLORS' panel definition statement.
1.3.1.2 Output Fields
The main characteristic of an 'OUTPUT' field is that it defines a variable,
known to PDS, which contains data to be merged with the panel when the panel is
displayed.
1.3.1 Field Definition and Attributes Page 5
Panel Display System (PDS)
The variable name must be a single word and must not contain an escape
character. The data contained within the 'OUTPUT' variable can be any character
including escape characters. This is because the escape characters are processed
when the PDS system is initialized prior to displaying the panel and not when
the display itself is built.
The length of an 'OUTPUT' field is determined by the number of character
positions from the 'OUTPUT' field escape character up to any succeeding escape
character or the end of a panel row definition record.
The default type of data that PDS expects for 'OUTPUT' fields are character
strings. The datatype for a field is overridden by defining the variable for
that field with a different datatype.
The color of an output field is determined first by the PD system default for
'OUTPUT' fields, second by the 'OUTPUT' color defined when the PD system is
initialized to process a panel library and lastly by the 'OUTPUT=' operand of
the ')COLORS' panel definition statement.
1.3.1.3 Input Fields
'INPUT' fields have many characteristics.
One characteristic is that they function exactly like 'OUTPUT' fields when the
physical display is being constructed from the panel definition.
The main characteristic about an 'INPUT' field is that these fields are where
the end user can and will be expected to enter data required by the application.
The length of an 'INPUT' field is determined by the number of character
positions from the 'INPUT' field escape character up to any succeeding escape
character or the end of a panel row definition record.
The default type of data that PDS expects for 'INPUT' fields are character
strings. The datatype for a field is overridden by defining the variable for
that field with a different datatype.
The color of an input field is determined first by the PD system default for
'INPUT' fields, second by the 'INPUT' color defined when the PD system is
initialized to process a panel library and lastly by the 'INPUT=' operand of the
')COLORS' panel definition statement.
1.3.1.2 Output Fields Page 6
Panel Display System (PDS)
1.3.1.3.1 Default PDS Input Field behavior
The PD system has a default behavior for most keystrokes and chords that the
user might use for an input field.
One behavior is to 'ECHO' the keystroke into the 'INPUT' field. This is the
default behavior for the alpha-numeric keys.
Other behaviors are defined for some keys which perform much as one would
expect them to do when processing input data.
'TAB' - Tab to the first position in the next input field.
'BACK_TAB' - Tab to the first position in the preceeding input field.
'INSERT' - Alternate the 'ECHO' behavior between 'INSERT' and 'OVERTYPE'.
'DELETE' - Delete the character under the cursor and left shift the rest.
'HOME' - Tab to the first position in the current input field.
'END' - Tab to the first blank trailing the last non-blank character
in the current input field.
'UP_ARROW' - Tab to the first position of the first input field on the
preceeding panel row.
'DOWN_ARROW' - Tab to the first position of the first input field on the
succeeding panel row.
'LEFT_ARROW' - Move the cursor left one position within the current input
field. If already at the first position, move to the last
position within the preceeding input field.
'RIGHT_ARROW' - Move the cursor right one position within the current input
field. If already at the last position, move to the first
position within the succeeding input field.
'ENTER' - The default action for this field is identical to that for
the 'DOWN_ARROW' field.
There are also some default actions defined when one of the following are
chorded with the 'CONTROL' key:
'DELETE' - Delete all characters from the current position to the end of
the input field.
'HOME' - Tab to the first position in the first input field defined for
the panel.
'END' - Tab to the first blank trailing the last non-blank character
in the last input field defined for the panel.
1.3.1.3.1 Default PDS Input Field behavior Page 7
Panel Display System (PDS)
1.3.1.4 PDS Output/Input Field Variable Name Substitution
Because not all fields should be as wide or wider than the name of the variable
used to hold the data for an output or input field, there is a mechanism by
which the developer can define a field that is shorter in length than the
variable name for that field.
This mechanism uses a separate list of variable names, specified for the entire
panel, which are used to define variable names for each field which is either 1
byte in width or which uses the PD system's variable name substitution escape
character.
The list of substitution variables is defined by the ')VARS' statement.
The field variable name substitution escape character is the '*' character.
Example:
)VARS sField1 sField2
--- other PDL statements ---
The variable sField1 is substituted here=> %+ and
the variable sField3 is not substituted here=> %sField3 +;
the variable sField2 is substituted here=> _* +;
In this example the output field "%+" is only 1 byte wide. This causes PDS to
use the first variable name defined by the ")VARS" statement. This results in
the variable name 'sField1' being defined as the source of data for this field.
The maximum width of data that will be displayed from the 'sField1' variable is
1 byte.
The input field "_* +" has the PDS substitution escape character defined as its
variable name. This escape character is replaced with the variable 'sField2'
since the variable 'sField1' has already been used by the preceeding output
field. The maximum width of data that will be displayed or can be keyed into the
field by the end user is 3 bytes.
Note that substitutable fields can be intermixed with non-substitution fields.
This is shown by the 'sField3' field being in between the other two fields in
the PDS panel processing order.
1.3.1.4 PDS Output/Input Field Variable Name Substitution Page 8
Panel Display System (PDS)
1.4 Variables
Variables are collections of data that are accessable by a published name for
that data.
PDS uses variables to communicate data and other information between PDS and the
application.
PDS uses variables to retrieve data from the application in order to merge that
data into a panel to be displayed to the end user. It also uses variables to
send data, keyed into a panel by the end user, back to the application.
In a REXX PD application, all output and input variables defined on a panel are
automatically available to the PD system without the application having to
provide any information other than the variable's name. The only restriction is
that the variable must have been defined in the REXX shared variable pool prior
to the display of any panel that requires data from that variable. Note, the
restrictions of accessability to shared variables imposed on REXX 'PROCEDURE's
are also imposed upon the rxPD system in that they do not exist unless defined
within the 'PROCEDURE' or 'EXPOSE'd by the procedure so that a preceeding
definition is available. If a REXX variable is not defined or not accessable,
the act of retrieving the data from that variable returns the variable's name as
the data.
Also, if the data retrieved from a variable is longer than the width of the
output or input field that defines that variable, then the data is truncated to
the width of the target field.
Named variables are also used to communicate information not related to a data
field on a panel.
One such variable is 'ZCURVAR'. This variable is updated by PDS when an 'AID' or
'XID' key is pressed (discussed in detail in a later section). The information
contained in this variable is the cursor position within an input field when the
'AID/XID' key was pressed and the name of that input field.
There are two routines available to a REXX PD application which help with the
interaction between the rxPD application and the rxPD system thru the use
of 'Z' variables and data variables.
The first is the rxpdZVarDefine routine. This routine can be used to create
'Z' variables whose values are needed to test 'AID' or 'XID' keys and to define
alternate attributes for data variables.
One such variable is the 'ZENTER' variable.
1.4 Variables Page 9
Panel Display System (PDS)
The 'ZENTER' variable is used by an rxPD application to test if the user pressed
the 'ENTER' key.
Another such variable is the 'ZVTYPE_LZEROFILL' used to assign a 'Left Zero
Fill' attribute to a data variable.
Data variables can be defined to the rxPD system thru the rxPDVarDefine routine.
The definition of REXX variables to rxPD is done solely to define additional
attributes to a variable. These attributes will be used by the PD system to
modify the behavior of a variable when it is processed by PDS as the result of
being displayed by a panel.
The act of defining a variable to PDS by an rxPD application does not override
the REXX shared variable pool restrictions and make the variable globally
available.
In a high level language other than REXX, variables must be defined to the rxPD
system in order to make their data accessable. Discussion of this is included in
the optional 'HLL', High Level Language, interface for PDS.
1.4.1 Variable's Attributes
In a REXX environment, all variables are, by default, defined as being a string
of characters.
The PD system provides other attributes which can be applied to a variable and
which will modify the action that PDS takes on that variable.
1.4.1.1 String Variables
This is the default attribute for all variables and as such does not need to be
defined for any variable in the rxPD environment.
The name of the 'Z' value for this attribute is 'ZVTYPE_ZSTRING'.
1.4 Variables Page 10
Panel Display System (PDS)
1.4.1.2 Floating Point Variables
When a variable is defined with this attribute, a number of additional
behaviors are added by PDS to this variable when it is displayed as an output
or input variable.
The first is that when displayed by a panel, a floating point precision
attribute is applied to round the variable to a specified number of decimal
positions.
If the variable is an input variable, I.E. the variable for an 'INPUT' field,
then PDs will prevent the end user from typing any non-floating point character
and will insure that the field contains a proper floating point number. Once the
input data is determined to be a valid floating point number, PDS will again
apply the precision attribute to the field data before actually updating the
variable itself.
Note, a blank field is considered to be a valid value for a floating point
field. The application's predefined 'Data Verification Procedure' for a
panel can verify that a field is non-blank and refuse the field. Further
discussion of 'DVP's can be found in a later section.
The name of the 'Z' value for this attribute is 'ZVTYPE_DOUBLE'.
1.4.1.3 Integer Variables
Like a floating point variable, an integer variable can be defined with a
precision that is applied to the variable to insure the minimum number of
digits is displayed for that integer.
If the variable is an input variable, then PDs will prevent the end user from
typing any non-numeric character. Once the input data is determined to be a
valid integer, PDS will again apply the precision attribute to the data before
actually updating the variable itself.
Again, a blank field is considered to be a valid value for an integer variable.
The name of the 'Z' value for this attribute is 'ZVTYPE_LONG'.
1.4.1.2 Floating Point Variables Page 11
Panel Display System (PDS)
1.4.1.4 Right Adjusted Variables
All types of data variables can be automatically aligned to the right of an
output or input field when the data is displayed.
The name of the 'Z' value for this attribute is 'ZVTYPE_RIGHTADJUST'.
1.4.1.5 Left Zero Filled Variables
Both the floating point and integer types of data variables can, in conjunction
with the 'ZVTYPE_RIGHTADJUST' attribute, be padded on the left with leading
zeros (0).
In other words, an integer value of 41 to be displayed in a 5 byte wide output
field with an attribute of 'ZVTYPE_RIGHTADJUST' can be displayed as 00041 with
the addition of the 'ZVTYPE_LZEROFILL' attribute.
1.4.1.6 Global Variables
At times, some variables need to be defined as 'Global' variables.
Global variables are made visable to certain REXX procedures which would not
normally have access to all variables in an rxPD application.
The 'ZVTYPE_GLOBAL' attribute is used to define a variable as being 'Global' in
scope.
The need for a 'Global' attribute is discussed in the section on 'Data
Verification Procedures' and the 'rxPDVDefVarRetrieve' routine.
1.4.1.4 Right Adjusted Variables Page 12
Panel Display System (PDS)
1.4.1.7 Static Variables
There are times when it is desirable to display a variable in an 'INPUT'
field without allowing the end user to modify the data in that variable.
This behaviour is useful for defining fields which the end user can 'tab'
into and out of but which the end user can not modify.
It is useful for conditionally 'locking' and 'unlocking' an 'INPUT' field by
modifying the attribute of the variable without having to define multiple panels
which alternate the field attribute used to display the variable. This alternate
method of defining multiple panels can become very cumbersome given a panel with
a number of fields which need to alternate between 'INPUT' and 'OUTPUT' field
types.
Variables with this attribute are 'Static' variables in that their data can NOT
be changed by the end user.
The 'ZVTYPE_STATIC' attribute is used to define a variable as being a 'Static'
variable.
1.4.1.7 Static Variables Page 13
Panel Display System (PDS)
1.5 Attention Identification Keys (AID Keys)
An 'AID' key is an 'Attention IDentification' key which is used to indicate what
key(s) the end user must press to notify the application that they are done with
the panel and that any input field data is available to the application.
What this means is that when a PDS application asks for a panel to be displayed
and to wait until the end user has entered all required data, that a specified
key or list of keys will return control back to the application.
The most common 'AID' key is the 'ENTER' key.
A panel can be defined to accept the 'ENTER' key as an 'AID' key by specifying
'ZENTER' as either a value for the 'AID=' operand on the ')PANEL' definition
statement or as an operand for the ')AID' statement.
If a panel has been defined with 'ZENTER' as an 'AID' key and when that panel is
displayed and the end user presses the 'ENTER' key, a number of actions will
take place.
1. All floating point numbers are verified by PDS to contain a proper floating
point number.
2. If a 'Data Verification Procedure' has been defined for a panel, or in the
case of the 'HLL' interface if a 'Data Verification Routine' has been
provided for the panel, then that 'DVP' will be executed thereby giving that
'DVP' the opportunity to validate the input fields within the context of the
application.
3. If there isn't a 'DVP' or if the 'DVP' says that all of the data is valid
application data, then PDS will replace the variables with the data from
their respective panel input fields.
4. PDS will update the 'ZCURVAR' with the name of the variable which had the
cursor focus and the index of the cursor within that field. The 'ZCURVAR'
variable is defined as a string variable that contains the index as a blank
delimited integer followed by the cursor field name.
Example:
If the cursor was over the 2nd byte of the sNewValue input field, then
'ZCURVAR' would look like having been set by the following REXX statement.
ZCURVAR = iFieldIndex||' SNEWVALUE'
1.5 Attention Identification Keys (AID Keys) Page 14
Panel Display System (PDS)
5. In the REXX environment, rxPD will return the value of the 'AID' key
that caused the attention request. In this example, the REXX 'RESULT'
variable will contain the value equal to the 'ZENTER' variable. In
the 'HLL' environment, the target 'AID' key field will be updated.
Almost any key or chord can be defined as an 'AID' key. See Appendix A for the
current list of available 'AID' keys.
There are two psuedo keys which can be defined as 'AID' keys.
The first is 'ZALL'. This means that the application wants to see every
keystroke the end user makes. In the REXX environment, this will slow down the
application, but this means that the application has complete control of the
functioning of the PD system with respect to the panel being displayed with this
'AID' key.
The second psuedo key is the 'ZNONE' key. This value will prevent all keys from
being used as an 'AID' key.
If a panel does not have any input fields defined, then 'ZNONE' is the default
'AID' key for that panel regardless of whether or not there are any 'AID' keys
defined for that panel.
Also, 'ZNONE' is the default 'AID' key value for all panels.
While this may seem strange and could possibly lead to a 'hung' application,
there is also the concept of an 'Exit ID' or 'XID' key for each and every panel.
1.5.1 Field Data Verification Procedure/Routine
As was mentioned in the 'AID' key discussion, a panel can be defined with a
'Data Verification Procedure' which can verify the correctness of the data
entered into the input fields of a panel when an 'AID' key is pressed.
The 'DVP' is a very powerful method by which some of the responsibility for
processing data can be offloaded from the application layer and placed under the
care of the PD system.
Essentially, a 'DVP' is an inline REXX procedure that has been defined for a
specific panel.
This REXX procedure has automatic 'Read' access to all input fields on the panel
where it is defined along with some special 'Z' variables. Such a REXX procedure
also has access to all variables defined to PDS as 'Global' variables.
1.5 Attention Identification Keys (AID Keys) Page 15
Panel Display System (PDS)
When a panel with input fields, 'AID' keys and a 'DVP' is displayed by a call to
PDS, and when the end user presses an 'AID' key for that panel, PDS will:
1. Verify that a 'DVP' has been defined for that panel.
2. Copy all of the input fields into a REXX shared variable pool explicitly
for that 'DVP'.
3. Copy the following 'Z' variables into that same REXX variable pool.
ZBid - The base handle to the current instance of the PDS environment.
ZPid - The handle to the panel being displayed.
ZKey - The value of the 'AID' key just pressed.
ZPName - The name of the panel being displayed.
ZFName - The name of the input field where the cursor is positioned.
ZFNdx - The index into that input field.
4. Execute the 'DVP'.
The 'DVP' is then responsible for testing the ZKey and the input fields for
correctness within the application.
All rxPD routines are available to the 'DVP'. In fact, a 'DVP' can be written
such that it is a complete application unto itself. This is not recommended
except in the case where 'HELP' information is being presented.
The rxPD routines most useful to a 'DVP' are the rxPDZVarDefine,
rxPDSetCursorFld, rxPDSetMsgText, rxPDSaveScreen, rxPDDisplay and
rxPDRestoreScreen routines.
While this is almost every rxPD routine there is, the use of these routines can
create a very powerful rxPD application.
An example, suppose we add a few things to the definition of the 'DEMO0001'
panel shown in Figure 2.
1.5.1 Field Data Verification Procedure/Routine Page 16
Panel Display System (PDS)
Figure 2. - Example of ")REM" ")AID" and ")PROC"
)PANEL NAME=DEMO0001 CLS=Y
)REM Define the 'ENTER' key and the 'F1' key as 'AID' keys for this panel.
)AID ZENTER ZF1
╔═════════════════════════════════════════════╗
║ My PDS Application ║
║ ║
║ Old Value..: %sOldValue + ║
║ ║
║ New Value..: _sNewValue + ║
║ ║
╚═════════════════════════════════════════════╝
)REM Define a 'Data Verification Procedure' for this panel.
)PROC
/* Define the possible AID ZKeys */
Call rxPDZVarDefine 'ZENTER', 'ZF1'
/* Define the possible return codes */
Call rxPDZVarDefine 'ZVERIFYPROC_RC_RETURN', 'ZVERIFYPROC_RC_NORETURN'
if ZKey = ZF1 then
do
svid = rxPDSaveScreen(ZBid)
akey = rxPDDisplay(ZBid,'DEMO0002')
rc = rxPDRestoreScreen(ZBid,svid)
return ZVERIFYPROC_RC_NORETURN
end
if ZKey = ZENTER then
do
if sNewValue = '' then
do
Call rxPDZVarDefine 'ZALARM_ERROR'
sShortMsg = 'DEMO001E'
sLongMsg = ' << New Value Required >> '
rc = rxPDSetMsgText(ZBid,sShortMsg,sLongMsg,,ZALARM_ERROR)
Call rxPDSetCursorFld ZBid, ZPName, 'sNewValue'
return ZVERIFYPROC_RC_NORETURN
end
return ZVERIFYPROC_RC_RETURN
end
1.5.1 Field Data Verification Procedure/Routine Page 17
Panel Display System (PDS)
svid = rxPDSaveScreen(ZBid)
Call rxPDZVarDefine 'ZALARM_SEVERE'
sShortMsg = 'DEMO002S'
sLongMsg = ' << Unknown AID key >> '
rc = rxPDSetMsgText(ZBid,sShortMsg,sLongMsg,,ZALARM_SEVERE)
akey = rxPDDisplay(ZBid,'DEMO0099')
rc = rxPDRestoreScreen(ZBid,svid)
return ZKey
)PROCEND
)END )BLANK FLDS="<Press ESC to reset, F3 to cancel or F1 for help>"
Figure 2 - Example of ")REM", ")AID" and ")PROC" statements.
The new statements added to the 'DEMO0001' panel are the ')REM', ')AID' and
')PROC' statement.
The ')REM' is a 'REMarks' statement just for adding comments.
The ')AID' statment defines the 'ENTER' and 'F1' keys as 'AID' keys for this
panel.
The ')PROC' statement in combination with the ')PROCEND' statement delimits the
'Data Verification Procedure' for this panel.
What follows is a brief description of what this 'DVP' does when one of the
'AID' keys is pressed.
- Since the 'DVP' is in effect a REXX 'PROCEDURE', it must define any 'Z'
variables it wants to use in its own variable pool.
- Define the possible 'AID' keys 'ZENTER' and 'ZF1'
- Define the possible return codes for the 'DVP'
- If the 'AID' key pressed was the 'F1' key then
- Save an image of the entire display as it currently exists
- Display the help panel associated with this panel
- Restore the display image
- Return the code that indicates that PDS should NOT return the AID key to the
application code nor update any input variables
1.5.1 Field Data Verification Procedure/Routine Page 18
Panel Display System (PDS)
- If the 'AID' key pressed was the 'ENTER' key then
- If the 'sNewValue' variable is all blanks then
- Define the 'Z' variable for an 'ERROR' alarm
- Define a short and long error message and inform PDS that it should handle
them when it next displays or redisplays a panel
- Inform PDS that the next time this panel is displayed or redisplayed that
it should position the cursor at the beginning of the 'sNewValue' field
- Return the code that indicates that PDS should NOT return the AID key to
the application code nor update any input variables
- If the 'sNewValue' variable is NOT all blanks then
- Return the code that indicates that PDS should return the AID key to
the application code and also update all input variables
The rest of the 'DVP' is code that complains about an 'Unknown AID key' by
setting an error message, popping up an error panel and then returning that
'AID' key to the application.
This last code is not really necessary since only the 'ZENTER' and 'ZF1' keys
are defined as possible 'AID' keys. In fact, the 'ZENTER' key test is not
necessary at all as long as all other possible 'AID' keys are properly tested.
1.5.1.1 Field Data Verification Procedure/Routine Return Codes
When a 'DVP' returns control to the PD system, it can affect the behavior of
PDS by carefully selecting what value it returns to PDS.
The possible values that a 'DVP' can return are:
1. ZVERIFYPROC_RC_RETURN - This value indicates to PDS that it should update all
input variables with the corresponding data from the panel's input fields.
2. ZVERIFYPROC_RC_NORETURN - This value indicates to PDS that it should not
update any input variables nor should it return control to the application.
3. Any integers other than ZVERIFYPROC_RC_RETURN and ZVERIFYPROC_RC_NORETURN are
treated as an application error code which suppresses updates to the input
1.5.1 Field Data Verification Procedure/Routine Page 19
Panel Display System (PDS)
fields, suppresses the return of the 'AID' key and propogates the integer to
the application as a return code.
4. An alternate 'AID' key or the value in 'ZKEY' can be returned. This is
treated like ZVERIFYPROC_RC_RETURN except that the alternate 'AID' key is
returned in place of the original 'AID' key. This is intended as a
method by which nested 'DVP's can propogate a decision back thru the
nested 'DVP's.
Example:
'DVP's could be nested 3 deep displaying popup help panels as follows:
Each of the popup help panels are defined with 'ZF1', 'ZF3', 'ZF4' and
'ZF4_A' as possible 'AID' keys.
At each level, when a 'DVP' pops up another help panel in response to
the 'ZF1' key and if that panel has a 'DVP', then that 'DVP' can pop up
another help panel and so on.
The lowest nested panel could receive a 'ZF3', which means to pop off
just this lowest level panel, 'ZF4' which could mean return to the first
'DVP' which popped up a help panel and stop at the panel being displayed
by the application or 'ZF4_A' (Alt+F4) could be propogated all the way
back to the application as an indication that the application be
terminated.
In other words, even tho each popup help panel was displayed as a result
of the user pressing 'F1', the 'DVP's for those panels can return an
'AID' key other than 'F1' in order to alter the default action of the
application.
1.5.1.1 Field Data Verification Procedure/Routine Return Code Page 20
Panel Display System (PDS)
1.6 Exit Identification Keys (XID Keys)
An 'XID' key is an 'eXit IDentification' key which is used to indicate what
key(s) the end user must press to cancel any input field updates or to exit
a panel which does not have any input fields.
Any key can be defined as an 'XID' key.
The default 'XID' key for all panels is the 'ESC' key.
The definition of an 'XID' key is similar to the 'AID' key in that it can be
defined on the 'XID=' operand of the ')PANEL' definition statement or as an
operand on the ')XID' statement.
The action taken by PDS when an 'XID' key is press is different from that taken
when an 'AID' key is pressed.
1. No 'Data Verification Procedure/Routine' is executed.
2. No input fields are updated.
3. In the REXX environment, rxPD will return the value of the 'XID' key
that caused the attention request.
The PD system does update the 'ZCURVAR' field when an 'XID' key is pressed if
there is an input field on the panel.
1.6 Exit Identification Keys (XID Keys) Page 21
Panel Display System (PDS)
╔══════════════════════════════════════════════════════════════════════════════╗
║ 2 Panel Definition Language ║
╚══════════════════════════════════════════════════════════════════════════════╝
The Panel Definition Language or PDL is a collection of statements that define
panels, attributes for the panels, rows of fields for the panels and attributes
for the fields of the panels.
The PDL statements reside in a simple text file that can be modified by any
normal text editor such as OS/2's 'E' or 'EPM' editors.
This text file is known a the panel library. The only restriction about the name
of the file is that it must end with a '.PNL' extension.
Each panel library is accessed only during the initialization of an instance of
the PD system for a particular application. All panel definition statements are
processed at that time and an image of the defined panels are retained in memory
for quicker access and processing of the panels when the application desires to
display a panel.
There are two main types of panel definition statements.
1. Panel attributes definition statements.
2. Panel row definition statements.
There are miscellaneous statements that are neither Panel Attributes Definition
statments nor Panel Row Definition statements.
1. Miscellaneous statements.
All PDL statements, except for one style of row definition statements, are
identified by the character ')' in column 1 of the statement.
2.1 Creating PDL Statements
The application developer can use any available text editor to create PDL
statements.
Because of the many different ways in which text editors create text records, an
understanding of how PDS processes text records is needed in order to know how
to assemble a set of PDL statements into a PANEL definition.
2 Panel Definition Language Page 22
Panel Display System (PDS)
The PD system trims all records of their trailing blank characters.
This means that any record which does not have any characters or fields defined
for that record is in effect a zero length or null record. This means that such
a record does not result in the definition of any panel fields for the row where
such a record is defined.
Horizontal tab characters are NOT expanded.
All such special characters are treated as being PDL statement characters.
In other words, Line Feeds, Vertical Tabs, Form Feeds, etc., will be treated as
displayable characters.
This allows the use of some of the specialy ANSI characters to define column
separators, panel borders, etc..
2.2 Order of PDL Statements
It is best to describe the order of the PDL statements in the panel library at
this point even tho the PDL statements have not as yet been discussed.
The PDL statements are:
1. )PANEL - Panel Definition Statement
2. )AID - Attention ID Definition Statement
3. )XID - Exit ID Definition Statement
4. )VARS - Substitution Variable Name Statement
5. )COLORS - Field Attribute Colors Statement
6. -------- - Current Row Panel Row Definition Records
7. )NULL - Null Row Statement
8. )BLANK - Blank Row Statement
9. )ROW - Explicit Row Panel Row Definition Records
10. )PROC - Data Verification Procedure Definition Statement
11. )PROCEND - Data Verification Procedure Delimiter Statement
12. )END - Panel Delimiter Statement
13. )REM - Remarks Statement
Panels are defined within the PDL library as groups of related PDL statements.
The start of a specific panel is marked by the ")PANEL" statement. The end of a
specific panel is marked by its paired ")END" statement. These two statements
delimit one entire panel. All other statements, except for the ")REM" statement,
must reside between these two statements.
2.1 Creating PDL Statements Page 23
Panel Display System (PDS)
The ordering of the other statements within the panel delimiters is dependent
upon their function and whether or not they are related to the attributes of the
panel or a row within the panel.
The ")AID" and ")XID" statement define special keystrokes to PDS for the panel
being defined. They are therefore panel attribute statements and can in fact
reside anywhere within the panel delimiters.
The ")PROC" and ")PROCEND" statements delimit a 'Data Verification Procedure'
for the panel. These delimiters may be paired anywhere within the panel, but
only valid REXX statements may reside between these 'DVP' delimiters.
If the 'DVP' is defined as the last block of statements within the panel, the
")PROCEND" is not needed because the ")END" statement will act as the default
'DVP' delimiter.
The ")COLORS" statement must be defined before any row containing a field of the
type whose color is being defined.
The ")VARS" statements must be defined before any panel row statements that
contain variable name substitition escape characters.
The "BODY" of the panel is defined by the panel row definition statements
")NULL", ")BLANK" and ")ROW".
Also, any other record between the panel delimiters which is not an explict PDL
statement is considered to be a row definition record for the "BODY" of the
panel.
The ")REM" statement is ignored by PDS and can be put anywhere in the panel
library as a convenient way to add 'Remarks' to the library. This is the only
statement that can be put within the panel delimiters which does not affect a
panel attribute, a field attribute or a row within the "BODY" of the panel.
The only valid records outside of the panel delimiters are the ")REM" statement
and blank records.
Figure 3 is a slightly modified version of the 'DEMO0001' panel which shows the
relationship of the various PDL statements.
2.2 Order of PDL Statements Page 24
Panel Display System (PDS)
Figure 3. - Example of a "COMPOSITE" display
)PANEL NAME=DEMO0001 CLS=N
)REM Define only the 'ENTER' key as the 'AID' key for this panel.
)AID ZENTER
)REM Define 'F3' and 'Alt+F4' keys as the 'XID' keys for this panel.
)XID ZF3 ZF4_A
)REM Define two substitutable variable names
)VARS sOldValue sNewValue sYesNo
)REM Override any defaulted field attribute colors
)COLORS TEXT=RED OUTPUT=WHITEHI INPUT=GREENHI
)REM Start the "BODY" of this panel
)REM Skip row # 1 and leave it untouched
)NULL
)REM Blank the rows # 2 thru # 9
)BLANK
)BLANK
)BLANK
)BLANK
)BLANK
)BLANK
)BLANK
)BLANK
)REM Reposition the current row number to # 2
)ROW 2
)REM Define rows # 2 thru # 9
╔═════════════════════════════════════════════╗
║ My PDS Application ║
║ ║
║ Old Value..: %* + ║
║ ║
║ New Value..: _* + ║
║ ║
╚═════════════════════════════════════════════╝
)REM Skip row # 10 and leave it untouched
)NULL
)REM Blank row # 11
)BLANK
)REM Jump to row # 15, column # 30 and overlay with field data.
)ROW 15 30 FLDS=" -- Type in a 'Y' here _+-- "
)REM Define a 'Data Verification Procedure' for this panel.
)PROC
/* 'ZENTER' is the only possible 'AID' key */
if sNewValue = '' then
do
2.2 Order of PDL Statements Page 25
Panel Display System (PDS)
Call rxPDZVarDefine 'ZALARM_ERROR'
sShortMsg = 'DEMO001E'
sLongMsg = ' << New Value Required >> '
rc = rxPDSetMsgText(ZBid,sShortMsg,sLongMsg,,ZALARM_ERROR)
Call rxPDSetCursorFld ZBid, ZPName, 'sNewValue'
return ZVERIFYPROC_RC_NORETURN
end
if TRANSLATE(sYesNo) <> 'Y' then
do
Call rxPDZVarDefine 'ZALARM_ERROR'
sShortMsg = 'DEMO002E'
sLongMsg = " << Value 'Y' Required >> '
rc = rxPDSetMsgText(ZBid,sShortMsg,sLongMsg,,ZALARM_ERROR)
Call rxPDSetCursorFld ZBid, ZPName, 'sYesNo'
return ZVERIFYPROC_RC_NORETURN
end
return ZVERIFYPROC_RC_RETURN
)REM Define the end of the 'Data Verification Procedure'
)PROCEND
)REM Define the end of the DEMO0001 panel.
)REM Also, define attributes for the last row of the display.
)REM These attributes are to blank out the last row and display a
)REM prompt for the end user.
)END )BLANK FLDS="<Press ENTER when done, F3 to cancel or Alt-F4 to exit>"
Figure 3 - Example of a panel which is part of a "COMPOSITE" display.
Figure 3 is an unnecessarily complex panel and should not be viewed as being too
cumbersome to define. Nor is it a necessarily good example of a PDS panel. It
merely shows the use of all of the PDL statements in the suggested order.
This type of panel is normally referred to as a "COMPOSITE" panel since the
display is not cleared, 'CLS=N', thereby causing the physical display to be
composed of whatever information was previously displayed plus the new fields
that this panel adds to the display.
The effect of this version of DEMO0001 is to explictly leave rows 1 and 10
untouched, to blank out rows 2 - 9 and 11, to write fields on rows 2 - 9, jump
to row 15, column 30 and overlay whatever is on the display at that position
with 2 text fields and an input field named 'sYesNo' and, depending upon the
depth of the physical display, reposition the current row pointer to the last
row of the display, blank out that row and write 1 text field centered within
that row.
2.2 Order of PDL Statements Page 26
Panel Display System (PDS)
Unless otherwise modified by the ")ROW" statement, the "BODY" of the panel
always begins at the upper left corner of the physical display at row # 1,
column # 1.
For this reason, the first field in the first "BODY" record will be written to
row 1, column 1 of the display. Subsequent fields on that record will be written
to the display at their respective positions within the record.
Subsequent "BODY" records increment the row counter by 1 in the order they are
processed.
This order can be modified by two PDL statements.
The ")NULL" statement is a "place holder" for the current row. This statement
causes the row counter to be incremented by 1 without defining any fields for
the current row. In effect, this preserves whatever was previously displayed on
that row when this panel is displayed.
The ")ROW" statement, in its simplest form, resets the current row pointer to a
specific value. Subsequent "BODY" records will then define fields starting with
that specific row.
In its more complex form, the ")ROW" statement resets the current row pointer to
a specific row, sets the column pointer to a specific column within that row
and defines a series of fields beginning at that position. This form of the
")ROW" statements subsequently sets the current row pointer to the following
row.
2.2 Order of PDL Statements Page 27
Panel Display System (PDS)
Figure 4. - Example of a "POPUP" panel
)PANEL NAME=DEMO0001 CLS=N AID=(ZENTER) XID=(ZF3,ZF4_A)
)VARS sYesNo
)ROW 2 18 FLDS="╔═════════════════════════════════════════════╗"
)ROW 3 18 FLDS="║ My PDS Application ║"
)ROW 4 18 FLDS="║ ║"
)ROW 5 18 FLDS="║ Old Value..: %sOldValue + ║"
)ROW 6 18 FLDS="║ ║"
)ROW 7 18 FLDS="║ New Value..: _sNewValue + ║"
)ROW 8 18 FLDS="║ ║"
)ROW 9 18 FLDS="╚═════════════════════════════════════════════╝"
)ROW 15 30 FLDS=" -- Type in a 'Y' here _+-- "
)PROC
/* 'ZENTER' is the only possible 'AID' key */
if sNewValue = '' then
do
Call rxPDZVarDefine 'ZALARM_ERROR'
sShortMsg = 'DEMO001E'
sLongMsg = ' << New Value Required >> '
rc = rxPDSetMsgText(ZBid,sShortMsg,sLongMsg,,ZALARM_ERROR)
Call rxPDSetCursorFld ZBid, ZPName, 'sNewValue'
return ZVERIFYPROC_RC_NORETURN
end
if TRANSLATE(sYesNo) <> 'Y' then
do
Call rxPDZVarDefine 'ZALARM_ERROR'
sShortMsg = 'DEMO002E'
sLongMsg = " << Value 'Y' Required >> '
rc = rxPDSetMsgText(ZBid,sShortMsg,sLongMsg,,ZALARM_ERROR)
Call rxPDSetCursorFld ZBid, ZPName, 'sYesNo'
return ZVERIFYPROC_RC_NORETURN
end
return ZVERIFYPROC_RC_RETURN
)END )BLANK FLDS="<Press ENTER when done, F3 to cancel or Alt-F4 to exit>"
Figure 4 - Example of a "POPUP" panel.
Figure 4 is a slightly different version of the 'DEMO0001' panel.
While it looks less complex that the panel shown in figure 3, they are, in fact,
almost identical in function.
2.2 Order of PDL Statements Page 28
Panel Display System (PDS)
This version uses the default field attribute colors defined for the current
instance of the PD system.
It defines only 1 substitutable variable. This is because 'sYesNo' is the only
variable that can not be defined wholey within the field.
Instead of blanking out various rows and replacing the entire row with new
display fields, it overlays the same rows with just the fields defined for
specific rows and columns.
This version of 'DEMO0001' is commonly referred to as a "POPUP" panel.
The application would normally save the current display image before displaying
this panel and then restore the display image after end user interaction with
the panel.
2.2 Order of PDL Statements Page 29
Panel Display System (PDS)
Figure 5. - Example of a "BASE" panel
)PANEL NAME=DEMO0001 CLS=Y AID=(ZENTER) XID=(ZF3,ZF4_A)
)VARS sYesNo
)COLORS TEXT=RED OUTPUT=WHITEHI INPUT=GREENHI
╔═════════════════════════════════════════════╗
║ My PDS Application ║
║ ║
║ Old Value..: %sOldValue + ║
║ ║
║ New Value..: _sNewValue + ║
║ ║
╚═════════════════════════════════════════════╝
-- Type in a 'Y' here _+--
)PROC
/* 'ZENTER' is the only possible 'AID' key */
if sNewValue = '' then
do
Call rxPDZVarDefine 'ZALARM_ERROR'
sShortMsg = 'DEMO001E'
sLongMsg = ' << New Value Required >> '
rc = rxPDSetMsgText(ZBid,sShortMsg,sLongMsg,,ZALARM_ERROR)
Call rxPDSetCursorFld ZBid, ZPName, 'sNewValue'
return ZVERIFYPROC_RC_NORETURN
end
return ZVERIFYPROC_RC_RETURN
if TRANSLATE(sYesNo) <> 'Y' then
do
Call rxPDZVarDefine 'ZALARM_ERROR'
sShortMsg = 'DEMO002E'
sLongMsg = " << Value 'Y' Required >> '
rc = rxPDSetMsgText(ZBid,sShortMsg,sLongMsg,,ZALARM_ERROR)
Call rxPDSetCursorFld ZBid, ZPName, 'sYesNo'
return ZVERIFYPROC_RC_NORETURN
end
return ZVERIFYPROC_RC_RETURN
)END FLDS="<Press ENTER when done, F3 to cancel or Alt-F4 to exit>"
2.2 Order of PDL Statements Page 30
Panel Display System (PDS)
Figure 5 - Example of a "BASE" panel.
Figure 5 is a version of the 'DEMO0001' panel commonly referred to as a "BASE"
panel since it clears the entire screen and creates the display with only those
fields defined for this panel.
This is the easiest and most common output/input form of a PDS panel.
2.2 Order of PDL Statements Page 31
Panel Display System (PDS)
2.3 Panel Attributes Definition Statements.
Panel attribute statements are statements that define panels and their
characteristics. These statements are not visible when the panel is displayed,
but the characteristics imparted by these statements may or may not visible to
the end user.
Some of the characteristics are:
1. The name of the panel.
2. Whether or not to clear the display screen when the panel is displayed.
3. What 'AID' and 'XID' keys are available to the end user for the panel.
4. What the escape characters are for the 'TEXT', 'OUTPUT' and 'INPUT' fields.
5. What the colors are for the 'TEXT', 'OUTPUT' and 'INPUT' fields.
6. What REXX statements to execute when an 'AID' key is pressed.
7. Whether or not to present the panel immediately to the end user when the
panel is displayed.
8. Whether or not to wait for the end user to press an 'AID' key.
2.3 Panel Attributes Definition Statements. Page 32
Panel Display System (PDS)
2.3.1 ")PANEL" Panel Definition Statement
This is the main PDL statement.
It is the statement which defines the beginning of a collection of PDL
statements that make up a single panel within the panel library.
This statement has a number of operands which define various attributes of the
panel.
It has the following format:
)PANEL NAME=pnlname CLR=clropt AID=(aidlist) XID=(xidlist) ATTR=attrlist
2.3.1.1 "NAME=" Panel Name Operand
This operand asigns a name to the panel being defined. It is this name by which
the panel is referrenced in all subsequent interactions with the PD system.
This operand is required.
2.3.1.2 "CLS=" Clear Screen Option
This operand tells PDS whether or not to clear the display buffer before
updating the buffer with the rows of fields defined for the panel.
CLS=Y - Clear the video buffer before constructing the panel.
CLS=N - Do not clear the video buffer. This is the default action.
2.3.1.3 "AID=" Attention ID Option
This operand defines one or more 'AID' keys for the panel.
It has the following format:
AID=(aidkey,aidkey,aidkey,...)
There should be no intervening blanks anywhere in the operand.
2.3.1 ")PANEL" Panel Definition Statement Page 33
Panel Display System (PDS)
The default for any panel which doesn't have an "AID=" operand is to have no
'AID' keys defined.
Example:
AID=(ZENTER,ZF1)
2.3.1.4 "XID=" Exit ID Option
This operand defines one or more 'XID' keys for the panel.
It has the following format:
XID=(xidkey,xidkey,xidkey,...)
There should be no intervening blanks anywhere in the operand.
The default for any panel which doesn't have an "XID=" operand is to have
just the 'ESC' key defined as an 'XID' key.
Example:
XID=(ZESC,ZF3,ZF4_A)
2.3.1.5 "ATTR=" Attribute Character(s) Option
This operand defines alternate characters as the field attributes escape
characters.
It has the following format:
ATTR=iot
Where:
'i' is the overriding 'INPUT' field attribute character.
'o' is the overriding 'OUTPUT' field attribute character.
't' is the overriding 'TEXT' field attribute character.
2.3.1.3 "AID=" Attention ID Option Page 34
Panel Display System (PDS)
Default:
ATTR=_%+
Example:
ATTR=_$+
In this example, the '$' key is defined as the 'OUTPUT' field attribute
character replacing the default '%' key.
2.3.1.5 "ATTR=" Attribute Character(s) Option Page 35
Panel Display System (PDS)
2.3.2 ")AID" Attention ID Definition Statement
This statement can be used in place of or in addition to the "AID=" operand
available on the ")PANEL" statement.
Multiple instances of this statement can be defined. Each additional statement
adds to the 'AID' key list.
This allows for the definition of large numbers of 'AID' keys for a particular
panel.
An AID key of 'ZNONE' can be defined on this statement. The only caution is that
the definition of this value deletes all preceeding 'AID' keys in the list.
It has the following format:
)AID aidkey aidkey aidkey
Example:
)AID ZENTER ZF1
2.3.3 ")XID" Exit ID Definition Statement
This statement can be used in place of or in addition to the "XID=" operand
available on the ")PANEL" statement.
Multiple instances of this statement can be defined. Each additional statement
adds to the 'XID' key list.
This allows for the definition of large numbers of 'XID' keys for a particular
panel.
An XID key of 'ZNONE' can be defined on this statement. The only caution is that
the definition of this value deletes all preceeding 'XID' keys in the list.
It has the following format:
)XID xidkey xidkey xidkey
Example:
)XID ZESC ZF3 ZF4_A
2.3.2 ")AID" Attention ID Definition Statement Page 36
Panel Display System (PDS)
2.3.4 ")VARS" Substitution Variable Name Statement
This statement is used to define a list of substitutable field variable names
for those fields whose widths are shorter than the name of the variable itself.
Multiple instances of this statement can be defined. Each additional statement
adds to the list of field substitution variable names.
This allows for the definition of large numbers of substitution variable
names for a panel.
It has the following format:
)VARS var1 var2 var3 var4
Example:
)VARS sMyField1 sMyVeryLongFieldName s2
2.3.5 ")COLORS" Field Attribute Colors Statement
This statement is used to override the colors defined for the three field
types just for this panel.
These colors are applied to the fields defined by the panel row definition
statements that immediately follow this ")COLORS" statement.
More than one ")COLORS" statement can be specified per panel. The colors of each
field type are inherited from the base colors of the current instance of the PD
system, either the default PDS values or the values specified when the
application initializes an instance of PDS, or from any preceeding ")COLORS"
statement which specifies a new value for that field type.
This allows for a single panel to have different colors for different fields of
the same type.
The only restriction is that all fields of the same type on the same row will
have the same color.
In order to have different colors for like field types on the same row, the
fields will have to be defined by the use of explicit ")ROW" definition
2.3.3 ")XID" Exit ID Definition Statement Page 37
Panel Display System (PDS)
statements. This will allow the intermixing of ")COLORS" and ")ROW" statements
for the individual fields for the same row.
It has the following format:
)COLORS OUTPUT=ocolor INPUT=icolor TEXT=tcolor BCKG=bcolor
Example:
)COLORS TEXT=WHITEHI INPUT=GREENHI
The ")COLORS" options "OUTPUT=", "INPUT=", "TEXT=" and "BCKG=" are optional and
can be declared in any order.
Refer to APPENDIX B for the list of colors supported by PDS.
2.3.5.1 "OUTPUT=" Output Color Option
The "OUTPUT=" option of the ")COLORS" statement overrides the color
to be used for 'OUTPUT' fields displayed by this panel.
2.3.5.2 "INPUT=" Input Color Option
The "INPUT=" option of the ")COLORS" statement overrides the color
to be used for 'INPUT' fields displayed by this panel.
2.3.5.3 "TEXT=" Text Color Option
The "TEXT=" option of the ")COLORS" statement overrides the color
to be used for 'TEXT' fields displayed by this panel.
2.3.5.4 "BCKG=" Background Color Option
The "BCKG=" option of the ")COLORS" statement overrides the color to be used for
the background of the fields in the panel being constructed.
2.3.5 ")COLORS" Field Attribute Colors Statement Page 38
Panel Display System (PDS)
2.3.6 ")PROC" Data Verification Procedure Definition Statement
The ")PROC" statement denotes the start of an inline Data Verification
Procedure.
The REXX statements that compose the 'DVP' follow this PDL statement.
The 'DVP' is delimited by either the ")PROCEND" or ")END" statements depending
upon the ordering of the PDL statements.
2.3.7 ")PROCEND" Data Verification Procedure Delimiter Statement
The ")PROCEND" statement denotes the end of an inline Data Verification
Procedure.
2.3.8 ")END" Panel Delimiter Statement
The ")END" statement denotes the end of a series of related PDL statements that
defined a panel.
It is also used to define a number of optional panel attributes and an optional
set of fields for the last row of the physical display.
It has the following format:
)END )BLANK )NOWAIT )NODISPLAY FLDS="fields"
Example:
)END )BLANK FLDS="< Press ENTER, F1 or F3 >"
2.3.8.1 ")BLANK" Blank the Last Row Option
The ")BLANK" is actually a keyword operand, not a PDL statement.
This operand requests that the last physical row of the panel be overwritten
with blanks when the panel is displayed.
The default is to leave the last physical row untouched.
2.3.6 ")PROC" Data Verification Procedure Definition Statemen Page 39
Panel Display System (PDS)
2.3.8.2 ")NOWAIT" Defer End User Input Option
This operand requests that a call to the routine that displays a panel does not
result in the application waiting for the end user to press an 'AID' key.
The main purpose of this operand is to allow the developer to construct a
composite display made up of multiple panels containing 'TEXT' and 'OUTPUT'
fields.
If a panel with 'INPUT' fields is displayed with this option, the 'INPUT' fields
are treated simply as 'OUTPUT' fields. Only the last panel with 'INPUT' fields
and without the ")NOWAIT" option can be used to receive input from the user.
Another purpose of this option is to be able to create simple character based
animation sequences where a series of ")NOWAIT" panels are displayed.
2.3.8.3 ")NODISPLAY" Suppress Panel Display Option
This operand requests that the video buffer not be written to the display after
the panel has been constructed.
The purpose of this operand is to allow the developer to construct a composite
display made up of multiple panels containing 'TEXT' and 'OUTPUT' fields.
It is normally used in conjunction with the ")NOWAIT" operand for the purpose of
constructing a composite display.
Optionally, the application developer might deem it important for the end user
to see the composite display being constructed. Normally however, the
construction of a composite display is fast enough that the display of a
sequence of such panels is simply a brief flicker.
Only a panel without the ")NODISPLAY" will cause the physical display to be
updated from the logical video buffer.
2.3.8.4 "FLDS=" Field Definition Option
This operand is similar to the "FLDS=" operand that is a part of the ")ROW"
definition statement.
2.3.8.1 ")BLANK" Blank the Last Row Option Page 40
Panel Display System (PDS)
Its purpose is to allow the developer to display fields on the last physical row
of the display.
Unlike this same operand on the ")ROW" statement, the fields within the "FLDS="
value are centered on the last physical row.
The default is no "FLDS=" fields.
Example:
)END FLDS="< Press Enter to Register your vote for the %* +candidate>"
In this example, when the panel is displayed, the last row of the physical
display will be overwritten with the text fields and the data contained in the
the substitution variable from the ")VARS" statement. The PD system will then
wait for the end user to press an 'AID' or 'XID' key.
2.3.8.4 "FLDS=" Field Definition Option Page 41
Panel Display System (PDS)
2.4 Panel Row Definition Statements.
Panel row definition statements are statements that define the fields which make
up the rows of a panel.
The rows and columns where fields are positioned are relative to the physical
display, not to a position within a defined panel.
In other words, all panels are positioned in the upper left corner of the
physical display at row # 1, column # 1.
Fields within the panel are positioned within that coordinate system.
The number of rows and columns can be set by the application during PDS
initialization.
2.4.1 Current Row Panel Row Definition Records
By default, any record in a PDL library which falls within the "body" of a PDS
panel that is not a specific PDL statement is considered to be a panel row
definition record.
Such a record is, by default, treated as being a row containing a single 'text'
field of displayable characters and the row is displayed at the 'current row
position' within the panel.
The 'current row position' is always set to 1 when the ")PANEL" statement is
encountered. Each subsequent panel row definition record increments this
position by 1.
Row definition records do not have to contain only 'text' fields.
Each row definition record is processed for any explicit field attribute escape
characters which denote the beginning of a field of that type.
The column where these fields are placed within the 'current row position' is
defined as being the position, within the row definition record, where the field
attribute escape character was found.
Example:
This row has an output field %iOut+at column 36 called "iOut".
2.4 Panel Row Definition Statements. Page 42
Panel Display System (PDS)
In the above example, a 'text' field starts at column 1 followed by an 'output'
field at column 36 and another 'text' field which starts at column 41 and goes
to the end of the record.
2.4.2 ")NULL" Null Row Definition Statement
The ")NULL" statement is a row definition statement which defines a zero length
row statement. This has the effect of incrementing the 'current row position'
without causing any fields to be displayed on the current row.
Note, because of the way in which the PD system trims all trailing blanks from
all PDL statements, all PDL statements which do not define any text or fields
for a row in the panel are by default 'null' PDL statements. The ")NULL" PDL
statement is included more as a method of documenting that a row is, in fact, a
null row rather than having to remember that an all blank record is also a null
row.
2.4.3 ")BLANK" Blank Row Definition Statement
The ")BLANK" statement is a row definition statement which defines a row
statement consisting of all blanks.
This has the effect of writing a blank row at the current row and subsequently
incrementing the 'current row position'.
2.4.4 ")ROW" Explicit Row Panel Row Definition Statement
The ")ROW" statement is used to explictly change the 'current row position'
to a value specified by the application developer.
There are two forms of the ")ROW" statement.
The first form simply changes the 'current row position' for subsequent row
definition statements.
This form has the following format:
)ROW rowoption
rowoption - Define the value for the 'current row pointer'.
2.4.1 Current Row Panel Row Definition Records Page 43
Panel Display System (PDS)
The second form changes the 'current row position', defines the target column
position and the field or list of fields to be displayed at the desired
row/column. The 'current row position' is subsequently incremented to the next
row of the panel.
This form has the following format:
)ROW rowoption columnoption FLDS="fielddefoption"
rowoption - Define the value for the 'current row pointer'.
columoption - Define the target column number.
fielddefoption - Define the fields for this row/column.
2.4.4.1 Target )ROW Row Option
This option of the ")ROW" statement defines either the next row number of
subsequent panel row definition records or it defines the explicit row number
for the fields defined by the "FLDS=" option of the ")ROW" statement.
2.4.4.2 Target )ROW Column Option
This option of the ")ROW" statement defines the target column number for the
fields defined by the "FLDS=" option of the ")ROW" statement.
2.4.4.3 Target )ROW "FLDS=" Field Definition Option
This option is used to define one or more fields to be placed at a specific
position within the panel.
The fields are defined identically to those defined by a panel row definition
statement. In effect, the fields look like a substring of a normal row
definition statement.
2.4.4 ")ROW" Explicit Row Panel Row Definition Statement Page 44
Panel Display System (PDS)
Figure 6. - Example of the ")ROW" statement
)PANEL NAME=DEMO0003 CLS=Y
This is ROW # 1
)ROW 12
This is ROW # 12
)ROW 17 15 FLDS="Text at 17/15 and output at 17/49 %sOutVar+"
This is ROW # 18
)END
Figure 6 - Example of the use of the ")ROW" statement.
The panel "DEMO0003" in figure 6 defines two ")ROW" statements.
The first record following the ")PANEL" statement defines a single text field
with the characters "This is ROW #1" beginning in row 1 column 1 of the panel.
The first ")ROW" statement resets the 'current row position' to 12. This
forces the following 'text' record "This is row 12" to be displayed at
row 12 of the panel.
The second ")ROW" statement resets the 'current row position' to 17, sets the
target field column as column 15 and defines 2 'text' fields and one output
field for row 17, column 15. It subsequently sets the CRP to row 18.
Assuming that the variable "sOutVar" contained the string "1234567890", the act
of displaying "DEMO0003" would result in the display shown in figure 7.
2.4.4.3 Target )ROW "FLDS=" Field Definition Option Page 45
Panel Display System (PDS)
Figure 7. - Example of the ")ROW" statement
This is ROW # 1
This is ROW # 12
Text at 17/15 and output at 17/49 12345678
This is ROW # 18
Figure 7 - Example of a display using the ")ROW" statement.
2.5 Miscellaneous PDL Statements
There is currently only one PDL statement which does not affect or otherwise
define a panel attribute or a row attribute.
2.5.1 ")REM" Remarks Statement
The ")REM" PDL statement allows the developer of the panel to add 'remarks' or
'comments' to the panel for documentation purposed.
These statements can be placed anywhere in the PDL Library.
They are explicitly ignored by the PD system when encountered within a PDL
Library.
The ")REM" as the following form:
)REM anycommentsortext
2.4.4.3 Target )ROW "FLDS=" Field Definition Option Page 46
Panel Display System (PDS)
2.6 Defining Panel Rows and Fields
As has been discussed in other sections, PDS panels are made up of rows of
fields.
What determines a panel row in a PDL Library has been shown to be any non-PDL
statement or the ")NULL", ")BLANK" or ")ROW" PDL statements.
What determines a field in a panel row is the existance of a field attribute
escape character.
The default field escape charaters are:
Plus or '+' character - Denotes the start of a 'TEXT' field.
Percent or '%' character - Denotes the start of an 'OUTPUT' field.
UnderScore or '_' character - Denotes the start of an 'INPUT' field.
These characters define the beginning of a field of the type denoted by the
character.
The source of displayable information for each type of field is either a text
string explicitly defined in the PDS panel or an indirection thru the use of a
'Variable' associated with the field.
By default, all rows in a panel start with a 'TEXT' field. In other words, any
text, encountered on a panel row, which does not have an explict field escape
character is defined to be a static 'TEXT' field.
The 'TEXT' field escape character ('+') is not normally needed. It is used only
to mark the end of an 'INPUT' or 'OUTPUT' field previously defined on that panel
row. Such a 'TEXT' field will first display a blank (' ') character in place of
the 'TEXT' escape character along with whatever other text characters follow the
'TEXT' field attribute. This will continue until the next field attribute
character is encountered.
The 'OUTPUT' field escape character defines the start of a dynamically created
field which can be used to show data defined by the application program. This
field can be used to display information that might change between each
execution of the application, such as the current date, or which changes between
each display of the panel, such as the current time.
The end if an 'OUTPUT' field is either another field attribute escape character
or the end of the PDL row definition record. This determines the width of the
2.5.1 ")REM" Remarks Statement Page 47
Panel Display System (PDS)
'OUTPUT' field and thereby the maximum amount of data which can be displayed in
the field.
Each 'OUTPUT' field also designates, either directly or indirectly, the name of
a variable created and initialized by the application program.
The name of the variable normally follows the field escape character in the row
definition record.
But, in the case where the variable name is longer that the width of the field,
a variable name substitution or indirection mechanism is provided whereby the
name of the variable is predefined by the ")VARS" PDL statement. This
variable name substitution mechanism is discussed elsewhere in this manual.
The data that is displayed at the fields position on the panel is retrieved
from the corresponding variable during the creation of the display that is done
as the result of a request by the application program to display a panel.
This means that if the application is building a "COMPOSITE" display from a
series of panels and if a variable, that was previously retrieved by a panel,
changes before the video buffer is written to the display, the display will show
the older variable value.
An example is shown in figure 8.
2.6 Defining Panel Rows and Fields Page 48
Panel Display System (PDS)
Figure 8. - Example of a "COMPOSITE" display
)PANEL NAME=DEMO0004 CLS=Y
This is ROW # 1
This is the 1st value of variable sOutVar: %sOutVar+
)END )NODISPLAY )NOWAIT
)PANEL NAME=DEMO0005 CLS=N
This is the 2nd value of variable sOutVar: %sOutVar+
This is ROW # 5
)END
/* REXX source to display "DEMO0004" and "DEMO0005" */
sOutVar=0123456789
rc=rxPDDisplay(bid,"DEMO0004")
sOutVar=ABCDEFGHIJ
rc=rxPDDisplay(bid,"DEMO0005")
Figure 8 - Example of the creation of a composite display.
If the sample REXX code in figure 8 is executed, the display shown in
figure 9 will result.
2.6 Defining Panel Rows and Fields Page 49
Panel Display System (PDS)
Figure 9. - Example of a "COMPOSITE" display
This is ROW # 1
This is the 1st value of variable sOutVar: 01234567
This is the 2nd value of variable sOutVar: ABCDEFGH
This is ROW # 5
Figure 9 - Example of a composite display.
The 'INPUT' field is in fact an 'OUTPUT/INPUT' field.
This is because the 'INPUT' field is defined with the same type of application
variable name.
This variable name is used as the source of any output data and as the target of
any end user input data.
The amount of the data displayed or entered is again determined by the width of
the 'INPUT' field.
2.6 Defining Panel Rows and Fields Page 50
Panel Display System (PDS)
╔══════════════════════════════════════════════════════════════════════════════╗
║ 3 REXX PDS Application Programming Interface ║
╚══════════════════════════════════════════════════════════════════════════════╝
The REXX PDS Application Programming Interface, or rxPD, is an OS/2 REXX
extension.
This means that the PDS routines provided by rxPD are available to all REXX
scripts once they have been defined to OS/2.
The REXX PDS interface is a procedural language interface.
This means that the application program makes a request of rxPD and interprets
the results after control is returned to the application.
3.1 Defining the REXX PDS, "RXPD", interface to OS/2
OS/2 provides a way to dynamically add REXX extension routines to the REXX
'MacroSpace' for the purpose of being able to add functionality to REXX.
To dynamically define a new routine in the REXX 'MacroSpace', the end user or
application programmer executes the 'RxFuncAdd' builtin REXX function.
The format of the call is:
CALL RxFuncAdd routinename, dllname, procedurename
'routinename' - Name by which all REXX scripts will referrence the routine.
'dllname' - Name of the Dynamic Link Library containing the procedure.
'procedurename' - Name of the routine as defined within the DLL.
Now, this call can be made for each and every one of the rxPD routines, but,
rxPD provides a simpler method of defining the rxPD routines.
Instead of defining each routine, just define the rxPDLoadFuncs routine and then
call it in order to define all of the rest of the routines.
Example:
/* Add the rxPDLoadFuncs routine to the REXX MacroSpace */
CALL RxFuncAdd 'rxPDLoadFuncs', 'HSSPD', 'rxPDLoadFuncs'
/* Call rxPDLoadFuncs to define the rest of the rxPD system */
Call rxPDLoadFuncs
3 REXX PDS Application Programming Interface Page 51
Panel Display System (PDS)
This series of calls need only to be made once before the first usage of the
rxPD system. But, since REXX extensions are dynamic extensions, these same calls
must be made each time OS/2 is rebooted. OS/2 does not remember the existance of
REXX extensions across OS/2 shutdowns.
These calls can be made by every rxPD application. Repeated calls to RxFuncAdd
to define the same routine again do not affect the REXX MacroSpace.
The 'STARTUP.CMD' is an excellent candidate for defining rxPD to OS/2 without
having to put this code into each rxPD application. Then again, having each rxPD
application define rxPD itself does simplify the installation of the rxPD
application.
The format for rxPDLoadFuncs is:
Call rxPDLoadFuncs
3.2 Initializing the RXPD environment with rxPDInit
Each rxPD application must initialize another instance of the rxPD system by
calling the 'rxPDInit' routine.
This call initializes an instance of the rxPD system and it also processes a PDL
Library for subsequent use of the panels contained therein.
This does NOT mean that a single execution of an rxPD application must
initialize a single instance of the rxPD system.
In the case of an rxPD application that requires a large number of PDS panels,
it might prove preferrable to split up the PDS panels into separate PDL
Libraries.
This will allow the application programmer to defer the initialization of a PDL
Library to a point later in the application. This can mean that a PDL Library
might not even be initialized during the processing of the application.
By defering the initialization until needed, the application programmer will
reduce the amount of initialization required at the start of the rxPD
application.
A side benefit of using multiple PDL Libraries is that each instance of the
initialization returns a handle that referrences only those PDS panels defined
in that library.
3.1 Defining the REXX PDS, "RXPD", interface to OS/2 Page 52
Panel Display System (PDS)
This can result in a minor decrease in the time it takes PDS to find and display
a panel since in this case the panels are referrenced by different handles and
the search path will be shorter than if all of the panels had been defined in
only one PDL Library.
The use of multiple PDL Libraries is only recommended in those cases where there
are a large number of panels or where the initialization time is determined to
be unacceptable for the end user.
There is a caveat when using multiple instances of rxPD within a single
application. That caveat is that any variables explicitly defined to the PD
system with the rxPDVarDefine routine are defined only for a single instance of
the rxPD interface.
If a REXX variable must be defined to rxPD and if that variable will be
processed by PDS panels from different PDL Libraries, then that variable must be
defined to each instance of rxPD if the PD system is to perform the same data
tests and manipulations defined for that variable on each panel which
referrences that variable.
The format for rxPDInit is:
bid = rxPDInit(pdllib,clriput,clroput,clrtext,clrbckg,newrow,newcol)
bid - The base ID or handle to this instance of rxPD.
pdllib - The name of the PDL Library to processed by this instance of rxPD.
The file name of the Library must NOT include the extension. By
default, PDS always appends the extension ".PNL" to the library
name before searching for the file. Except for the ".PNL"
extension, the library name can be fully qualified. The rxPDInit
routine will search the current working directory and then the
"DPATH" variable for the directory containing the PDL Library.
clriput - An optional overriding default to the base input field color for
all panels in this library.
clroput - An optional overriding default to the base output field color for
all panels in this library.
clrtext - An optional overriding default to the base text field color for
all panels in this library.
clrbckg - An optional overriding default to the base background field color
for all panels in this library.
newrow - Optionally change the number of rows for this OS/2 session.
newcol - Optionally change the number of columns for this OS/2 session.
Note, this parameter is not implemented at this time but has been
included for future referrence.)
3.2 Initializing the RXPD environment with rxPDInit Page 53
Panel Display System (PDS)
When executed, rxPDInit does the following:
1. Saves an image of the current video display, the video status and the
status of the cursor.
2. If necessary, rxPDInit changes the video mode to match the rows and
columns specified otherwise it defaults to the current video mode.
3. Processes the PDL Library.
4. If there are no errors in the PDL Library, rxPDInit returns
a handle to this instance of the rxPD system.
3.3 Terminating the RXPD environment with rxPDTerm
When an rxPD application is finished with an instance of the rxPD system, the
application should call 'rxPDTerm' to release all resources consumed by the
instance of rxPD created by 'rxPDInit'
The format for rxPDTerm is:
rc = rxPDTerm(bid)
rc - Return code should be 0.
bid - The handle to an instance of the rxPD system.
When executed, rxPDTerm does the following:
1. If necessary, rxPDTerm restores the video mode to match the rows and
columns at the time of the rxPDInit.
2. Restores the cursor and the video state.
3. Restores the image of the current video display that was saved by
rxPDInit.
3.2 Initializing the RXPD environment with rxPDInit Page 54
Panel Display System (PDS)
3.4 Displaying a PDS panel with rxPDDisplay
To display a panel or to build a composite display from a panel, the rxPD
application calls the 'rxPDDisplay' routine.
This routine displays the panel and optionally positions the cursor to a
specific input field and index within that field.
The format for rxPDDisplay is:
akey = rxPDDisplay(bid,pnlname,fldname,fldndx)
akey - The AID/XID key pressed by the end users.
bid - The handle to an instance of the rxPD system.
pnlname - The name of a panel owned by the bid.
fldname - Optional name of an input field where the cursor is to be placed.
fldndx - Optional cursor index within the cursor field.
When executed, rxPDDisplay does the following:
1. Searchs for a matching panel owned by the bid.
2. Updates the video buffer with all fields defined for the panel.
3. Optionally flushes the video buffer to the display.
4. Optionally positions the cursor on a specific input field.
5. Optionally waits for the end user to press and AID or XID key.
The rxPDDisplay routine normally returns either an AID key or an XID key.
This key will have a value, defined by PDS, with the format of:
akey = "extendedkey shiftstate asciicode scancode"
E.G. akey = "00 01 1B 01"
The above example is the value returned if the end user pressed the 'ESC' key.
Note, do NOT depend upon the format described above. It is not guarenteed to
stay the same format. Instead, use the 'rxPDZVarDefine' routine to define the
'Z' variables which can be used to test the values returned via the 'akey'
variable.
3.4 Displaying a PDS panel with rxPDDisplay Page 55
Panel Display System (PDS)
One variation on the above format is that the 'Data Verification Procedure'
can return an integer as a return code instead of an AID/XID key.
This is entirely up to the application programmer who creates the 'DVP' for a
panel. To test for an integer instead of an AID/XID key, use the builtin
REXX 'DATATYPE' function to test for a 'NUM' value.
3.5 Saving an image of the display with rxPDSaveScreen
To save a copy of the current display image, use the 'rxPDSaveScreen' routine.
The format for rxPDSaveScreen is:
svid = rxPDSaveScreen(bid)
svid - The handle to the saved image.
bid - The handle to an instance of the rxPD system.
3.6 Restoring an image of the display with rxPDRestoreScreen
To restore a copy of the display image, use the 'rxPDRestoreScreen' routine.
The format for rxPDSaveScreen is:
rc = rxPDRestoreScreen(bid,svid)
rc - Return code should be 0.
bid - The handle to an instance of the rxPD system.
svid - The handle to the saved image.
3.7 Setting an error or informational message with rxPDSetMsgText
The PD system allows the application developer to request that a text message be
displayed regardless of what panel is displayed.
In the case of a 'DVP' which returns with the ZVERIFY_RC_NORETURN value, this
same message will also be displayed when control is returned to PDS.
The message text actually has 3 optional parts and an audible cue which the
developer can request be displayed.
3.4 Displaying a PDS panel with rxPDDisplay Page 56
Panel Display System (PDS)
The format for rxPDSetMsgText is:
rc = rxPDSetMsgText(bid,shortmsg,longmsg,popuppanel,alarm)
rc - Return code should be 0.
bid - The handle to an instance of the rxPD system.
shortmsg - An optional short message.
This short message is displayed in the lower left corner of the
physical display.
longmsg - An optional long message.
This long message is displayed centered on the bottom row of the
physical display.
popuppanel - An optional popup panel name.
This panel is displayed by PDS via an internal call to
rxPDDisplay so any panel may be used.
alarm - The optional audible beep.
This audible cue can be either a warning, error or severe level
cue.
The way in which PDS handles the displaying of the 3 optional messages is
dependent upon what is requested on the call to rxPDSetMsgText.
When PDS determines that there is a message(s) to be displayed then it displays
the first non-null option specified by the call.
Subsequent to the display of the first non-null option, the 'F1' key will
automatically display the next non-null option in the list. This is repeated
until all messages are displayed or until either the 'ESC' key or any other key
is pressed. If any key other than 'F1' or 'ESC' is pressed, then that key is
processed by PDS as a valid key for any input field currently being displayed.
An example of this can be seen in figure 10.
3.7 Setting an error or informational message with rxPDSetMsgTe Page 57
Panel Display System (PDS)
Figure 10. - Example of setting message text
)PANEL NAME=DEMO0006 CLS=Y
This is ROW # 1
Please enter a value for variable sOutVar: _sOutVar+
)END )NODISPLAY )NOWAIT
)PANEL NAME=ERROR001 CLS=N XID=(ZESC) AID=(ZNONE)
)COLORS TEXT=RED OUTPUT=YELLOWHI
)ROW 10 15 FLDS="The value specified is in error: %sErrVal+"
)END
/* Set the error message text */
sErrVal=sOutVar
sOutVar="**********"
rc=rxPDSetMsgText(bid,"ERR0001E"," <INVALID VALUE> ","ERROR001")
rc=rxPDDisplay(bid,"DEMO0006")
Figure 10 - Example of setting a message text.
In figure 10, a popup panel and some REXX code is shown which specifies three of
the message options. The result of displaying the "DEMO0006" panel is shown in
figure 11 (assuming a display of only 25 rows).
3.7 Setting an error or informational message with rxPDSetMsgTe Page 58
Panel Display System (PDS)
Figure 11. - Example of a short message
This is ROW # 1
Please enter a value for variable sOutVar: ********
ERR0001E
Figure 11 - Example of a short message.
As can be seen in figure 11 the short message text "ERR0001E" is displayed
along with the "DEMO0006" panel.
If the 'ESC' key were pressed, then this short message would be cleared.
If the 'F1' key were pressed, then the display would look like that in figure
12, otherwise any other key would be processed as normal resulting in the
dismissal of the message text options.
3.7 Setting an error or informational message with rxPDSetMsgTe Page 59
Panel Display System (PDS)
Figure 12. - Example of a long message
This is ROW # 1
Please enter a value for variable sOutVar: ********
ERR0001E <INVALID VALUE>
Figure 12 - Example of a long message.
As can be seen in figure 12 the long message text " <INVALID VALUE> " is now
displayed along with the "ERR0001E" message.
If the 'ESC' key were pressed, then both messages would be cleared.
If the 'F1' key were pressed, then the display would look like that in figure
13, otherwise any other key would be processed as normal resulting in the
dismissal of the message text options.
3.7 Setting an error or informational message with rxPDSetMsgTe Page 60
Panel Display System (PDS)
Figure 13. - Example of a "POPUP" panel
This is ROW # 1
Please enter a value for variable sOutVar: ********
The value specified is in error: ABCDEFGH
ERR0001E <INVALID VALUE>
Figure 13 - Example of a popup panel.
As can be seen in figure 13 the popup panel "ERROR001" is displayed along with
both the short and long messages.
Notice that only the 'ESC' key can be pressed for this panel.
PDS does NOT override the AID/XID keys defined for the popup panel "ERROR001".
It is up to the application developer to design error popup panels such that
they will conform in some degree to the standards set for the short and long
message fields. In this particular case, the 'ESC' is specifically defined as
the XID for this panel. This will allow the end user to dismiss the popup panel
without passing this key on to panel "DEMO0006".
If the developer wanted to allow the end user to type into the sOutVar field,
then an XID=(ZALL) should have been coded for panel "DEMO0006".
3.7 Setting an error or informational message with rxPDSetMsgTe Page 61
Panel Display System (PDS)
This would pass all but the 'ESC' key on to the "DEMO0006" panel.
Regardless of what is defined for either the "DEMO0006" or "ERROR001" panel's
AID or XID options, PDS always consumes the 'ESC' key as a request to clear the
display of all message text fields or panel.
3.8 Setting the target field for the cursor with rxPDSetCursorFld
By default, the rxPD system always places the cursor over the first byte of the
first input field on a panel.
The rxPD application can override this cursor placement either by specifying a
target cursor field on the call to 'rxPDDisplay' or by using the
'rxPDSetCursorFld' routine.
The format for rxPDSetCursorFld is:
rc = rxPDSetCursorFld(bid,pnlname,fldname,fldndx)
rc - Return code should be 0.
bid - The handle to an instance of the rxPD system.
pnlname - The name of a panel.
fldname - The name of a field within the panel.
fldndx - Optional index within the field where the cursor is to be
positioned. If not specified or if a value out of range of the
width of the field is specified, then the cursor index will be set
to the first byte within the field.
The 'rxPDSetCursorFld' is a deferred action routine whereby the application can
request that the cursor be placed on a specific input field of a panel prior to
the displaying of that panel by 'rxPDDisplay' or when a 'Data Verification
Procedure' returns ZVERIFY_RC_NORETURN to suppress the return of an AID key.
It is this second reason that makes 'rxPDSetCursorFld' most useful.
A 'DVP' can be written such that it determines that a field contains invalid
data, sets an error message and positions the cursor over the data in question.
An example of this can be seen in figure 14.
3.7 Setting an error or informational message with rxPDSetMsgTe Page 62
Panel Display System (PDS)
Figure 14. - Example of setting a cursor field
)PANEL NAME=DEMO0007 CLS=Y AID=(ZENTER)
This is ROW # 1
Please enter any value for variable sTxtVar: _sTxtVar+
Please enter a numeric value for variable sNumVar: _sNumVar+
)PROC
/* Determine the validity of the variable 'sNumVar' */
if DATATYPE(sNumVar) <> 'NUM' then
do
rc=rxPDSetMsgText(bid,"ERR0002E"," <NON-NUMERIC VALUE> ","ERROR002")
rc=rxPDSetCursorFld(bid,"DEMO0007","sNumVar")
Call rxPDZVarDefine "ZVERIFY_RC_NORETURN"
return ZVERIFY_RC_NORETURN
end
return ZKey
)END )NODISPLAY )NOWAIT
)PANEL NAME=ERROR002 CLS=N XID=(ZESC) AID=(ZNONE)
)COLORS TEXT=RED OUTPUT=YELLOWHI
)ROW 10 15 FLDS="The value specified for sNumVar is not numeric."
)END
Figure 14 - Example of setting a cursor field.
In figure 14, panel "DEMO0007" is designed such that the 'ENTER' key is the only
AID key for the panel and a 'Data Verification Procedure' will be executed when
the 'ENTER' key is pressed.
When the "DEMO0007" panel is displayed, the PD system will display the text
fields of the panel and the values contained in the variables "sTxtVar" and
"sNumVar" and it will position the cursor over the first byte in the "sTxtVar"
field. The PD system will then wait for the end user to press the 'ENTER' key.
When the 'ENTER' key is pressed, the following will occur:
1. A copy of the variable "sNumVar" is created in the REXX shared variable pool
for the 'Data Verification Procedure'.
2. The 'DVP' is called.
3. The 'DVP' checks the type of data that "sNumVar" contains.
3A. If the data is not numeric.
3A1. Set a short, long and panel to be displayed.
3.8 Setting the target field for the cursor with rxPDSetCursorF Page 63
Panel Display System (PDS)
3A2. Set the target cursor position to the "sNumVar" field.
3A3. Ask rxPD to define the value for the return code that suppresses the
return of the AID key to the application.
3A4. Return the "NoReturn" code to PDS.
3A5. PDS will display the short message text.
3A6. PDS will position the cursor over byte 1 of the "sNumVar" field.
3A7. PDS will then wait for the end user to press 'ENTER'.
3B. If the data is numeric.
3B1. Return the AID key to PDS.
3B2. PDS will return the AID key to the application.
3.9 Defining variable attributes with rxPDVarDefine
As has been discussed in another section, a number of attributes can be defined
for a variable which will affect how PDS will process that variable.
The rxPD routine which assigns attributes to variables is the 'rxPDVarDefine'
routine.
The format for rxPDVarDefine is:
rc = rxPDVarDefine(bid,varname,varattrib,precision)
rc - Return code should be 0.
bid - The handle to an instance of the rxPD system.
varname - The name of the variable being defined.
varattrib - Attribute(s) being assigned to the variable.
precision - The optional precision size to be used for a variable being
assigned the floating point or integer attribute.
The values for the variable attributes are defined as 'Z' variables by the
'rxPDZVarDefine' routine.
The attributes are:
ZVTYPE_ZSTRING - Variable is a text string (default).
ZVTYPE_LONG - Variable is an integer.
ZVTYPE_DOUBLE - Variable is a floating point number.
ZVTYPE_RIGHTADJUST - Variable is to be right adjusted on output.
ZVTYPE_LZEROFILL - Variable is to be padded on the left with zeros.
ZVTYPE_GLOBAL - Variable is global in scope for all 'DVP's.
To assign multiple attributes to a single variable, the above values must be
added together when the variable is defined.
3.8 Setting the target field for the cursor with rxPDSetCursorF Page 64
Panel Display System (PDS)
Example:
rc = rxPDVarDefine(bid,"sNumVar", ZVTYPE_LONG+ZVTYPE_RIGHTADJUST, 4)
The above example will define the variable "sNumVar" as being an integer which
will always be right adjusted whenever it is processed for output by the PD
system. The variable will always have at least 4 bytes of precision displayed on
output.
Note, the same variable can be defined more than once. But, only the most recent
definition is used when processing the variable.
3.10 Deleting variable attributes with rxPDVarDelete
Just as an rxPD application can define attributes for a variable, the
application can also delete previously defined attributes.
This attribute deletion is not a subtraction of a single attribute, but is
instead a deletion of the variable name from the PD system's list of 'VDefined'
variables.
When used in concert with multiple calls to 'rxPDVarDefine' for a single
variable, 'rxPDVarDelete' allows the application developer to 'PUSH' a new
attribute for a variable with 'rxPDVarDefine' and to 'POP' the new attribute
with 'rxPDVarDelete'.
The format for rxPDVarDelete is:
rc = rxPDVarDelete(bid,varname)
rc - Return code should be 0.
bid - The handle to an instance of the rxPD system.
varname - The name of the variable being deleted.
3.9 Defining variable attributes with rxPDVarDefine Page 65
Panel Display System (PDS)
3.11 Querying a panel's field 'MDT' state with rxPDQueryMDT
In order to simplify the processing of input fields by an rxPD application, a
couple of rxPD routines are provided which help determine the state of the input
fields for a panel.
The first of these routines is the 'rxPDQueryMDT' routine.
The acronym 'MDT' is an arcane term known as "Modified Data Tag" which will be
familiar to some mainframe programmers.
What it refers to is a 'Changed' state for an input field.
Whenever an end user modifieds an input field for a panel in any way, PDS turns
on the 'MDT' state for that input field.
The application can query this state for any or all fields on the panel just
displayed or any panel which has been previously displayed.
In other words, PDS clears all 'MDT's for all input fields for a panel being
displayed. It then sets the 'MDT' for any field the user modifies. It retains
this state for each field until the panel is again displayed by the application.
This 'MDT' state latency can be used by the application programmer to remember
the path an end user took to get where they are in the execution of the
application.
It is used mainly to determine whether or not the end user modified the data in
a field without having to make copies of a variable prior to displaying a panel
containing the variable.
Use of this routine greatly reduces the amount of application code required to
process a panel with a large number of input fields.
The format for rxPDQueryMDT is:
cnt = rxPDQueryMDT(bid,pnlname,fldname)
cnt - Either the 'MDT' state of the variable or the count of all modified
fields on the panel.
bid - The handle to an instance of the rxPD system.
pnlname - The name of the panel being queried.
fldname - The optional name of the field being queried.
The 'rxPDQueryMDT' returns a number possible values depending upon whether or
3.11 Querying a panel's field 'MDT' state with rxPDQueryMDT Page 66
Panel Display System (PDS)
not a field name was specified.
If a 'fldname' is specified when 'rxPDQueryMDT' is called, then either a 0
(FALSE) or a 1 (TRUE) is returned depending upon both the existance of the field
in the panel and the 'MDT' state of the field.
Example:
mdtstate = rxPDQueryMDT(bid,"DEMO0007","sNumVar")
In the above example, the variable 'mdtstate' will contain either a 0,
indicating the field "sNumVar" was not modified, or a 1, indicating that
"sNumVar" was modified.
If a 'fldname' is NOT specified when 'rxPDQueryMDT' is called, then either a 0
(NONE) or a value greater than 0 (COUNT) is returned.
Example:
mdtcount = rxPDQueryMDT(bid,"DEMO0007")
In the above example, the variable 'mdtcount' will contain either a 0,
indicating that no fields were modified, or in the case of our "DEMO0007" panel
a value from 1 to 2 depending upon which fields, "sTxtVar" and/or "sNumVar",
were modified.
3.12 Querying a panel's modified field names with rxPDQueryMDTFld
Another rxPD routine which helps an rxPD application process the input fields
for a panel is the 'rxPDQueryMDTFld' routine.
The purpose of this routine is to retrieve the name of a field which has the
'MDT' state set on.
Instead of querying the 'MDT' state of each input field on a panel, the rxPD
application can ask for the name of a modified field on the panel.
This is done by calling 'rxPDQueryMDTFld' with an index representing the which
modified field name to return.
The format for rxPDQueryMDTFld is:
fld = rxPDQueryMDTFld(bid,pnlname,fldindx)
3.11 Querying a panel's field 'MDT' state with rxPDQueryMDT Page 67
Panel Display System (PDS)
fld - Either the field name of a modified field or a null string
representing no such field.
bid - The handle to an instance of the rxPD system.
pnlname - The name of the panel being queried.
fldindx - The index number of a possible modified field.
The 'fldindx' value is not the number of a field on the panel, but the number of
a modified field on the panel.
In other words, a panel might contain 6 fields, but only 3 of the fields might
have been modified by the user. The highest 'fldindx' value for this panel would
be an index of 3.
While this might seem unusual, it removes the requirement that an application
know what field is in what order on a panel.
Instead, an application need only know what field names are on the panel and the
count of the modified fields on the panel.
Since the count of modified fields can be queried by the 'rxPDQueryMDT' routine,
the use of both routines can greatly decrease the perceived response time of an
rxPD application.
Example:
mdtcount = rxPDQueryMDT(bid,"DEMO0007") /* Retrieve the count */
do i = 1 to mdtcount
fld = rxPDQueryMDTFld(bid,"DEMO0007",i) /* Retrieve a 'MDT' field name */
select
when fld = 'sTxtVar' then
do
Call rProcessText sTxtVar
end
when fld = 'sNumVar' then
do
Call rProcessNumber sNumVar
end
otherwise
do
SIGNAL UNKNOWNFIELD
end
end /*select*/
end /*do i = 1 to mdtcount*/
The above example shows how to skip thru the possible modified fields of the
panel "DEMO0007".
3.12 Querying a panel's modified field names with rxPDQueryMDTF Page 68
Panel Display System (PDS)
If in fact only the "sNumVar" field was modified, then only that field will be
processed. The same is true of the "sTxtVar" field. If both fields were
modified, then both fields would be processed.
Now, in the above example, only two fields are possible and in that situation it
would probably be faster to test each field separately with the 'rxPDQueryMDT'
routine. But, the example code is still valid in this case.
It is best to note here that the order in which the names of the modified fields
are retrieved from the PD system's list of modified fields is dependent upon the
order the fields were defined for the panel within the PDL Library.
3.13 Retrieving predefined variable values with rxPDVDefVarRetrieve
By design, 'Data Verification Procedure's are executed as REXX procedures.
This means that they can not see any variables outside the scope of their
execution.
By design, the PD system automatically creates certain 'Z' variables in the
shared variable pool of the 'DVP' along with a copy of each input field on the
panel that defined the 'DVP'.
Only these variables are immediately accessable by the 'DVP'.
However, there may be times that a 'Data Verification Procedure' may need to to
be able to test a panel's field value against a variable that is not within the
'DVP's variable pool.
A way has been provided by which a 'DVP' can retrieve variables from the rxPD
application which are not available from the panel.
This is done by a combination of 'Defined' variables and the
'rxPDVDefVarRetrieve' routine.
Variables which have been defined to PDS with the ZVTYPE_GLOBAL attribute are
available to the 'DVP' if it needs access to such a variable.
In order to keep the performance of a 'DVP' as responsive as possible, none of
these variables are automatically defined in the 'DVP's variable pool.
Instead, these variables must be explicitly retrieved by the 'DVP' with the
'rxPDVDefVarRetrieve' routine.
3.12 Querying a panel's modified field names with rxPDQueryMDTF Page 69
Panel Display System (PDS)
The format for rxPDVDefVarRetrieve is:
fld = rxPDVDefVarRetrieve(bid,pid,fldname)
fld - The field to recieve the data contained in the 'VDefined'
ZVTYPE_GLOBAL variable.
bid - The handle to an instance of the rxPD system.
pid - The handle of the panel which owns the 'DVP'.
fldname - The name of a variable defined as ZVTYPE_GLOBAL.
The bid is the base handle to this instance of the PD system and is passed to
the 'DVP' in the variable 'ZBid'.
The pid is the handle to the panel which owns the currently executing 'DVP'.
This handle was passed to the 'DVP' in the variable 'ZPid'. This handle must be
used instead of the panel name. This insures that only 'DVP's can call the
'rxPDVDefVarRetrieve' routine.
See figure 15 for an example of 'rxPDVDefVarRetrieve'.
3.13 Retrieving predefined variable values with rxPDVDefVarRetri Page 70
Panel Display System (PDS)
Figure 15. - Example of retrieving variables
)PANEL NAME=DEMO0008 CLS=Y AID=(ZENTER)
This is ROW # 1
Please change the value for variable sTxtVar: _sTxtVar+
)PROC
/* Retrieve original value for variable 'sTxtVar' into a different variable */
sOldTxtVar = rxPDVDefVarRetrieve(ZBid,ZPid,"sTxtVar")
/* Test to insure that 'sTxtVar' has been changed as required. */
if sOldTxtVar = sTxtVar then
do
rc=rxPDSetMsgText(bid,"ERR0003E"," <INVALID VALUE> ")
rc=rxPDSetCursorFld(bid,"DEMO0008","sTxtVar")
Call rxPDZVarDefine "ZVERIFY_RC_NORETURN"
return ZVERIFY_RC_NORETURN
end
return ZKey
)END )NODISPLAY )NOWAIT
/* First define sTxtVar to the PD system */
Call rxPDVarDefine bid, "sTxtVar", ZVTYPE_GLOBAL
/* Now set sTxtVar to the current value */
sTxtVar = "CurValue"
akey = rxPDDisplay(bid,"DEMO0008")
Figure 15 - Example of retrieving variables
In figure 15, panel "DEMO0008" is designed such that when the 'ENTER'
key is pressed, the 'Data Verification Procedure' will be executed.
This 'DVP' will retrieve the value of 'sTxtVar' as it was when the 'DVP' was
called and compare it to the value of 'sTxtVar' as it is on the panel
"DEMO0008". If they are still the same, then that is considered to be an error
situation.
Note that the variable 'sTxtVar' was defined to PDS as a 'Global' variable
before the variable was defined and initialized. This is acceptable as the PD
system doesn't search the REXX variable pool for 'Global' variables until it
becomes necessary to call the 'DVP'.
3.14 Dynamically setting Field colors with rxPDSetFldColors
3.13 Retrieving predefined variable values with rxPDVDefVarRetri Page 71
Panel Display System (PDS)
An rxPD application can dynamically set the foreground and background colors for
any specific Input or Output field on a specific panel.
This allows a PDS application to draw attention to a specific field by altering
the foreground and/or background colors in order to emphasize the data in the
field.
The colors which can be specified are the same as those which can be defined
within the PDL library and specified on the rxPDInit call.
The format for rxPDSetFldColors is:
rc = rxPDSetFldColors(bid,pnlname,fldname,fcolor,bcolor)
rc - Return code should be 0.
bid - The handle to an instance of the rxPD system.
pnlname - The name of a panel.
fldname - The name of a field within the panel.
fcolor - The optional new foreground color for the field.
bcolor - The optional new background color for the field.
If neither the foreground nor the background color is specified, PDS will swap
the field's current foreground and background colors resulting in an inverse
video effect.
3.14 Dynamically setting Field colors with rxPDSetFldColors Page 72
Panel Display System (PDS)
3.15 Dynamically setting Panel colors with rxPDSetPnlColors
A PDSAPI application can dynamically set the foreground and background colors
for all Input, Output or Text fields on a specific panel.
This allows a PDS application to highlight the fields, of a specific type, on a
panel by modifying the foreground and/or background colors of that type of
field(s).
The colors which can be specified are the same as those which can be defined
within the PDL library and specified on the rxPDInit call.
The format for rxPDSetPnlColors is:
rc = rxPDSetPnlColors(bid,pnlname,icolor,ocolor,tcolor,bcolor)
rc - Return code should be 0.
bid - The handle to an instance of the rxPD system.
pnlname - The name of a panel.
icolor - The optional new foreground color for all 'INPUT' fields.
ocolor - The optional new foreground color for all 'OUTPUT' fields.
tcolor - The optional new foreground color for all 'TEXT' fields.
bcolor - The optional new background color for all matching fields.
One or more of the field types can be specified on one call to rxPDSetPnlColors.
The background color field applies to all field types specified on the call.
Example:
rc = rxPDSetPnlColors(bid, "PANEL001", NULL, "WHITE", "WHITE", "BLACK");
In the above example all 'OUTPUT' and 'TEXT' fields would be changed to 'WHITE'
on 'BLACK'. Neither the foreground nor the background colors for any 'INPUT'
fields would be changed.
Example:
rc = rxPDSetPnlColors(bid, "PANEL001", "REDHI", NULL, "REDHI", NULL);
In the above example all 'INPUT' and 'TEXT' fields would have their foreground
colors changed to 'REDHI'. Their background colors would not change.
3.15 Dynamically setting Panel colors with rxPDSetPnlColors Page 73
Panel Display System (PDS)
╔══════════════════════════════════════════════════════════════════════════════╗
║ APPENDIX A - REXX AID/XID Keys and other 'Z' Values ║
╚══════════════════════════════════════════════════════════════════════════════╝
This appendix lists the "Z" values used by rxPD routines and the
panels' REXX Data Verification Procedures.
It is not recommended that the following REXX statements be used by
any REXX script, instead a REXX procedure should use the rxPDZVarDefine
routine to define selected values as variables in the REXX variable
pool as needed.
/* The following define the REXX AID/XID keys. */
ZBACKSPC = "00 00 08 0E"
ZBACKSPC_S = "00 01 08 0E"
ZBACKSPC_A = "01 02 00 0E"
ZBACKSPC_C = "00 04 7F 0E"
ZESC = "00 00 1B 01"
ZESC_S = "00 01 1B 01"
ZESC_A = "00 00 00 00"
ZESC_C = "00 00 00 00"
ZENTER = "00 00 0D 1C"
ZENTER_S = "00 01 0D 1C"
ZENTER_A = "01 02 00 1C"
ZENTER_C = "00 04 0A 1C"
ZENTER_KPAD = "00 00 0D E0"
ZENTER_KPAD_S = "00 01 0D E0"
ZENTER_KPAD_A = "01 02 00 A6"
ZENTER_KPAD_C = "00 04 0A E0"
ZTAB = "00 00 09 0F"
ZTAB_S = "01 01 00 0F"
ZTAB_A = "01 02 00 A5"
ZTAB_C = "01 04 00 94"
ZHOME = "01 00 E0 47"
ZHOME_S = "01 01 E0 47"
ZHOME_A = "00 00 00 00"
ZHOME_C = "01 04 E0 77"
ZHOME_KPAD = "01 00 00 47"
ZHOME_KPAD_S = "00 01 37 47"
ZHOME_KPAD_A = "00 00 07 00"
ZHOME_KPAD_C = "01 04 00 77"
ZEND = "01 00 E0 4F"
ZEND_S = "01 01 E0 4F"
ZEND_A = "01 02 00 9F"
ZEND_C = "01 04 E0 75"
APPENDIX A - REXX AID/XID Keys and other 'Z' Values Page 74
Panel Display System (PDS)
ZEND_KPAD = "01 00 00 4F"
ZEND_KPAD_S = "00 01 31 4F"
ZEND_KPAD_A = "00 00 01 00"
ZEND_KPAD_C = "01 04 00 75"
ZINSERT = "01 00 E0 52"
ZINSERT_S = "01 01 E0 52"
ZINSERT_A = "01 02 00 A2"
ZINSERT_C = "01 04 E0 92"
ZINSERT_KPAD = "01 00 00 52"
ZINSERT_KPAD_S = "00 01 30 52"
ZINSERT_KPAD_A = "00 00 00 00"
ZINSERT_KPAD_C = "01 04 00 92"
ZDELETE = "01 00 E0 53"
ZDELETE_S = "01 01 E0 53"
ZDELETE_A = "01 02 00 A3"
ZDELETE_C = "01 04 E0 93"
ZDELETE_KPAD = "01 00 00 53"
ZDELETE_KPAD_S = "00 01 2E 53"
ZDELETE_KPAD_A = "00 00 00 00"
ZDELETE_KPAD_C = "01 04 00 93"
ZF1 = "01 00 00 3B"
ZF1_S = "01 01 00 54"
ZF1_A = "01 02 00 68"
ZF1_C = "01 04 00 5E"
ZF2 = "01 00 00 3C"
ZF2_S = "01 01 00 55"
ZF2_A = "01 02 00 69"
ZF2_C = "01 04 00 5F"
ZF3 = "01 00 00 3D"
ZF3_S = "01 01 00 56"
ZF3_A = "01 02 00 6A"
ZF3_C = "01 04 00 60"
ZF4 = "01 00 00 3E"
ZF4_S = "01 01 00 57"
ZF4_A = "01 02 00 6B"
ZF4_C = "01 04 00 61"
ZF5 = "01 00 00 3F"
ZF5_S = "01 01 00 58"
ZF5_A = "01 02 00 6C"
ZF5_C = "01 04 00 62"
ZF6 = "01 00 00 40"
ZF6_S = "01 01 00 59"
ZF6_A = "01 02 00 6D"
ZF6_C = "01 04 00 63"
ZF7 = "01 00 00 41"
ZF7_S = "01 01 00 5A"
APPENDIX A - REXX AID/XID Keys and other 'Z' Values Page 75
Panel Display System (PDS)
ZF7_A = "01 02 00 6E"
ZF7_C = "01 04 00 64"
ZF8 = "01 00 00 42"
ZF8_S = "01 01 00 5B"
ZF8_A = "01 02 00 6F"
ZF8_C = "01 04 00 65"
ZF9 = "01 00 00 43"
ZF9_S = "01 01 00 5C"
ZF9_A = "01 02 00 70"
ZF9_C = "01 04 00 66"
ZF10 = "01 00 00 44"
ZF10_S = "01 01 00 5D"
ZF10_A = "01 02 00 71"
ZF10_C = "01 04 00 67"
ZF11 = "01 00 00 85"
ZF11_S = "01 01 00 87"
ZF11_A = "01 02 00 8B"
ZF11_C = "01 04 00 89"
ZF12 = "01 00 00 86"
ZF12_S = "01 01 00 88"
ZF12_A = "01 02 00 8C"
ZF12_C = "01 04 00 8A"
ZPGUP = "01 00 E0 49"
ZPGUP_S = "01 01 E0 49"
ZPGUP_A = "01 02 00 99"
ZPGUP_C = "01 04 E0 84"
ZPGUP_KPAD = "01 00 00 49"
ZPGUP_KPAD_S = "00 01 39 49"
ZPGUP_KPAD_A = "00 00 09 00"
ZPGUP_KPAD_C = "01 04 00 84"
ZPGDW = "01 00 E0 51"
ZPGDW_S = "01 01 E0 51"
ZPGDW_A = "01 02 00 A1"
ZPGDW_C = "01 04 E0 76"
ZPGDW_KPAD = "01 00 00 51"
ZPGDW_KPAD_S = "00 01 33 51"
ZPGDW_KPAD_A = "00 00 03 00"
ZPGDW_KPAD_C = "01 04 00 76"
ZARRWUP = "01 00 E0 48"
ZARRWUP_S = "01 01 E0 48"
ZARRWUP_A = "01 02 00 98"
ZARRWUP_C = "01 04 E0 8D"
ZARRWUP_KPAD = "01 00 00 48"
ZARRWUP_KPAD_S = "00 01 38 48"
ZARRWUP_KPAD_A = "00 00 08 00"
ZARRWUP_KPAD_C = "01 04 00 8D"
APPENDIX A - REXX AID/XID Keys and other 'Z' Values Page 76
Panel Display System (PDS)
ZARRWLEFT = "01 00 E0 4B"
ZARRWLEFT_S = "01 01 E0 4B"
ZARRWLEFT_A = "01 02 00 9B"
ZARRWLEFT_C = "01 04 E0 73"
ZARRWLEFT_KPAD = "01 00 00 4B"
ZARRWLEFT_KPAD_S = "00 01 34 4B"
ZARRWLEFT_KPAD_A = "00 00 04 00"
ZARRWLEFT_KPAD_C = "01 04 00 73"
ZARRWRIGHT = "01 00 E0 4D"
ZARRWRIGHT_S = "01 01 E0 4D"
ZARRWRIGHT_A = "01 02 00 9D"
ZARRWRIGHT_C = "01 04 E0 74"
ZARRWRIGHT_KPAD = "01 00 00 4D"
ZARRWRIGHT_KPAD_S = "00 01 36 4D"
ZARRWRIGHT_KPAD_A = "00 00 06 00"
ZARRWRIGHT_KPAD_C = "01 04 00 74"
ZARRWDOWN = "01 00 E0 50"
ZARRWDOWN_S = "01 01 E0 50"
ZARRWDOWN_A = "01 02 00 A0"
ZARRWDOWN_C = "01 04 E0 91"
ZARRWDOWN_KPAD = "01 00 00 50"
ZARRWDOWN_KPAD_S = "00 01 32 50"
ZARRWDOWN_KPAD_A = "00 00 02 00"
ZARRWDOWN_KPAD_C = "01 04 00 91"
Z_A = "00 00 61 1E"
Z_A_S = "00 01 41 1E"
Z_A_A = "01 02 00 1E"
Z_A_C = "00 04 01 1E"
Z_B = "00 00 62 30"
Z_B_S = "00 01 42 30"
Z_B_A = "01 02 00 30"
Z_B_C = "00 04 02 30"
Z_C = "00 00 63 2E"
Z_C_S = "00 01 43 2E"
Z_C_A = "01 02 00 2E"
Z_C_C = "00 00 00 00"
Z_D = "00 00 64 20"
Z_D_S = "00 01 44 20"
Z_D_A = "01 02 00 20"
Z_D_C = "00 04 04 20"
Z_E = "00 00 65 12"
Z_E_S = "00 01 45 12"
Z_E_A = "01 02 00 12"
Z_E_C = "00 04 05 12"
Z_F = "00 00 66 21"
Z_F_S = "00 01 46 21"
APPENDIX A - REXX AID/XID Keys and other 'Z' Values Page 77
Panel Display System (PDS)
Z_F_A = "01 02 00 21"
Z_F_C = "00 04 06 21"
Z_G = "00 00 67 22"
Z_G_S = "00 01 47 22"
Z_G_A = "01 02 00 22"
Z_G_C = "00 04 07 22"
Z_H = "00 00 68 23"
Z_H_S = "00 01 48 23"
Z_H_A = "01 02 00 23"
Z_H_C = "00 04 08 23"
Z_I = "00 00 69 17"
Z_I_S = "00 01 49 17"
Z_I_A = "01 02 00 17"
Z_I_C = "00 04 09 17"
Z_J = "00 00 6A 24"
Z_J_S = "00 01 4A 24"
Z_J_A = "01 02 00 24"
Z_J_C = "00 04 0A 24"
Z_K = "00 00 6B 25"
Z_K_S = "00 01 4B 25"
Z_K_A = "01 02 00 25"
Z_K_C = "00 04 0B 25"
Z_L = "00 00 6C 26"
Z_L_S = "00 01 4C 26"
Z_L_A = "01 02 00 26"
Z_L_C = "00 04 0C 26"
Z_M = "00 00 6D 32"
Z_M_S = "00 01 4D 32"
Z_M_A = "01 02 00 32"
Z_M_C = "00 04 0D 32"
Z_N = "00 00 6E 31"
Z_N_S = "00 01 4E 31"
Z_N_A = "01 02 00 31"
Z_N_C = "00 04 0E 31"
Z_O = "00 00 6F 18"
Z_O_S = "00 01 4F 18"
Z_O_A = "01 02 00 18"
Z_O_C = "00 04 0F 18"
Z_P = "00 00 70 19"
Z_P_S = "00 01 50 19"
Z_P_A = "01 02 00 19"
Z_P_C = "00 00 00 00"
Z_Q = "00 00 71 10"
Z_Q_S = "00 01 51 10"
Z_Q_A = "01 02 00 10"
Z_Q_C = "00 04 11 10"
APPENDIX A - REXX AID/XID Keys and other 'Z' Values Page 78
Panel Display System (PDS)
Z_R = "00 00 72 13"
Z_R_S = "00 01 52 13"
Z_R_A = "01 02 00 13"
Z_R_C = "00 04 12 13"
Z_S = "00 00 73 1F"
Z_S_S = "00 01 53 1F"
Z_S_A = "01 02 00 1F"
Z_S_C = "00 00 00 00"
Z_T = "00 00 74 14"
Z_T_S = "00 01 54 14"
Z_T_A = "01 02 00 14"
Z_T_C = "00 04 14 14"
Z_U = "00 00 75 16"
Z_U_S = "00 01 55 16"
Z_U_A = "01 02 00 16"
Z_U_C = "00 04 15 16"
Z_V = "00 00 76 2F"
Z_V_S = "00 01 56 2F"
Z_V_A = "01 02 00 2F"
Z_V_C = "00 04 16 2F"
Z_W = "00 00 77 11"
Z_W_S = "00 01 57 11"
Z_W_A = "01 02 00 11"
Z_W_C = "00 04 17 11"
Z_X = "00 00 78 2D"
Z_X_S = "00 01 58 2D"
Z_X_A = "01 02 00 2D"
Z_X_C = "00 04 18 2D"
Z_Y = "00 00 79 15"
Z_Y_S = "00 01 59 15"
Z_Y_A = "01 02 00 15"
Z_Y_C = "00 04 19 15"
Z_Z = "00 00 7A 2C"
Z_Z_S = "00 01 5A 2C"
Z_Z_A = "01 02 00 2C"
Z_Z_C = "00 04 1A 2C"
Z_1 = "00 00 31 02"
Z_1_S = "00 01 21 02"
Z_1_A = "01 02 00 78"
Z_1_C = "00 00 00 00"
Z_2 = "00 00 32 03"
Z_2_S = "00 01 40 03"
Z_2_A = "01 02 00 79"
Z_2_C = "01 04 00 03"
Z_3 = "00 00 33 04"
Z_3_S = "00 01 23 04"
APPENDIX A - REXX AID/XID Keys and other 'Z' Values Page 79
Panel Display System (PDS)
Z_3_A = "01 02 00 7A"
Z_3_C = "00 00 00 00"
Z_4 = "00 00 34 05"
Z_4_S = "00 01 24 05"
Z_4_A = "01 02 00 7B"
Z_4_C = "00 00 00 00"
Z_5 = "00 00 35 06"
Z_5_S = "00 01 25 06"
Z_5_A = "01 02 00 7C"
Z_5_C = "00 00 00 00"
Z_6 = "00 00 36 07"
Z_6_S = "00 01 5E 07"
Z_6_A = "01 02 00 7D"
Z_6_C = "00 04 1E 07"
Z_7 = "00 00 37 08"
Z_7_S = "00 01 26 08"
Z_7_A = "01 02 00 7E"
Z_7_C = "00 00 00 00"
Z_8 = "00 00 38 09"
Z_8_S = "00 01 2A 09"
Z_8_A = "01 02 00 7F"
Z_8_C = "00 00 00 00"
Z_9 = "00 00 39 0A"
Z_9_S = "00 01 28 0A"
Z_9_A = "01 02 00 80"
Z_9_C = "00 00 00 00"
Z_0 = "00 00 30 0B"
Z_0_S = "00 01 29 0B"
Z_0_A = "01 02 00 81"
Z_0_C = "00 00 00 00"
ZSPACE = "00 00 20 39"
ZSPACE_S = "00 01 20 39"
ZSPACE_A = "00 02 20 39"
ZSPACE_C = "00 04 20 39"
/* The following define the expected non-AID/XID key return codes that */
/* can be returned by a panel's REXX Data Verification Procedure. Any */
/* AID or XID key or other integer is returned to the routine which */
/* is displaying the panel. */
ZVERIFYPROC_RC_RETURN = 0 /* Return the current AID key */
ZVERIFYPROC_RC_NORETURN = 4 /* Don't return to panel displayer */
/* The following define the REXX variable types for rxPDVarDefine. */
=
ZVTYPE_ZSTRING = 1
APPENDIX A - REXX AID/XID Keys and other 'Z' Values Page 80
Panel Display System (PDS)
ZVTYPE_LONG = 2
ZVTYPE_DOUBLE = 4
ZVTYPE_RIGHTADJUST = 256
ZVTYPE_LZEROFILL = 512
ZVTYPE_GLOBAL = 1024
ZVTYPE_STATIC = 2048
/* The following define the alarm types for rxPDSetMsgText */
ZALARM_NOERROR = 0
ZALARM_WARNING = 1
ZALARM_ERROR = 2
ZALARM_SEVERE = 3
/* The following define the boolean tests for rxPDQueryMDT */
ZFALSE = 0
ZTRUE = 1
APPENDIX A - REXX AID/XID Keys and other 'Z' Values Page 81
Panel Display System (PDS)
╔══════════════════════════════════════════════════════════════════════════════╗
║ APPENDIX B - Color values for PDS fields and background ║
╚══════════════════════════════════════════════════════════════════════════════╝
The following is a list of the 16 colors supported by PDS and the names required
by the PDL ")COLORS" statement and the rxPD "rxPDInit" routine:
Color - Name
Black - BLACK
Dark Blue - BLUE
Dark Green - GREEN
Light Blue - LBLUE
Dark Red - RED
Purple - PURPLE
Yellow - YELLOW
White - WHITE
Grey - GRAY
High Intensity Blue - BLUEHI
High Intensity Green - GREENHI
High Intensity Blue - LBLUEHI
High Intensity Red - REDHI
High Intensity Purple - PURPLEHI
High Intensity Yellow - YELLOWHI
High Intensity White - WHITEHI
APPENDIX B - Color values for PDS fields and background Page 82
Panel Display System (PDS)
╔══════════════════════════════════════════════════════════════════════════════╗
║ Index ║
╚══════════════════════════════════════════════════════════════════════════════╝
)AID - 14 , 17 , 18 , 23 , 24 , 25 , 36
)BLANK - 3 , 18 , 23 , 24 , 25 , 26 , 28 , 39 , 43 , 47
)COLORS - 5 , 6 , 23 , 24 , 25 , 30 , 37 , 38 , 58 , 63 , 82
)END - 3 , 4 , 18 , 23 , 24 , 26 , 28 , 30 , 39 , 41 , 45 , 49 , 58 , 63 , 71
)NODISPLAY - 39 , 40 , 49 , 58 , 63 , 71
)NOWAIT - 39 , 40 , 49 , 58 , 63 , 71
)NULL - 23 , 24 , 25 , 27 , 43 , 47
)PANEL - 3 , 14 , 17 , 21 , 23 , 25 , 28 , 30 , 33 , 36 , 42 , 45 , 49 , 58 ,
63 , 71
)PROC - 17 , 18 , 23 , 24 , 25 , 28 , 30 , 39 , 63 , 71
)PROCEND - 18 , 23 , 24 , 26 , 39
)REM - 17 , 18 , 23 , 24 , 25 , 26 , 46
)ROW - 23 , 24 , 25 , 27 , 28 , 37 , 38 , 40 , 41 , 43 , 44 , 45 , 46 , 47 ,
58 , 63
)VARS - 8 , 23 , 24 , 25 , 28 , 30 , 37 , 41 , 48
)XID - 21 , 23 , 24 , 25 , 36
AID= - 14 , 33 , 34 , 36
ATTR= - 34
BCKG= - 38
CLS= - 33
COLUMN - 22 , 23 , 25 , 26 , 27 , 42 , 43 , 44 , 45
DVP - 11 , 14 , 15 , 16 , 18 , 19 , 20 , 24 , 39 , 56 , 62 , 63 , 64 , 69 ,
70 , 71
FLDS= - 3 , 4 , 18 , 25 , 26 , 28 , 30 , 39 , 40 , 41 , 44 , 45 , 46 , 58 , 63
INPUT= - 6 , 38
NAME= - 33
OUTPUT= - 6 , 38
ROW - 3 , 5 , 6 , 22 , 23 , 24 , 25 , 26 , 27 , 29 , 37 , 39 , 41 , 42 , 43 ,
44 , 45 , 46 , 47 , 48 , 49 , 50 , 57 , 58 , 59 , 60 , 61 , 63 , 71
TEXT= - 5 , 38
XID= - 21 , 34 , 36
ZALARM_ERROR - 17 , 26 , 28 , 30 , 81
ZALARM_NOERROR - 81
ZALARM_SEVERE - 18 , 81
ZALARM_WARNING - 81
ZBid - 16 , 70
ZFname - 16
ZFndx - 16
ZKey - 16 , 17 , 18 , 20 , 63 , 71
ZPid - 16 , 70
ZPname - 16
ZVERIFYPROC_RC_NORETURN - 17 , 19 , 26 , 28 , 30 , 80
ZVERIFYPROC_RC_RETURN - 17 , 19 , 20 , 26 , 28 , 30 , 80
Index Page 83
Panel Display System (PDS)
ZVTYPE_DOUBLE - 11 , 64 , 81
ZVTYPE_GLOBAL - 12 , 64 , 69 , 70 , 71 , 81
ZVTYPE_LONG - 11 , 64 , 81
ZVTYPE_LZEROFILL - 10 , 12 , 64 , 81
ZVTYPE_RIGHTADJUST - 12 , 64 , 81
ZVTYPE_STATIC - 13 , 81
ZVTYPE_ZSTRING - 10 , 64 , 80
aid - 9 , 14 , 15 , 16 , 17 , 18 , 19 , 20 , 21 , 25 , 28 , 30 , 32 , 33 , 34 ,
36 , 40 , 41 , 55 , 62 , 63 , 64 , 80
bid - 53 , 54 , 55 , 56 , 57 , 62 , 64 , 65 , 66 , 68 , 70 , 72 , 73
field - 4 , 5 , 6 , 7 , 8 , 9 , 11 , 12 , 13 , 14 , 15 , 16 , 17 , 19 , 21 ,
23 , 24 , 25 , 26 , 27 , 29 , 34 , 35 , 37 , 40 , 42 , 43 , 44 , 45 ,
46 , 47 , 48 , 50 , 53 , 55 , 57 , 62 , 63 , 66 , 67 , 68 , 69 , 70 ,
71 , 72 , 73
panel - 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 , 9 , 11 , 13 , 14 , 15 , 16 , 18 , 19 ,
20 , 21 , 22 , 23 , 24 , 25 , 26 , 27 , 28 , 29 , 31 , 32 , 33 , 34 ,
37 , 38 , 39 , 40 , 41 , 42 , 43 , 44 , 45 , 46 , 47 , 48 , 49 , 50 ,
53 , 55 , 56 , 57 , 58 , 61 , 62 , 63 , 66 , 67 , 68 , 69 , 70 , 71 ,
73 , 80
pid - 70
procedure - 9 , 11 , 14 , 15 , 17 , 18 , 23 , 24 , 25 , 26 , 39 , 56 , 62 ,
63 , 69 , 71 , 74
routine - 9 , 14 , 16 , 40 , 51 , 52 , 53 , 55 , 62 , 64 , 66 , 67 , 74 , 80
rxPDDisplay - 16 , 55 , 57 , 62
rxPDInit - 52 , 53 , 54 , 72 , 73 , 82
rxPDLoadFuncs - 51 , 52
rxPDQueryMDT - 66 , 67 , 68 , 69 , 81
rxPDRestoreScreen - 16 , 56
rxPDSaveScreen - 56
rxPDSetCursorFld - 17 , 26 , 28 , 30 , 62 , 63
rxPDSetFldColors - 71 , 72
rxPDSetMsgText - 56 , 57 , 58 , 59 , 60 , 61 , 81
rxPDSetPnlColors - 73
rxPDTerm - 54
rxPDVDefVarRetrieve - 12 , 69 , 70 , 71
rxPDVarDefine - 10 , 53 , 64 , 65 , 71
rxPDVarDelete - 65
rxPDZVarDefine - 9 , 17 , 18 , 26 , 28 , 30 , 55 , 63 , 64 , 71 , 74
svid - 17 , 18 , 56
verification - 11 , 12 , 14 , 15 , 17 , 18 , 19 , 21 , 23 , 24 , 25 , 26 , 39 ,
56 , 62 , 63 , 69 , 71 , 74 , 80
xid - 9 , 15 , 21 , 25 , 32 , 34 , 36 , 41 , 55 , 61 , 62 , 80
Index Page 84
