When the OpenEdge GUI client renders widgets on a window, it calls a Microsoft Windows API during the widget creation. The Windows function allows the caller to pass a child-window identifier which Windows uses to identify that given widget. By default, the OpenEdge GUI client generates a new identifier for each widget each time the window runs. While this process is efficient, it prevents the use of third-party automated testing tools that rely on your widgets having the same unique identifier across sessions.
OpenEdge R10.1A introduced the WIDGET-ID attribute to enable you to assign a fixed identifier to the widgets on your interface. This attribute can provide third-party tools with the unique identifiers they require for automated testing. That release also included the Widget ID Assignment Utility PRO*Tool to enable you to assign widget IDs to simple GUI containers without opening them. However, that tool writes the widget ID directly into the static code for each widget which prevents it from assigning widget IDs to certain widgets.
Note: To make use of the WIDGET-ID attribute, you must start your session with the Use Widget ID (-usewidgetid) startup parameter. Using widget IDs causes extra processing to render your widgets. Since widget IDs are only intended for use with automated testing tools, you can avoid any performance impact by not specifying this parameter for your deployed applications.
OpenEdge R10.1C extends the support for widget IDs. New AppBuilder preferences enable automatic assignment of the WIDGET-ID attribute for certain widgets. This release also introduces the Runtime WIDGET-ID Assignment Tool PRO*Tool to enable you to easily assign widget IDs in ADM2 and Progress Dynamics applications. You can now assign widget IDs to the following:
Widgets in dynamic objects, for example, a dynamic SmartDataViewer
Dynamically-rendered widgets in SmartObjects, for example, a SmartSelect
Multiple instances of a SmartObject in the same run-time container
Note: Some widgets are composed of elements that the third-party testing tools consider separate widgets. The widget IDs for these elements are always assigned by the AVM when the widget is rendered. For example, the AVM assigns widget IDs to the columns of a browse by incrementing the browse's widget ID by a constant for each column.
The Runtime WIDGET-ID Assignment Tool creates an XML file to store the widget IDs that it assigns. When the AVM renders the widgets at run time, it uses the numbers from this file to assign values to the widget's WIDGET-ID attributes. The XML file creates a context in which a dynamically-generated widget can have the same widget ID over several sessions.
As long as you do not change the number of widgets on a container, you can edit the container and get a repeatable set of unique widget IDs. However, if you add or remove a widget on a container, you must generate a new XML file. A given widget's widget ID might not match between the old and new files. Regenerating the file creates a new context, and you need to record your tests again in the third party tool to make use of these new widget IDs.
If you start a session without the Use Widget ID (-usewidgetid) startup parameter, the ADM rendering engine ignores the WIDGET-ID attribute and assigns identifiers through its default process. If you do specify the startup parameter, the ADM uses the following precedence to assign widget IDs:
1. The ADM reads the widgetIDFileName property for the container. If the ADM finds a filename, it uses the values in the XML file to assign the WIDGET-ID attribute for the listed widgets.
2. For the remaining widgets, the ADM determines if a WIDGET-ID attribute was specified in a static file. If the ADM finds a hard-coded value, it assigns that value to the widget.
3. For any remaining widgets, it assigns the next unused value, working from the top-end of the range backwards. The WIDGET-ID attribute accepts even INTEGER values of 2 through 65534.
Note: Widget IDs must be unique across a window. When a conflict occurs, a warning dialog appears and the ADM assigns the next available value as described in Step 3 above.
As this process shows, the actual value of a widget ID might be assigned by one of several methods. In general, the user does not need to know the actual value of a widget ID. The third-party tools access these numbers through the Windows API, rather than directly from OpenEdge. A user never needs to prepare a complete list of all the widget IDs in an application. The only time a user cares about the value is if a conflict arises because a newly assigned widget ID is not unique. The user can then alter the value of that widget to create a unique widget ID.
Widgets in dynamic objects, for example, a dynamic SmartDataViewer
