The My@WndTrepanat tool provides you with two great features which are:
1. It creates an interactive visual diagram showing control hierarchy in a tree.
This feature gives you a clear idea of the GUI internals of your tested application, which is quite important to write correct test scripts. Even more, you can see easily find invisible windows and operate with them.
Finally, for those who use TestComplete, this tool is shipped with a TestComplete plug-in by means of each you can find needed controls using the true control hierarchy.
Here are a couple of screenshots illustrating the results of using the tool in action:
2. It includes a handy real-time debugging tool for the TestComplete’s Regions.Find function.
The tool gives a big advantage for the TestComplete users, who needs to write scripts for applications with graphic GUI elements (not windowed controls). Let us explain why.
TestComplete includes special functions for working with such elements called Regions.Find and Regions.Compare. One of their parameter refers to a bitmap that represents a graphic element which you need to locate on the target window. A good example for such a graphic element is a TimeLine in video and audio editing systems, or special CAD elements, etc.
Usually, it is rather difficult to create bitmaps for such graphic controls and My@WndTrepanat makes this process as simple as possible. All what you need is to “capture” a graphic element, specify its name and invoke Regions.Find. In case this control is included in the target window, My@WndTrepanat will draw a frame on it to illustrate where your graphic element is located.
If needed, you can also adjust additional parameters of Regions.Find calls such as Left & Top by clicking the left mouse button on the needed place of the target control and Transparent by changing the state of the corresponding checkbox.
To illustrate how it works, let’s take a situation when you need to press a button on the tools palette of Adobe Photoshop. The interface of this graphic editor is completely based on non windowed (graphic) elements.
The only way to work with it, it to use pixel-by-pixel search of graphic elements based on elements samples. But the problem is that there is no ready library of such elements. For example, you need to find a button for the PEN tool. To prepare a bitmap for it, you need to use the capture tool included in TestComplete, save it to a file and then capture the entire tool palette using My@WndTrepanat. Now, open the saved by TestComplete file in My@WndTrepanat and notice how the tool shows the Regions.Find result for you:
You may know that sometimes, TestComplete cannot identify a windowed control explicitly. This happens when the window which you are working with includes a set of controls with the same wndClss and wndCaption values. In this case, TestComplete uses indexes which may lead to the wrong results. The following image illustrates how TestComplete represents the hierarchy and how it looks in reality:
Thus, often you may end up with a situation when you simply cannot locate the needed control or your script fails when you receive a new build of the tested application, since it does not “understand” that “similar” controls in fact have different parent windows.
Now, check how My@WndTrepanat builds the control hierarchy for the sample application and you will notice the difference!
To make the use of the tool easily, we developed a special plug-in called MyPlugin. Its use is described below.
The MyPlugin plug-in.
To start using the plug-in, first install myPlugin4TC3.pls in TestComplete.
It will give you 3 functions which will allow you to search controls in the way natural for Windows.
MyTCObject.GetChildWindow (hWnd: integer): hWnd MyTCObject.GetParentWindow (hWnd: integer): hWnd MyTCObject.GetWindowChildList (hWnd: integer): hWnd
To understand how it works in action, here is a sample function that search for a control using its parent as a parameter. Using this way, you make your scripts more reliable and their execution more stable since you can be sure that your code will find exactly what it is looking for!
Function SearchObject(wSource : OleVariant; SrchClass,SrchCaption : String) : OleVariant;
var
w: OleVariant;
CurWnd, i, SourceWnd, ChldCount: integer;
begin
SourceWnd := wSource.Id;
ChldCount := MyTCObject.GetWindowChildList(SourceWnd);
i := 1;
while i <= ChldCount do
begin
CurWnd := MyTCObject.GetChildWindow(SourceWnd,VarToInteger(i));
w := Sys.WindowFromHandle(CurWnd);
if VarType(w)<>VarEmpty then
if ((Pos(SrchCaption,w.wndCaption)>0) or (SrchCaption = w.wndCaption))
and (Pos(SrchClass,w.wndClass)>0) then
begin
Result := w;
break;
end;
Result := nil;
inc(i);
end;
if Result = nil then
begin
Log.CreateNode('Search Object');
if VarType(wSource) <> varEmpty then
Log.Message('Source object = '+wSource.Name);
Log.Message('SearchObject', 'SrchClass - ' + SrchClass + ' ; SrchCaption - ' +
SrchCaption, pmHigh, 2, clBlack);
Log.CloseNode;
end;
end;