Configurable Screens > Adding Fields and Frames
  
Adding Fields and Frames
In component-based screens in QAD Enterprise Edition, you can add a new field to a table and then add the new field to the current screen. See User Guide: QAD Financials for details of Design Mode for component-based screens.
In Standard Edition, the list of fields that you can add to a screen is displayed in the Available Fields area of the Configure screen. The Available Fields area has two sections:
Standard Fields
These are existing data fields for the program. The Standard fields area only displays fields that have been hidden from the screen as part of a previous customization.
User Fields
These are the default user customization fields that are defined for all tables.
Adding New Fields and Tables to Programs
When you design a program, the user fields available to add to the screen are displayed in the Available Fields area. You can add these to existing frames, or create a new frame to contain one or more of these fields.
By default, only specific tables and fields are displayed for a particular program. These tables and fields are defined in the configscreens.xml file.
The <tableaccess> section of this file lists the tables associated with some of the programs that are available for Design mode.
By default, you can only add fields that follow these naming conventions:
*__chr..
*__dte..
*__log..
*__dec..
*_user1
*_user2
These names correspond to the following field types:
character
date
logical
decimal
integer
These fields are reserved for customization and can be added as values for any table.
The <userfields> section of the file allows additional fields to appear in the User Fields section of the Configure screen.
Warning The default fields that follow the naming convention above are safe to add to screens because they are specifically reserved for customizations. However, when adding other fields to the <userfields> section of configscreens.xml, you must be very familiar with the fields and the side effects that can be caused by adding them to the screen. Some fields are heavily validated and verified by the standard code. If they are added to the screen using this mechanism, this validation and verification will be bypassed—causing data corruption.
In the example, the <tableaccess> section of the configscreens.xml file lists the tables for woworl01.p and wowor1.p.
The default value of each program displays the default table that appears first in the Available Fields area of the Design window.
 
<configscreens>
<tableaccess>
<program name="woworl01.p" default="wo_mstr">
<table name="wo_mstr"/>
<table name="pt_mstr"/>
</program>
<program name="woworl.p" default="wo_mstr">
<table name="wo_mstr"/>
<table name="pt_mstr"/>
</program>
</tableaccess>
<userfields>
<table name="pt_mstr">
<field name="pt_desc1"/>
<field name="pt_desc2"/>
</table>
</userfields>
</configscreens>
There are two copies of configscreens.xml, in the com/qad/mfgpro and com/mfgpro folders. You must modify both files to enable your additional field changes.
Adding Available Fields to Screens
To add a field to the current frame, select the field in the Available Fields area and use the arrow button to move the field to the Selected Fields area. Before moving the field, click Edit to view and modify the field properties. The Edit button is only available for user fields in the Available Fields area.
Editing Field Properties
The Edit Field screen displays read-only properties for the selected field, and lets you modify the field label and validation.
Note: The Edit Field screen is not available for Standard Fields.

Edit Field
Field Descriptions
Table
This read-only field displays the database table for which this field is defined.
Name
This read-only field displays the field name.
Data Type
This field displays the field type: character, date, logical, decimal, user 1, or user 2.
Format
This read-only field displays the field data format; for example, the maximum number of characters for a character field.
Label
This field displays the field label. You can modify the label up to a maximum of 35 characters. Note that the system will translate the value you put in the Label field if the value is a label term. Otherwise, the system will just use the value for the label.
Validations
Use this area to define how the field is to be validated.
Generalized Code Validation
Check this field to ensure that the values for this field are based on the valued specified in Generalized Code Maintenance (36.2.13). You can use Generalized Codes Validation Rpt (36.2.15) to view a list of database fields that have schema validation assigned.
Note: When adding values in Generalized Codes Maintenance, you must specify the full table and field name. For example, if specifying values for the field pt_chr01, you enter the table and field name pt_mstr.pt_chr01.
Program
Use this field to enter the name of a user-defined Progress program that validates the field.
You can use the program template gpvalidate.p to create your own Progress programs. This template is stored in the QADInstallDir/qadui/com/qad/shell/interface directory and contains instructions for usage. Copy the template and rename it appropriately.
Adding New Frames to Screens
Click the Add Frame button to add a new frame to the program.

