GetTextLocation example using QTP

Extern.Declare micHwnd, "FindWindow", "user32.dll", "FindWindowA", micString, micString

hwnd = Extern.FindWindow ("MSPaintApp", "cmd.gif - Paint")'
Print hwnd

l = -1 'left
t = -1 'top
r = -1 'right
b = -1 'bottom

succeeded = TextUtil.GetTextLocation("rights",hwnd,l,t,r,b)
Print succeeded

If Succeeded Then
 Print "Text found" & " Left:" & l &  " Top:" & t &  " Right:" & r &  " Bottom:" & b
End If

Enabling QTP to indentify WPF windows objects

I was trying to create a test script for an application which had a grid like UI build using WPF. When i tried to use QTP object spy it wasn't able to detect this object. After following up with HP someone in our team found a solution to this probem as:

Using command prompt with Run As Administrator execute the following command to register the DLLs found under "\Program Files (x86)\HP\QuickTest Professional\GlobalAssemblyCache\Net4"

C:\Program Files (x86)\HP\QuickTest Professional\bin> GACRegUtil4x86.exe -ie ..\G
lobalAssemblyCache\Mercury.QTP.Agent.dll

Hope this helps to someone facing the same issue.

Reference:
http://h30499.www3.hp.com/t5/Functional-Testing-QTP-Support/WPF-test-record-problems/td-p/5791825

Typical Structure for Test Automation Framework

DataRepo:

                This holds data. A standard tool like XL or MDB to hold test data and allowing enough flexibility to manipulate and modify data effectively. This tool / component will typically contain a list of test cases and the test data to be fed to the test case.

ActionLibrary:

                Also understood as functional keywords. All possible actions for a page in the AUT are captured in the form of functions. These functions can be called in the form of test steps.

CommonLibrary:

                Library of functions which make the code modular and reusable. This will typically contain following set of common technical functionalities:

1.       Data access

2.       Logging

3.       File handling

4.       Time handling

5.       Test Result Prepare & Publish

ObjectRepo:

                This is a repository to hold information about the objects which are part of the test application. Using this information the test script identifies the object to perform action on it.

Driver:

                This is a common script which ties / glues all the components described above. As a typical flow, driver script will do the following:

1.       Get the test case details (name, test data, etc) from DataRepo

2.       Based on the test steps it decides which functions to call and pass what test data to it

3.       Each function call tries to identify an object using the attributes available from the ObjectRepo to perform action around it.