Waiting for applications response : Automation API

[schachner]

I am using a Visual C++ GUI-Client which uses COM-Objects to
process several actions on a database.

So most of the time I have to wait for transactions to be finished before I can continue the testing procedure.

I wrote a testing programm which invokes my application and looks for a
certain data-set. Unfortunatly , it is not possible for Ranorex to recognize directly when a transaction of the application has finished.

Can I use the Ranorex-Classes in my application's code to tell the testing procedure about the state of my transaction?
If so, which classes should I use?

[Support Team]

Hi,

Normally, you'll simulate the same actions with Ranorex as a normal user of your application does. How does a user of your program recognize a finished transaction in your GUI. Are there any status text boxes or controls notifying a successful data base transaction? If yes, you will be able to search for a specific object having a specific state or text value.

Following example closes the calculator application when the given value within the text box equals to '9':

Code: Select all

Text resultBox = Host.Local.FindSingle(new Ranorex.Core.RxPath("/form[@title='Calculator']/text[@text='9, ']"),new Duration(60000));
Ranorex.Form calc = (Ranorex.Form)resultBox.Element.Parent;
Mouse.MoveTo(calc);


Would it be possible to do something similar within your automation code?

best regards,

Christoph,
Ranorex Support Team

[jhance]

I have a similar and possibly simpler problem. First, I have an application which pulls a bunch of data from a database, runs some calculations, then outputs the whole thing to a .Net datagrid viewer. As such, the way the user would "know" the calculations were complete is the datagrid viewere would render. Load time is directly related to the size of the data being loaded.

Similarly, we output some of our reports, based on the data we loaded from the db and the calculations previously performed, to the default .html viewer (usually IE). Again, the user knows the load is done when the page renders.

So, how might we insert some kind of Wait, Sleep, or "look for element X" into a script, so that Ranorex waits until the data is completely loaded before proceeding with it's testing?

Thanks so much!

[Support Team]

The find() method in a Ranorex Element Object supports a Duration Timeout.
So you can wait for an object until its data is loaded.

Regards,
Christian,
Ranorex Support Team

[schachner]

We often have background actions that yield no visible change in any control, e.g. checks, wether a customer's number does exist or not.

The user is just waiting for the application to return and to let him jump
to the next input box to enter different data (no discussion about application design, please ). So for me it seems to be necessary to adapt my application's code using events that can be handled by the test automation.

So my question is still : are there events in the Ranorex API that can be used for this (in C++ application coode)?

[Support Team]

So my question is still : are there events in the Ranorex API that can be used for this (in C++ application coode)?

No, currently events coming from elements are not supported. However, you could use the "HasFocus" property to check whether the element already has the focus. You can do that in code using a loop to wait for the element to get focus or by adding a condition ("and @hasfocus='true'")to the RanoreXPath of the element, e.g.:

Text textWithFocus = myForm.FindSingle("text[@controlid='403' and @hasfocus='true']", 10000);

Regards,
Alex
Ranorex Support Team

[atom]

I use several "tricks" when there is no visual clue if the AUT has finished an operation:

- Check mouse pointer Hour-Glass
- Check Process.Responding
- Check AppHung property of the main form
- Send a WM_NULL message with no time-out
- Loop attempting to set Focus on an element, and then check if it has Focus

Im sure some combination of above might be of some help.

It also depends on the AUT, if the operation is done in the GUI thread, or some background thread.