Add Frame
The button is only available when there are available fields to add. A default message (8622, ‘See User Guide for adding User Fields’) is displayed when no fields are available.
The new frame is displayed behind the Configure screen. To add fields to the screen, use the arrow key to move fields from the Available Fields area to the Selected Fields area. Use the cursor to position fields in the frame, and click the Tab Order button to set the tabbing order for the frame.
Click Save to save this frame and insert it into the program sequence, or Remove Frame to remove the frame from the sequence. When you remove a frame, the fields are selectable again in the Available Fields area.
When you create a new frame, save your updates, and exit Configure Screens, the frame is displayed immediately following the current frame when you next launch the program.
Note: A technical limitation with underlying Progress program transactions can prevent data from being saved in frames that are added using Configurable Screens design tool. In particular, adding a configured frame after the last frame of a program can be a problem. The design tool cannot determine which programs are affected by this and thus cannot prevent a frame from being added in the trouble spots. Instead of placing a configured frame after the last frame in a program, consider the following alternative approaches:
Move the configured frame to be located earlier in the program. For example, if configuring Item Planning Maintenance, put the configured frame before the Item Planning Data frame. This will properly save the data in the configured frame.
Add fields to existing frames that will put them in the proper transaction scope. If there is not a lot of available space in an existing frame it is still possible, in some cases, to place fields in that frame in spaces that appear too small to fit and which cause overlap with other fields. At run-time, the frame will be expanded to accommodate this and the fields will appear spaced properly.
Using the design tool, drag around the existing fields on a frame to make space available for adding additional fields.
Customize the underlying Character UI code to add the additional frame within the transaction scope (this would not involve using the Configurable Screens design tool).
QAD Services has a customization tool kit (ICT), which provides a nonintrusive customization mechanism that can handle some customizations that Configurable Screens cannot handle. (Implementing this requires more effort than the previous options.)
Note: There is a technical limitation with Configurable Screens regarding existing transactions of the underlying Progress program. This limitation can prevent data from being saved in frames that are added using the Configurable Screens design tool. Adding a configured frame after the last frame of a program can sometimes be a challenge. The design tool cannot determine at design time which programs are affected by this and thus cannot prevent a frame from being added in the trouble spots. Nevertheless, there are some alternatives:
The configured frame can be moved earlier in the program. For example, in the case of Item Planning Maintenance, the configured frame can be added before the Item Planning Data frame. This will properly save the data in the configured frame.
Fields can be added to existing frames that put them in the proper transaction scope. If there is not a lot of available space in an existing frame it is still possible, in some cases, to place fields in that frame in spaces that appear too small to fit and that cause overlap with other fields. At run-time the frame will be expanded to accommodate this and the fields will appear spaced properly. The workability of this varies depending on the frame but it can be a very workable option.
The existing standard fields on a frame can be dragged around, using the design tool, to free up space to add additional fields.
The underlying CHUI code itself can be customized to add the additional frame within the transaction scope. (This would not utilize the Configurable Screens mechanism.)
QAD Services has a customization tool kit (ICT), which provides a nonintrusive customization mechanism that can handle some customizations that Configurable Screens cannot. Note that implementing this is a larger scope than the above options.
Adding Lookups to a User-Defined Field
Note: To add a lookup to a user-defined field, you must use the full field name when you set up the lookup in Drill Down/Lookup Maintenance. The full field name includes the table name and the field name in the format table_name.field_name. View the screen and enter Ctrl+F on the added field. You will see the full field name (for example, ad_mstr.ad__chr02, where ad_mstr is the table name and ad_chr02 is the field name).
You can remove fields you have added by clicking Delete. (You can only remove the fields you have added.)
Warning When you create your own field and frame, you add the field to the schema, and as the program is used, users add values to it. When you delete, you delete the field and all its stored values from the database. Use the Disable or remove options to remove a field from the screen without deleting it from the database.
Using New Fields in Character Code
The Configurable Screens functionality for Enterprise Edition allows New Fields that are not part of the existing schema to be added to screens via the Configure dialog-box. These New Fields are not physically part of the master tables but are stored in a side table and thus require a different way to access their values from the CHUI code.
For this purpose, the include file gpgenfld.i gives access to the values of these new fields through function calls.
Note: This function is only used when modifying character code.
To access to the function calls, include the following file at the top of the program that will use them:
{com/qad/mfgpro/gpgenfld.i}
The get function calls provided by gpgenfld.i are as follows:
GetFieldValueChar returns character (pTable as character, pField as character, pRecordID as decimal, pRefresh as logical).
GetFieldValueDec returns decimal (pTable as character, pField as character, pRecordID as decimal, pRefresh as logical).
GetFieldValueInt returns integer (pTable as character, pField as character, pRecordID as decimal, pRefresh as logical).
GetFieldValueDate returns date (pTable as character, pField as character, pRecordID as decimal, pRefresh as logical).
GetFieldValueLog returns logical (pTable as character, pField as character, pRecordID as decimal, pRefresh as logical).
Where:
pTable is name of the table.
pField is name of the new field that is being accessed.
pRecordId is the OID value of the specific record of table pTable.
pRefresh specifies whether the function should read the record fresh or use a cached value. The first call for a particular OID value will always read the record. From then on, the cached record will be used for additional function calls, unless the call specifies yes for this parameter. Then the record will be reread.
For example: GetFieldValueDec("so_mstr", "so_field1", oid_so_mstr, yes).
The set function calls provided by gpgenfld.i are as follows:
SetFieldValueChar returns logical (pTable as character, pField as character, pRecordID as decimal, pValue as function-dependent datatype).
SetFieldValueDec returns logical (pTable as character, pField as character, pRecordID as decimal, pValue as function-dependent datatype).
SetFieldValueInt returns logical (pTable as character, pField as character, pRecordID as decimal, pValue as function-dependent datatype).
SetFieldValueDate returns logical (pTable as character, pField as character, pRecordID as decimal, pValue as function-dependent datatype).
SetFieldValueLog returns logical (pTable as character, pField as character, pRecordID as decimal, pValue as function-dependent datatype).
Each function returns a logical that indicates if the operation was successful and accepts the parameters as follows:
pTable is the name of the table.
pField is the name of the new field that is being accessed.
pRecordId is the OID value of the specific record of table pTable.
pValue is the value to assign (the datatype varies depending on which function is called).
Example: SetFieldValueDec("so_mstr", "so_field1", oid_so_mstr, 5.6).