Tuesday, October 05, 2010 10:25 AM
In my workflow, click on a button and next step would be to select the menu item. After click on ok button, the process becomes busy and the menu item cannot be selected as process is busy. Here when i use menuitem.WaitForControlReady(time) , it should return false, as menu item is not allowed to select. But almost all teh times, i see that it returns true.
Want to know where am i doing wrong?? i want to see with what settings, waitForControlReady returns false.
Tuesday, October 05, 2010 1:56 PM
By default .WaitForControlReady() will check for the foreground thread i.e., UI Thread only. What kind of wait have you put in your App? Can you try setting the following property in your Coded UI Test and see the behaviour:
Playback.PlaybackSettings.WaitForReadyLevel = WaitForReadyLevel.AllThreads;
Tuesday, October 05, 2010 2:49 PMTried this,but this did not help me.
Tuesday, October 05, 2010 3:01 PMOk, can you let us know how you have implemented the wait mechanism in your app ? Which thread is busy in Application after button click, is it UI (foreground) thread only ?
Wednesday, October 06, 2010 4:55 AM
Here are my workflow steps:
1. I have a A.exe process
2. B.exe process gets started on making few actions on some controls of A.exe process
3. Making an ation over A.exe control , makes B.exe to be busy
4. Now B.exe doesnot allow to take any actions
Note: i dont have any problem to handle synchronization here. Using WaitForReadyLevel.AllThreads works well for me. But my problem here is I want to see WaitForReadyControl to return false, when any control of B.exe doesnot allow to take any keyboard or mouse inputs.
How do you suggest me to check this?
Tuesday, March 13, 2012 4:17 AMAny update on this?
Monday, March 19, 2012 6:15 AM
Will it be possible for you to share the Coded UI Test code for both
a) when you use WaitForReadyLevel.AllThreads and things work fine
b) when you dont want to use the above settings and it is not working as expected.
You can mail me at this address => deepak.singhalATmicrosoftDOTcom
Monday, April 02, 2012 7:54 AM
I don't have sample application to reproduce this. But this happened in our real product.
In this application(A.exe), when we do some action, it internally opens Excel.exe to do some processing, which means Excel.exe becomes busy and after sometime, Excel.exe is internally closed and A.exe becomes free at the end. During playing with this, what i observed is, Excel.exe becomes free in the middle of its processing and again becomes busy. When Excel .exe is free from busy, at this time, WaitForControlReay(AllThreads) is coming out.
Should i rely only on UI sync for these kinds of scenarios?
Saturday, April 14, 2012 7:16 AM
The behavior seems correct since the app is not busy, probably in such case you can add some delay and again wait for the app to get free.
- Marked As Answer by A Nagababu Saturday, April 14, 2012 11:11 AM