This project is read-only.

Window undetected by White, detected using UIAutomation

Nov 20, 2012 at 11:07 AM


Posting here but really unsure whether this forum is even monitored by the Dev team anymore.

I've been using White for a while now but tend to use a mixture of White and the underlying UIAutomation as the latter is more accurate. 

Anyway, my query is this....the snippet of code below fails for white but succeeds for UIAutomation and I'm a little lost as to why.

The White code below fails on both counts to find the said window

windowList = Desktop.Instance.Windows().FindAll(obj => obj.Name.Contains(windowName)); 

windowList = Desktop.Instance.Windows().FindAll(obj => obj.Title.Contains(windowName));     

However, the UIAutomation code finds the window no problem.

Condition condition1 = new PropertyCondition(AutomationElement.NameProperty, windowName);                   

Condition condition2 = new PropertyCondition(AutomationElement.ControlTypeProperty, ControlType.Window);                   

AndCondition AndCondition1 = new AndCondition(condition1, condition2);                    AutomationElement window = AutomationElement.RootElement.FindAll(TreeScope.Descendants, AndCondition1);

The depth level using white has been set to 10 which I believe is more than adequate as the window in question is 4 levels from the Desktop hierarchy.

Nov 20, 2012 at 6:50 PM
Edited Nov 20, 2012 at 6:54 PM

you are right.. the most questions weren't answered..

 You code is correct, I just tried to open several notepad instances and executed the code below and it returned the correct number. Something wrong in your environment. Is it 64 bit OS? Try to play with VS project settings. I saw a problem when White couldn't click calculator button, but after playing with project settings it started to work..


var notepads = Desktop.Instance.Windows().FindAll(w => w.Name.Contains("Notepad")); 


Nov 22, 2012 at 9:13 AM

Is it a 64bit OS but I've not had many issues with 64bit up until now.


What Visual Studio settings are you referring to?

Nov 22, 2012 at 8:34 PM

Surely one of them was Project settings -> Debug -> Platform target -> x86, also I remember that I changed something in configuration manager from edit box next to start debugging [ > ] button

It's strange that the code you provide doesn't work.. I've never had problems with it

But I had problems finding windows from Application and Windows using constructors with Title / SearchCriteria. Could you please look at the post below?

Nov 22, 2012 at 8:56 PM

Thanks for the feedback. I compile as AnyCPU which normally works fine. This is on Windows 2008 server which might make a difference. 

The actual control is the User Name dialog in MS Excel version 2007\2010 (when you first launch Excel it prompts for a user). Using Automation UI, this is correctly detected but which searches differently and this brings back the toolbar incorrectly. Although I can then grab the dialog using UI Automation, the OK button is nowhere to be seen, even with UI Automation. The UISpy does not detect it but Inspect.exe and UIVerify do. Interestingly enough, Inspect (according to Microsoft) switches between Native and Managed versions of the UI Automation libraries and its the C++ version that will hook into anything. 

Nov 23, 2012 at 1:13 PM
Edited Nov 23, 2012 at 1:18 PM

Probably UISpy doesn't detect a control due to by default it uses Control view. Try to open Raw View, which contains full unfiltered tree and try to find the control again.

I'm almost new in UI Automation, so I might use wrong terms, but I try to explain (I faced with the similar issue not so long ago).

When you use AutomationElement.FindFirst and FindAll looks like UIA searches only in Control view. Control view does not contain all the existing tree elements, but only those which are interesting for user from interaction point of view. E.g., invisible elements aren't shown, and and some panes. The most full view is Raw View.

You can use TreeWalker.RawViewWalker for searching in the RawView. It contains methods like: GetParent, Get1stChild, GetLastChild, GetNext/Prev Sibling. You can write you own wrapper for TreeWalker.RawViewWalker to make it more useful.

Nov 26, 2012 at 4:26 PM

I believe this now to be a 2008 Server R2 issue which should be supported. Window 7 works fine so further investigation is required I think. 

Windows correctly detects the button I require but on Windows Server 2008 R2 the button cannot be detected, even with the RawViewWalker.