Finding controls using raw elements

Mar 25, 2008 at 6:03 PM
In our application under test it's necessary for us to locate elements (controls) that are only accessible as raw elements, we have done this previously by stepping over the TreeWalker.RawViewWalker (from System.Windows.Automation)

An example of this would be in your WPFTestApp, if you use UI Spy to show both the 'Control View' and the 'Raw View' and identfy the label on the Group box on the top of 'Form 1' you'll see that the 'Raw View' in UISpy shows the text item whereas the 'Control View' does not.

Is there any plan to add support for accessing these raw elements to White? (or is it already there and I'm just not seeing it?)

Thanks,

James.
Coordinator
Mar 25, 2008 at 7:20 PM
The idea of white is to hide the users from complexity of UIAutomation and window messages. The user of white should be able to ask a question and if white can (using UIA) can answer it it would.
So my question would be what is that you want to know about GroupBox which you cannot get from the GroupBox object in white?
Every UI item exposes AutomationElement (property by same name). White is an abstraction, but if you want to bypass it for certain purpose you can do that.
You can also use class AutomationElementFinder etc for your purpose if you want.
Mar 26, 2008 at 11:32 AM
I understand what you're saying but I think I need to give you a better example than using the groupbox in your WPF test app. Take the following example from UISpy details when identifying a control on our application under test:

Control View:

-ListItem (has no automation ID and a name that does not uniquely identify it)
--Image (has no name nor automation ID)

Raw View:

-ListItem (has no automation ID and a name that does not uniquely identify it)
--Image (has no name nor automation ID)
--TextBlock (has no automation ID but does have a unique name)

In the above control example I want to be able to double click the specific list item but when I look at the control view there are no properties that uniquely identify the list item, the only control that allows me to uniquely identify the list item, and therefore locate it and select it i.e. the TextBlock, which is only visible in the raw view.

Does that make my problem any more clear?

In specific response to your point about using AutomationElementFinder, I cant use any of the methods in there to find controls that are not on the Control view and the TextBlock in my example is not visible in the control view.

I also appreciate your point that in this example I could bypass White, but then I would have to ask myself whats the point in using White at all if much of the time I'm having to bypass it to automate controls in my application.

Thanks,

James.
Coordinator
Mar 26, 2008 at 6:07 PM
I understand the issue better now. I had infact never come across example like this before.
I am creating an issue for this in the Issue Tracker and would fix this in the next release.
The example I sent was to indicate that you can get hold of the AutomationElement and do what you want to do with. This doesn't mean that it is the right solution but something which you can use till white fixes it. The whole idea of white is to avoid users to having to do that.
Mar 27, 2008 at 10:42 AM


viveksingh wrote:
I understand the issue better now. I had infact never come across example like this before.
I am creating an issue for this in the Issue Tracker and would fix this in the next release.
The example I sent was to indicate that you can get hold of the AutomationElement and do what you want to do with. This doesn't mean that it is the right solution but something which you can use till white fixes it. The whole idea of white is to avoid users to having to do that.


Thanks very much, having the ability to access raw elements would be incerdibly useful for us.

James.