This document covers the following topics:
Creating Screens from the Session View using Screen Creation Definitions
Automatically Identify Screens, using the Trace Files (GCT) Wizard
See also Screens and Screen Groups in the Natural Screen Tester Reference Guide.
A single Natural Screen Tester screen represents a corresponding screen in the host. A Natural Screen Tester screen is usually
defined using unique text identifiers from the host screen, but it is also possible to use other identifiers such as the position
of the cursor when the screen is loaded or field attributes (Protected, Intensified or Hidden).
When navigating in the host application, Natural Screen Tester tries
to find the screen entity that matches the host screen it encounters. Once a
match is found, Natural Screen Tester can use the data and definitions of the host screen in
its various components. Sometimes the screen image needs to be updated, click
on the Capture image icon 
to
update the image. The following guidelines will help you determine which
screens to identify:
screens that will be part of navigation paths (recommended for easier path definition)
screens that will contain field mappings
any important screen in the host application
To allow the Natural Screen Tester Server to recognize the corresponding host screen; each screen must be identified by giving it a unique name, and defining the screen's identifiers. In addition, when relevant, you may want to map fields to the screen, associate screen groups to the screen and define steps in the application map.
Natural Screen Tester screens can be created
manually, via the Session View
by importing application host maps such as Natural, BMS and MFS
automatically or semi-automatically, using identification definitions
Screens can be created via the menu or from within the session view.
Note:
The screen must be displayed in the session view when creating the
new screen.
To create a screen via a session
In the Emulation session, navigate to the relevant screen.
Select text in the emulation screen.
Click on the Identify Screen button
. The New Screen wizard is
displayed, with a suggested name displayed in the Name field. Enter a suitable
description and determine the folder where the screen is to be located. Click
. You have now created a new screen entity in the
repository.
For the Natural Screen Tester Server to recognize a host screen, you need to identify the screen in Natural Screen Tester. The screen is identified using "identifiers". Different identifier types include identifying specific text on the screen, the screen cursor position or the field attributes. The Natural Screen Tester Server analyzes the current screen and tries to match it to all of the screen identification strings stored in the application repository (database). For a screen to be recognized, all its identifiers must be matched. You may define an unlimited number of identifiers. The following identifiers are available:
Use text identifiers to identify a screen by selecting specific text that appears on the screen. Use the Capture from Screen feature to identify a string of text accurately from the host screen and insert this string into the text box.
To define a text identifier
Access the relevant screen.
Select the Identifiers Tab.
Determine whether to ignore the application's window definitions during the identification of a screen, select the relevant check box. Once the screen is identified the full screen is used. This check box is only enabled when the screen has a window.
Note:
When changing the state of the Ignore entire screen
(ignore window definition) check box, you must manually edit the
identifiers and mappings to support the new positions.
Click the arrow on Add Identifier and select . Another row will be added to the list of identifiers.
Select Is (default) in order to match the exact text on the host screen. Alternatively, select Is NOT if any text other than the specified is suitable as a screen identifier. Check Empty to identify an empty space on the host screen. This clears the Text text box.
Select Rectangle to indicate that the identifier should be searched for within the defined rectangle, Position, to indicate that the identifier must start at a specific position or Anywhere on screen to indicate that the identifier may be anywhere on the screen.
If you select Rectangle, define the rectangle range (start and end row and column). If you select Position, select the row and column.
It is also possible to add an identifier by selecting the area in the host screen, and then clicking Add Identifier. If you select an area that is a rectangle, identifiers will be added for each and every row of the selected rectangle.
Use the Cursor Position identifier to identify a screen by the cursor position when the screen is loaded.
To define a cursor position identifier
Access the relevant screen.
Select the Identifiers Tab.
To ignore the application's window definitions during the identification of a screen, select the relevant check box. Once the screen is identified the full screen is used.
Click the arrow on Add Identifier and select . Another row will be added to the list of identifiers.
Select Is to indicate that the cursor is positioned within the region area details that follow. Alternatively, select Is NOT to indicate that the cursor is not positioned within the region area details that follow.
Select Rectangle to indicate that the cursor position should be searched for within the defined rectangle or Position, to indicate that the cursor position must start at a specific position
It is also possible to add an identifier by selecting the area in the host screen, and then clicking Add Identifier.
Attribute Identifiers:Use the Attributes identifier to identify a screen by the host's attributes. Attributes of the host screen may be Protected, Intensified or Hidden.
To define an attribute identifier
Access the relevant screen.
Select the Identifiers Tab.
To ignore the application's window definitions during the identification of a screen, select the relevant check box. Once the screen is identified the full screen is used.
Note:
When changing the state of the Ignore entire screen
(ignore window definition) check box, you must manually edit the
identifiers and mappings to support the new positions.
Click the arrow on Add Identifier and select . Another row will be added to the list of identifiers.
Select whether the Attribute Type is/is not Protected, Hidden, Intensified or Reversed video.
Enter values or use the Capture from Screen feature to indicate a specific location of the attribute by its Row and Column.
It is also possible to add an identifier by selecting the area in the host screen, and then clicking Add Identifier.
Use the Window identifier to identify a screen by determining whether it is or is not a window. In Natural UNIX, it is possible to identify a screen by determining whether it is a window and whether it has specific text in the title.
To define a window identifier
Access the relevant screen.
Select the Identifiers Tab.
To ignore the application's window definitions during the identification of a screen, select the relevant check box. Once the screen is identified the full screen is used.
Click the arrow on Add Identifier and select . Another row will be added to the list of identifiers.
Select Is to indicate that the screen is a window. Alternatively, selectIs NOT to indicate that the screen is not a window.
For Natural UNIX hosts: Select the check box to indicate to identify by the window title. You can enter text for the title or select the text in the session view and click the Capture from screen icon. You can also identify a screen which is a window and does not have a title by selecting the radio button.
When a screen is identified, field entities can be mapped to it. A field makes relating to a string on the host screen much simpler. Fields offer an enhanced way of referring to host fields - by their name rather than by their position. In addition, mapped test project fields simplify future maintenance of the test project - when a field changes in the original host application, updates only need to be made to the application field definition. The following guidelines will help you determine which fields to identify:
Fields that will be part of navigation paths.
Fields that will be used as test case input and output attributes.
Recommended: all input and output fields (not constants).
Any important field in the host application.
There are limitations when defining a mapping. A mapping cannot:
Start in an unprotected field and end in a protected field, or vice versa.
Start with an attribute byte.
Overlap another mapping on the same screen.
Start in one line and end on another line.
Start on one line and end off the screen's limits.
An identified field makes relating to a string on the host screen much simpler. Fields offer an enhanced way of referencing host fields - by their name rather than by their position. Using fields has many advantages:
A field's ID is meaningful regarding the contents of the field, unlike a numeric position.
You define a field only once, and later can reference that definition in all of your code - knowing you always mean the same definition.
If changes in the host application occur in the future, the only place that requires to be changed is the field definition.
Field properties can be accessed by right-clicking on the Repository node and selecting and then searching for the specific field.
In the Field Editor, it is possible to set the Input Mask (Defines the values that can be entered in the field) and the field type (numeric or alphanumeric).
When a screen is identified, field entities can be mapped to it. A field makes relating to a string on the host screen much simpler. Fields offer an enhanced way of referring to host fields - by their name rather than by their position. In addition, mapped test project fields simplify future maintenance of the test project - when a field changes in the original host application, updates only need to be made to the application field definition.
Fields can be mapped according to their position in the screen or according to their leading label - dynamic field mapping (do not set the same field to be mapped by position and by its leading label).
Mapping according to leading labels (dynamic mapping) is particularly useful in the following cases:
The application has fields that are dynamically drawn on the screen.
Host applications are sometimes changed and items can be moved. Using dynamic field mappings, the fields will continue to be mapped and identified and the application will not be affected.
Using dynamic field mappings enables more flexibility when using Screen Groups, as Screens which include the same field, can be associated with the same Screen Group even when the field is located in a different position.
To map fields according to their position in the screen
Click the Fields tab to view and/or modify the fields in this screen.
Click the arrow next to , and select or to add a new field mapping.
In the Field name field, either enter a field name or enter the first letters of a field name and then click CTRL and SPACE to display relevant fields.
Select the Protection type: Protected (cannot be edited in host), Unprotected (editable in host) or Both (may sometimes be editable and sometimes not).
The Do not save field content when recording check box enables not saving data which you do not want to be displayed when viewing the recorded trace file.
The Row and Column fields indicate the position of the field on the screen. The values of these fields can be changed using the Capture from Screen feature or by entering values in the fields.
When adding a multiple field mapping, determine the number of occurrences and the rows and/or columns between occurrences.
Note:
You can automatically map all of the unprotected fields in the
screen by clicking on the Automatically identify unprotected
fields icon.
To map fields according to their leading label (not
available in right to left and character mode applications)
In some screens, the position of a field may vary. It is therefore necessary to map some fields in such a way, that even if they appear in a different position, they will still be recognized and mapped. This is possible by defining the label near the field (the label must be to the left of the field) and identifying the field according to this label. This mapping type is called "Single Dynamic" as the mapping position changes dynamically according to the leading label. Refer to Dynamic Field Mapping Limitations.
Click the Fields tab to view and/or modify the fields in this screen.
Click the arrow next to Add Field Mapping, and select to add a new field mapping.
In the Field name field, either enter a field name or enter the first letters of a field name and then click CTRL and SPACE to display relevant fields.
Select the field protection type: Unprotected, Protected or Both. Prefer to set the field type either as Protected or Unprotected when you are sure of the type of the dynamic field. Use Both when you are not sure of the type of the dynamic field.
Determine the leading label: the leading label is the label which appears before the field. This label is inserted as the Field name and can be edited. The label you define should be as accurate as possible (do not use strings which normally appear within the field).
Determine the method to use to search for the label:
Contains text: Searches for the given text anyway in the defined region (default).
Exact phrase: Searches for the given text within the defined region. The text must be preceded and followed by at least two white space characters.
Contains word: Searches for the given text as word(s) within the defined region.
Regular expression: Searches for the given pattern within the defined region. Refer to Regular Expression Syntax in the Natural Screen Tester Reference Guide.
Note:
If you select a different option, after defining a regular
expression search definition, the value of the previous regular expression
definition will be lost.
Define the region type in which the label will be searched for: anywhere in the screen, within a specified rectangle or within a specified row range. The Row and Column fields indicate the position of the label on the screen. The values of these fields can be changed using the Capture from Screen feature or by entering values in the fields.
Use length:
In Unprotected fields: Determine whether to recognize a field mapping according to the leading label and the length of the input field (Fixed length) or just according to the leading label (Dynamic length).
In Protected fields: The length defined here is the length of the mapping. The identified field is cropped to the specified length.
Define the region type in which the field will be searched for: anywhere in the screen, within a specified rectangle or within a specified row range. The Row and Column fields indicate the position of the field on the screen. The values of these fields can be changed using the Capture from Screen feature or by entering values in the fields.
Note:
The region will be displayed in the Session View with a yellow
frame, and the background of the screen within this region will be
dotted.
It is preferable to define your regions as rectangles, that do not overlap each other, and whose size are minimal.
The feature is best suited to locate dynamic fields which change their location vertically so that labels are aligned vertically in one region, and fields aligned vertically on a region to the right of the labels.
Mappings inherited from screen groups are indicated with an icon.
You can override this mapping to suit the current screen by clicking on the
Override hyperlink. Hereafter, this mapping will be marked
with the 
icon. You can
restore the inherited mapping by clicking on the Restore Inherited
Mapping hyperlink. Note that when selecting an inherited mapping, you cannot change the mapping properties. When selecting a local
mapping, all properties can be changed. If you select an overridden mapping,
all properties can be changed, except for the name.
To delete a field mapping, click on the Delete Field Mapping hyperlink.
It is not possible to remove mappings which are used in other entities, such as in procedures or tables.
You can sort the contents of a List of Field Mappings table by field name or by any other column. Click the header of the column by which you want to sort. The contents are sorted in ascending order. Click again to sort in descending order. This feature is useful when detecting duplicate field entries. The sort will be cancelled when you close the screen entity.
Screen Creation Definitions are a set of basic definitions which are used to create a new Natural Screen Tester screen. These definitions include the default screen name, initial identifiers and determine whether input fields will be created. Creating a new screen using screen creation definitions reduces the complexity and the time required to identify new screens.
To use this feature, at least one set of Screen Creation Definitions must be created within a Screen Group (in the dedicated tab). When navigating within a session, and reaching an unidentified screen, Natural Screen Tester searches for Screen Groups which match the unidentified screen, and then creates a new screen based on the screen group's identifiers and on parameters defined in the creation definition configured in the Screen Group. This process can be initiated in three different modes:
Automatically: A screen will automatically be created for each unknown screen that matches a screen group. This screen will include basic screen definitions, which are defined in the screen group.
Semi-automatically: The New Screen Wizard will automatically be displayed for each unknown screen that suits a screen group. This screen will include basic screen definitions, which are defined in the screen group.
Manually: The New Screen Wizard is displayed when clicking on the Identify New Screen icon.
The mode is set in the session view by clicking on the Change screen creation mode icon in the tool bar. Refer to Changing the Screen Definition Mode.
This section covers the following topics:
The difference between creating a screen in the manual mode and creating a screen in the semi-automatic mode, is that in the manual mode, when you reach an unidentified screen, you are required to click on the Identify New Screen icon in the Session view. You can then select from a list of Screen Groups relevant to this scReen, the screen group which has screen creation definitions which you would like to use (you can select to create a new screen without using screen creation definitions by clicking on in the Use a Screen Creation Definition dialog box). By default the list of screen groups which are relevant to this screen are displayed. It is also possible to show and select a screen group from all the application screen groups that have screen creation definitions. If you want Natural Screen Tester to always use the Screen Group with the highest priority, select the Don't ask again check box. It is possible to display this dialog box again by changing the Always use the highest prioritized screen group check box in .
The new screen has a number of basic definitions such as the screen name and a number of identifiers. These are determined according to the definitions in the Screen Creation Definition tab in the relevant Screen Group entity (You can select to create a new screen without using screen creation definitions by clicking on in the Use a Screen Creation Definition dialog box). The screen name is determined according to the screen name position definition in the Screen Creation Definition tab. The list of identifiers is determined according to the Screen Group identifiers, as well as the strings which appear in the list of identifier locations in the Screen Creation Definition tab. To automatically create input fields in the new screen, select Automatically create input fields. The labels near the input fields are used as the input field names.
To manually create screens using screen creation definitions
Within the relevant Screen Group, create a Screen Creation Definition.
Ensure that in the session view the selected mode is Manual Screen Creation: in the Session view click on the Screen Creation Definition mode icon and select Manual Screen Creation.
Navigate within a session.
Once a screen group is recognized within an UNKNOWN screen, click on the Identify New Screen icon. The Use a Screen Creation Definition dialog box is displayed. Here you can determine whether to base the new screen on a Screen Creation Definition or not. Click to create a new screen without using Screen Creation Definitions.
This dialog box displays, by default, the screen groups which have screen creation definitions and are relevant to the UNKNOWN screen. You can display all the screen groups which have screen creation definitions and select a different screen group. Click
The New Screen wizard is displayed. The default name is taken from the text which appears in the screen name position definition in the Screen Creation Definition tab. Click
The new screen is displayed in the Editor and is listed in the repository.
Refer to Automatically Creating Screens and Semi-Automatic Creation of Screens.
Similar to the automatic mode, when navigating in a session and a screen group is recognized, and the current screen has not yet been identified, the process of creating a new screen entity is initiated. The new screen has a number of basic definitions such as the screen name and a number of identifiers. These are determined according to the definitions in the Screen Creation Definition tab in the relevant Screen Group entity (You can select to create a new screen without using screen creation definitions by clicking on in the Use a Screen Creation Definition dialog box). The screen name is determined according to the screen name position definition in the Screen Creation Definition tab. The list of identifiers is determined according to the Screen Group identifiers, as well as the strings which appear in the list of identifier locations in the Screen Creation Definition tab. To automatically create input fields in the new screen, select Automatically create input fields. The labels near the input fields are used as the input field names. As there may be more than one Screen Group which has Screen Creation Definitions, it is necessary to determine which screen group is to be used. This is done in the Use a Screen Creation Definition dialog box which is displayed once the unknown screen is reached. By default the list of screen groups which are relevant to this screen are displayed. It is also possible to show and select a screen group from all the application screen groups that have screen creation definitions. If you want Natural Screen Tester to always use the Screen Group with the highest priority, select the Don't ask again check box. It is possible to display this dialog box again by changing the Always use the highest prioritized screen group check box in .
To semi-automatically create screens using screen creation
definitions
Within the relevant Screen Group, create a Screen Creation Definition.
Ensure that in the session view the selected mode is : in the Session view click on the mode icon and select .
Navigate within a session.
Once a screen group is recognized within an unidentified screen, the Use a Screen Creation Definition dialog box is displayed. Here you can determine whether to base the new screen on a Screen Creation Definition or not. Click to create a new screen without using Screen Creation Definitions.
This dialog box displays, by default, the screen groups which have screen creation definitions and are relevant to the UNKNOWN screen. You can display all the screen groups which have screen creation definitions and select a different screen group. Click .
The New Screen wizard is displayed. The default name is taken from the text which appears in the screen name position definition in the Screen Creation Definition tab. Click
The new screen is displayed in the Editor and is listed in the repository.
Refer to Automatically Creating Screens and Manually Creating Screens.
When navigating to an unidentified (UNKNOWN) screen in a session and a screen group is recognized, a new screen entity is created. The new screen has a number of basic definitions such as the screen name and a number of identifiers. These are determined according to the definitions in the Screen Creation Definition tab in the relevant Screen Group entity. The screen name is determined according to the screen name position definition in the Screen Creation Definition tab. The list of identifiers is determined according to the Screen Group identifiers, as well as the strings which appear in the list of identifier locations in the Screen Creation Definition tab. When more than one screen group is relevant to the screen, the screen creation definition is based on the definition in the screen group with the highest priority. To automatically create input fields in the new screen, select Automatically create input fields. The labels near the input fields are used as the input field names.
To automatically create screens using screen creation
definitions
Within the relevant Screen Group, create a Screen Creation Definition.
Ensure that in the session view the selected mode is Automatic Screen Creation: in the Session view click on the icon and select .
Navigate within a session. New screens are automatically added to the repository.
Refer to Semi-Automatic Creation of Screens and Manually Creating Screens.
Using trace (GCT) files, you can automatically identify screens. In order to do this, you must ensure that a Screen Group includes a Screen Creation Definition.
To automatically identify screens using trace files
Right-click on the relevant application, and select. The wizard is displayed.
Select whether to analyze files or a folder. Locate the files/folder.
Select the Automatically identify screens check box.
You can automatically identify steps by selecting the Capture screen navigation map steps check box. Refer to Automatically Identify Steps using Trace Files (GCT) for further details.
Click .
The Console displays the outcome of the process.
Note:
When identifying a new screen, the screen name is taken from the
area you defined in the Screen Creation Definitions. If a screen with this name
already exits, the newly identified screen's name will be the name as of the
existing screen followed by an incremental number. If the area you defined in
the Screen Creation Definitions is empty, the screen will be named: "Screen"
and then an incremental number.
Standard maps, such as Natural, BMS and MFS, are used in host applications to describe the structure of the host screen including the static text and input and output fields. Natural Screen Tester enables importing these application maps, saving time and effort spent on manually identifying screens and simplifying the maintenance process when changes are made in the host application. When importing application maps, a screen is automatically created from each map, minimizing errors that may occur when creating the screens manually, one by one. The Natural Screen Tester screen created includes identifiers (based on the static text in the map) and fields (based on the input and output fields in the map). Natural Screen Tester supports a number of different types of maps:
NATURAL: Natural map support (from SYSTRANS/SYSOBJH or NaturalONE files).
BMS: CICS basic map support.
MFS: IMS message format service.
SDFX: Natural Screen Tester generic map format, used for other standard maps. To create SDFX files refer to SDFX File Format Definition in the Natural Screen Tester Reference Guide.
SDF: Compatible with Software AG's JIS product.
The import map feature can be used to import an application's maps for a new application or to maintain and update previously imported maps. When updating previously imported maps, screen identifiers will be deleted and replaced, existing fields will be updated with their new positions and their references to other entities will be preserved. Fields that were previously imported, but no longer exist on the host will be deleted.
Note:
Invalid entity names, such as names which include invalid characters
such as "#" or begin with a digit, will be automatically corrected by omitting
the invalid characters.
Note:
The colors displayed in the screen image may sometimes be different
than the colors that are displayed in the original host screen.
Maps can be imported either using the Import Host Screen Maps wizard or using a batch file (screen_import.bat in Windows and screen_import.sh in UNIX).
To import maps using the Import Host Screen Maps wizard
Ensure that the relevant Natural Screen Tester application and that the relevant map files are available.
From the menu, select or right-click on the repository node in the relevant application and then select .
The Import Host Screen Maps wizard is displayed.
Select the type of map that is to be imported. Click
The Import Parameters screen is displayed.
Select the source map file/s that you wish to import.
Select the Natural Screen Tester repository folder where the newly created screens are to be placed.
Select the map file encoding. By default, the server operating system default encoding is used.
Note:
When importing maps from NaturalONE it is recommended to use
UTF-8 encoding.
Determine whether you wish to simulate the import process, and create a report which details the import process or whether to actually import the maps and create the screens as well as the report.
If you selected to import a Natural map, you can click to configure the Natural Import Parameters, otherwise click to complete the wizard.
Natural Import Parameters screen:
- Message line row
Indicates where the error line is located - in the first line, one, two, three or four lines from the bottom or in the last line.
- Create message line field
Selecting this will map a field in every screen, where a message can be displayed. When selecting this option, you are required to enter a name for the field.
- Skip maps called with
WRITEcommandSelect this in order not to generate maps that are called with the Natural
WRITEcommand.
Click .
The screens created appear in the directory you determined in the Target folder field. The names of the screens are identical to the map names.
The report is displayed in the Eclipse console and includes a list of the screens added as well as the fields and identifiers created/updated/deleted.
To import screens via a batch file (using the command prompt
window)
Open a command prompt window.
Change the current directory to the Natural Screen Tester home directory.
Type screen_import.bat/sh followed by your required parameters. (The minus sign and letter should precede the value to distinguish between the parameters. The order of the parameters is not significant.)
| Parameter | Description | Default |
|---|---|---|
| -a | Natural Screen Tester application name (Required parameter) | |
| -af | Natural Screen Tester target folder within the application repository. | Root folder |
| -mf | Message line field name (Natural maps only) | MessageLine |
| -k | Don't skip map with write command. (Natural maps only) | true (skip) |
| -e | Map file encoding: Includes all encodings which
are supported by Java.
Note: |
Server operating system default encoding |
| -f | File name, or directory name (when importing more than one file). Required parameter. | |
| -t | Map type. Possible values: "sdf", "sdfx", "natural", "bms", "mfs" (required parameter). | natural |
| -s | Server address | 127.0.0.1 |
| -m | Indicates where the error line is located: "first", "last", "lastm1" (last minus 1), "lastm2", "lastm3", "lastm4" (Natural maps only) | last |
| -p | Server port | 3323 |
| -u | Natural Screen Tester user name (Required parameter) | |
| -x | The file extension. All files from the given directory that have this extension will be loaded (when not specified, the default extension for the map type is used: ".sdf", ".sdfx", ".ncd" or ".nsm"(for Natural), ".bms", and ".mfs"). When a file name is provided (and not a directory), the specific file will be imported (this parameter is not required in this case). | |
| -w | Natural Screen Tester user password | Empty by default |
The screens created appear in the directory you determined in the Target folder field. The names of the screens are identical to the map names.
The report is displayed in the command window and includes a list of the screens added as well as the fields and identifiers created/updated/deleted.
Refer to the Test Project Map Map for details. In this tab it is possible to manually define additional steps between screens that already exist in the test project map. The steps should be defined in the source screen and determine the destination screen of the step. It is possible to add a simple step between screens or to add an inner path step which executes a path. When you add a simple step, determine the target screen, the key to be sent, and the relevant inputs. When defining an inner path, select the path. Change the status of the step using the links (Approve, Set to Pending, Set to Not Approved). Once you save the new steps, you can check these navigation definitions in the Session View using the Test Project Map toolbar. Simply select the screen you want to navigate to and click on the icon to attempt to navigate to that screen.
A screen based table represents a logical table based on data gathered from a single Natural Screen Tester screen. When creating a table you can configure:
The header: A rectangle that contains all the column headers, and will later be used in the framework to hide this area.
Filters: empty row, and duplicate row filters will filter the table according to the value defined in the Primary Key column.
Table Columns: Includes the table definitions such as column details, occurrences, primary keys etc.
Once defined, you may view and design a table in a Natural Screen Tester Web application, or access it through a designated API in the Natural Screen Tester Base Object or from the Test Case Procedure Screen Mapper.
To create a table
Access the relevant screen and click on the Tables tab.
Click on the Create a New Table link.
A default name (new_table), which you can edit will appear in the Table name field.
The header definition is filled with values.
All the multiple fields which are in the screen are added to the list of columns.
Ensure that you check and refine the table definitions as required:
Header: To change the default header definitions, select the header area in the preview of the host screen and then click on the icon that is displayed next to the header row and column fields.
Filter rows: There are two types of filters which can be defined: filtering of empty rows (rows in which the values of the primary key columns are empty) and filtering of duplicated rows (rows in which the values of the primary key columns are identical to those of a previous row). By default these checkboxes are not selected.
Remove, add or edit table columns:
In the Name field enter a logical name to use when programming using the API or the framework, in the Caption field enter the name of the column as it will appear in the Web application, and in the Mapped to field select the host field to which the column will point.
Use the Move Up and Move Down options to define the order of the columns.
Define the table's primary key. A primary key is a key in the table that uniquely identifies each record. A table must always have one and only one primary key. The primary key can consist of one column or a combination of several columns, whose values give a unique key of each record. If no column is defined as the primary key of the table while creating the table, Natural Screen Tester automatically creates a numeric primary key for each record.
To define a primary key, select the relevant column and click on the Define Primary Key link.
A screen that belongs to a group inherits all the field mappings that are mapped to the group.
To associate screen groups to a screen
Access the relevant screen and click on the Assigned Screen Groups tab. The list of Screen Groups currently associated with this screen are listed.
Click on Assign Screen Group to select additional screen groups to be associated with this screen.
This tab is only displayed in right-to-left applications and enables overriding application settings per a specific screen.