Dot NET GUI 

• System.Windows.Forms standard GUI objects

Successfully recognized and mapped by QTP

Online reference: http://msdn.microsoft.com/en-us/library/system.windows.forms.aspx 

• System.Windows.Forms custom GUI objects

Successfully recognized by QTP but mapped as generic object class “swfObject”. Hence the limitations operating it. 

However, each object and its custom methods could be inspected manually (with Object Spy) and successfully mapped to a similar class in QTP.

List of custom objects with functionality descriptions and documented custom methods will be provided later. 

Dexterity GUI 

Microsoft Dexterity 10.0 Documentation Online reference: http://www.microsoft.com/downloads/details.aspx?FamilyID=65f324e5-2720-42b6-ba4e-5698bfc5d20f&displaylang=en 

• The main concept of Dexterity architecture is platform independency. While runtime engines (main executables) are platform-specific, the logic, data, and GUI layout of Dexterity application are platform-independent. Since the runtime engine is platform-specific, the all resources are interpreted appropriately for each platform – and recompiling of the application is not required in order to provide cross-platform functionality
• A Dexterity application is a combination of a few basic components that work together to present a functioning application: the resource containers named Dictionary and runtime Engine along with the Communication Bridge providing two-way messaging access.
• An application dictionary (a file with the extension .DIC) is the file that stores all of the resources and code for the application. All the windows, tables and reports used in Dexterity application, are added as objects, or resources, to the application dictionary. 

Dictionary files could be found in the Great Plains installation root folder. 

• The runtime engine interprets the contents of the dictionary to present a functioning application to users. The main dictionary DEX.DIC contains resources used by the runtime engine as it interprets an application dictionary 

Communication (User Interaction Events) 

The all communication between Dexterity applications and Windows event system is performed only through Dexterity Communication Bridge. Inside the application has its own custom MS Dynamics Dexterity Event System.

Concluding, since Dexterity GUI is not based on Microsoft Windows GUI objects with Windows Handle, and Dexterity Event System is not a part of Windows Event System, there is no direct communication possible between MS Dynamics Great Plains application and any Test Automation Tool.

Dexterity GUI and Event System on Microsoft Windows Platform 

Dexterity objects have the following hierarchy:

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

On Microsoft Windows platform special wrapping object is used to support appearance of Dexterity windows – WinForm. QTP captures all the keyboard interactions at level of this object only. Dexterity Button controls and ListBox controls have wrapping objects too as they receive direct mouse events (clicks), however only basic properties of them could be captured by QTP.

 Reliable and Robust Automation Approach

 MS Dynamics Dexterity architecture does not allow implementing a reliable GUI recognition and interaction if sending events from the outside.

However, MS Dynamics Great Plains application has extended integration support with its additional products, and one of them could be used in order to access Dexterity GUI from the inside – Continuum. QTP can establish a connection using COM mechanism, and Continuum will enable operating Application’s GUI and events simulating manual user activity.

Read more: Reference Page – GP/QTP Automation