All related posts: Reference Page – GP/QTP Automation  

Dexterity Objects Hierarchy 

Internally, Dexterity objects have the following hierarchy:

• Application
• Forms
• Windows
• Window Fields (input boxes, check/radio buttons, buttons, etc.) 

The hierarchy is stored in the Dictionary file. 

Visually, Dexterity objects are presented as:

• Panels
• Dialogs
• GUI Controls (input boxes, check/radio buttons, buttons, etc.) 

In order to use GUI objects in test automation, logical names of Dexterity GUI controls must be mapped and stored in easily accessible format. XML would be ideal as it has natural support for hierarchical data structures. 

Building XML GUI Map (algorithm) 

Using pseudo-code, Dictionary-to-XML GUI mapping script should perform the following. 

<Start GP Application>

<Connect to Dynamics.Application object>

<Create XML file parent> 

<Loop through all Form objects>

…..<Get Form instance>

…..<Retrieve logical name>

…..<Create new XML Form node>

…..<Assign logical name as attribute> 

…..<Loop through all Window objects>

……….<Get Window instance>

……….<Retrieve logical name>

……….<Create new XML Window node>

……….<Assign logical name as attribute> 

……….<Loop through all Field objects>

……………<Get Field instance>

……………<Retrieve logical name>

……………<Retrieve numeric ID>

……………<Create new XML Field node>

……………<Assign logical name as attribute>

……………<Assign numeric ID as attribute>

……….<End Loop> 

…..<End Loop> 

<End Loop> 

<Save XML file>

<Disconnect Dynamics.Application object> 

Using XML GUI Map 

Since XML GUI map created from Dictionary contains all defined GP application objects it’s pretty big and may cause performance issues. So it should be used as a separate base storage, and custom XML GUI Map files should be created with the data extracted from the base storage. Only GUI objects used in automation should be extracted.