This project is read-only.

Tree Constructor Internal?

Jun 10, 2008 at 9:23 AM
Is there a reason why the Tree constructor is maked as internal, I want to use the Tree wrapper on an exisiting automation element and can't instantiate one.

Jun 11, 2008 at 3:01 AM
I think that is a mistake as it is not consistent with other UIItems. Having said that I want to move in that (making things internal) direction generally though. Because it seems it is allowing people to make mistakes. Hence in your case, can you please tell me why you are not using window.Get<Tree>(....) to get the tree? This should instantiate it for you.
Jun 11, 2008 at 9:44 AM
Thanks for the response.

The main reason I don't use window.Get<T> is performance, the form I'm trying to automate is quite complex and has very many controls.  Whenever I try and search my form with Get<T>, CPU hits 100% and the call never returns.
Instead I focus my search a generation at a time using AutomationElementFinder.Child then wrapping the found AutomationElement with the appropriate UIItem.
Part of the problem maybe that I'm working with DevExpress controls which I can see don't expose themselves for automation very well.


Jun 12, 2008 at 3:08 PM
Are you using window.Get<Tree>() or something like window.Get<Tree>("someTree")?
Jun 12, 2008 at 4:09 PM
I'm using window.Get<Tree>("treeName").  However it is a DevExpress tree I'm looking for not a WinForms tree which might confuse matters.
The DevExpress tree does appear as a ControlType.Tree in UISpy though.
Jun 13, 2008 at 9:03 PM
This is confusing to me. Whatever search criteria you are using in AutomationElementFinder, you should be able to use it in window.Get?
Am I missing something?