There are a number of reasons to organize your Screen elements inside of ScreenGroup elements, of these, the most common include:
•Avoiding duplicate Recognize element definition
•"Splitting" a single Screen element into two or more elements
•Improving runtime performance
Avoiding duplicate Recognize element definition
Whenever possible, you should avoid duplicate Recognize elements within your Screen elements. If two or more Screen elements "share" a common text area used in recognition, they should be children of a common ScreenGroup. An exception to this guideline would be a "coincidental" duplication between two totally unrelated screens where it would be unnatural for the two screens to be grouped together.
To take two "already defined" Screen elements and group them together:
| 1. | Add a new ScreenGroup element to the FlyConnector element |
| 2. | Using drag-and-drop, move the ScreenGroup element above the first of your two screens (drag it and drop it on the first Screen to move it above the Screen) |
| 3. | Now drag-and-drop each of the two Screen elements so that they are children of the ScreenGroup element (drop on top of the ScreenGroup to set them as children) |
| 4. | Selecting each of the Screen elements, delete the duplicate Recognize elements |
| 5. | Selecting the new ScreenGroup element, rename it to an appropriate name |
| 6. | If there are already applications using your definitions file, check the Virtual checkbox for the new ScreenGroup: this will keep the qualified names of the children Screen elements the same in the applications that refer to them |
| 7. | Now, add whichever Recognize elements were deleted in step 4 to the parent ScreenGroup element |
"Splitting" a single Screen element into two or more elements
In many screen integration applications, what at the beginning of development appeared to be "one" logical screen, actually displays a "split personality" during development and testing. A good example of this is a screen that has one or more portions that change field layouts depending on the backing data (for example, the bottom half may have two or more different field layouts).
When this is discovered, you should split the screen definition in order to accomodate the different field layouts:
| 1. | Add a new ScreenGroup element to the FlyConnector element |
| 2. | Using drag-and-drop, move the ScreenGroup element to the location of the Screen element being split (drag it and drop it on the Screen to move it above the Screen) |
| 3. | Now drag-and-drop the Screen element so that it is a child of the ScreenGroup element (drop on top of the ScreenGroup) |
| 4. | Selecting the Screen element, delete all Recognize elements that are in the "common" area |
| 5. | Rename the original Screen element to a logical name representing its "personality" |
| 6. | Select the ScreenGroup element- rename from "new" to, most likely the Screen element's original name |
| 7. | You should not set the Virtual checkbox checked, even if there are existing applications: the need for the new ScreenGroup is essentially a change to the original specifications, and any existing Screen references should be updated with a fully qualified name |
| 8. | To the ScreenGroup element add the common Recognize elements deleted in step 4 |
| 9. | Add a new Screen Element as a child of the new ScreenGroup element |
| 10. | Name the new Screen element with a name that properly associates it with the name set in step 5 |
| 11. | Now, for each child Screen element, add one or more Recognize elements that uniquely identify that screen within the ScreenGroup |
Improving runtime performance
As your application develops, if you have a large number of Screen elements, you can "tune" the performance of your screen recognition by placing screens with common characteristics in ScreenGroup elements.
This is not worth doing in any system with relatively small concurrent sessions (under 25 or so), nor in an application with fewer than 20 or so Screen elements.
The goal is to reduce the number of comparisons taken to identify the most common screens. The simplest action is to move the most frequently displayed host Screen elements to the top of your definition. The recognition engine in Flynet Viewer starts its scan at the top of your definition file (after it is compiled), so moving a Screen element to the top means it gets compared first; if it is a frequently displayed screen that will cut-down on recognition operations.
If your application involves many "unrecognized" screens, such as default screens in a pass-through environment, you may also want to reduce the total number of decisions always, not just when a frequent screen is found immediately. You can do this by grouping Screen elements using common text.
To group one or more Screen elements based on common text:
| 1. | Add a new ScreenGroup element to the FlyConnector element |
| 2. | Using drag-and-drop, move the ScreenGroup element above the first of your screens (drag it and drop it on the first Screen to move it above the Screen) |
| 3. | Now drag-and-drop each of the Screen elements being grouped so that they are children of the ScreenGroup element (drop on top of the ScreenGroup to set them as children) |
| 4. | Selecting the new ScreenGroup element, rename it to an appropriate name |
| 5. | Check the Virtual checkbox for the new ScreenGroup: this will keep the qualified names of the children Screen elements the same in the applications that refer to them |
| 6. | Now, add one or more Recognize elements to the new ScreenGroup that are common across all the children Screen elements |
| 7. | If any of the Recognize elements added in step 6 are duplicated in any of the children Screen elements, delete them from those elements by first selecting the element and then using the Screenview delete action |
| 8. | As an additional check of your work, you can next select the ScreenGroup element, and then, one at a time, select each screen in the Screen Reference drop-down |
| 9. | If each Screen element moved to the ScreenGroup is properly recognized, as you click on the Reference elements in step 8, all the Recognize elements in the Screenview pane should not display the red X indicating a bad compare... |
