UI Automation: Open File dialog elements tree contains not all elements
up vote
0
down vote
favorite
I'm trying to use UI Automation with C# to type file path in opened Open
dialog and then press Open button. I'm able to find the dialog itself, but searching for inner elements (file path text box and Open button) gives no result. When I traverse elements tree writing elements to log file, I see that the log is obviously too short and not all elements printed out.
Strange behavior: if I switch with mouse on another window, traversing of the dialog returns all elements and I'm able to find desired controls and interact with them.
I've tried many approaches to bypass the problem:
- open some window, switch to it with
AutomationElement.SetFocus
; - search for element with Win API (
FindWindowEx
); - get
AutomationElement
by point on screen within dialog's bounding rectangle iterating by x and y with some step.
No one approach give me desired result.
What can cause incomplete elements tree using UI Automation and what is workaround for this?
My scenario is:
- test clicks on a button on web page
- standard Windows dialog to select a file is opened
- I'm trying to fill file path text box and press Open button using UI Automation
c# ui-automation
|
show 3 more comments
up vote
0
down vote
favorite
I'm trying to use UI Automation with C# to type file path in opened Open
dialog and then press Open button. I'm able to find the dialog itself, but searching for inner elements (file path text box and Open button) gives no result. When I traverse elements tree writing elements to log file, I see that the log is obviously too short and not all elements printed out.
Strange behavior: if I switch with mouse on another window, traversing of the dialog returns all elements and I'm able to find desired controls and interact with them.
I've tried many approaches to bypass the problem:
- open some window, switch to it with
AutomationElement.SetFocus
; - search for element with Win API (
FindWindowEx
); - get
AutomationElement
by point on screen within dialog's bounding rectangle iterating by x and y with some step.
No one approach give me desired result.
What can cause incomplete elements tree using UI Automation and what is workaround for this?
My scenario is:
- test clicks on a button on web page
- standard Windows dialog to select a file is opened
- I'm trying to fill file path text box and press Open button using UI Automation
c# ui-automation
When you have found theAutomationElement
(corresponding to the new Window), you can useFindAll()
to find a specific class and cast it toAutomationElement
. Something like:AutomationElement element = [MainElement].FindAll(TreeScope.Descendants, Automation.RawViewCondition).OfType<AutomationElement>().FirstOrDefault(elm => elm.Current.ClassName.Contains("[Some Class Name]"));
– Jimi
Nov 13 at 12:18
Yes, but problem is elements are not found due to internal elements tree is incomplete for some reason
– Maxim
Nov 13 at 12:23
They're probably just inside a different container. If you don't know the structure of the Dialog you're inspecting, use Spy++ to explore it, see what the nesting is and act on it. When you have a better view of the Dialog composition, its easier to get to the right elements while parsing the Tree. You'ld have the same problem if you were usingEnumChildWindows
.
– Jimi
Nov 13 at 12:27
I've inspected structure with inspectors and I see elements I need. As I wrote in my question, if I just switch to another window (while Open dialog is opened), elements are found. Also I print all structure recursively to log and don't see those elements. So there is no problem with how I search for them.
– Maxim
Nov 13 at 12:29
What is this Dialog? Is it the Shell'sBrowseForFolder
one?
– Jimi
Nov 13 at 12:31
|
show 3 more comments
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm trying to use UI Automation with C# to type file path in opened Open
dialog and then press Open button. I'm able to find the dialog itself, but searching for inner elements (file path text box and Open button) gives no result. When I traverse elements tree writing elements to log file, I see that the log is obviously too short and not all elements printed out.
Strange behavior: if I switch with mouse on another window, traversing of the dialog returns all elements and I'm able to find desired controls and interact with them.
I've tried many approaches to bypass the problem:
- open some window, switch to it with
AutomationElement.SetFocus
; - search for element with Win API (
FindWindowEx
); - get
AutomationElement
by point on screen within dialog's bounding rectangle iterating by x and y with some step.
No one approach give me desired result.
What can cause incomplete elements tree using UI Automation and what is workaround for this?
My scenario is:
- test clicks on a button on web page
- standard Windows dialog to select a file is opened
- I'm trying to fill file path text box and press Open button using UI Automation
c# ui-automation
I'm trying to use UI Automation with C# to type file path in opened Open
dialog and then press Open button. I'm able to find the dialog itself, but searching for inner elements (file path text box and Open button) gives no result. When I traverse elements tree writing elements to log file, I see that the log is obviously too short and not all elements printed out.
Strange behavior: if I switch with mouse on another window, traversing of the dialog returns all elements and I'm able to find desired controls and interact with them.
I've tried many approaches to bypass the problem:
- open some window, switch to it with
AutomationElement.SetFocus
; - search for element with Win API (
FindWindowEx
); - get
AutomationElement
by point on screen within dialog's bounding rectangle iterating by x and y with some step.
No one approach give me desired result.
What can cause incomplete elements tree using UI Automation and what is workaround for this?
My scenario is:
- test clicks on a button on web page
- standard Windows dialog to select a file is opened
- I'm trying to fill file path text box and press Open button using UI Automation
c# ui-automation
c# ui-automation
edited Nov 13 at 13:20
asked Nov 13 at 12:04
Maxim
8181716
8181716
When you have found theAutomationElement
(corresponding to the new Window), you can useFindAll()
to find a specific class and cast it toAutomationElement
. Something like:AutomationElement element = [MainElement].FindAll(TreeScope.Descendants, Automation.RawViewCondition).OfType<AutomationElement>().FirstOrDefault(elm => elm.Current.ClassName.Contains("[Some Class Name]"));
– Jimi
Nov 13 at 12:18
Yes, but problem is elements are not found due to internal elements tree is incomplete for some reason
– Maxim
Nov 13 at 12:23
They're probably just inside a different container. If you don't know the structure of the Dialog you're inspecting, use Spy++ to explore it, see what the nesting is and act on it. When you have a better view of the Dialog composition, its easier to get to the right elements while parsing the Tree. You'ld have the same problem if you were usingEnumChildWindows
.
– Jimi
Nov 13 at 12:27
I've inspected structure with inspectors and I see elements I need. As I wrote in my question, if I just switch to another window (while Open dialog is opened), elements are found. Also I print all structure recursively to log and don't see those elements. So there is no problem with how I search for them.
– Maxim
Nov 13 at 12:29
What is this Dialog? Is it the Shell'sBrowseForFolder
one?
– Jimi
Nov 13 at 12:31
|
show 3 more comments
When you have found theAutomationElement
(corresponding to the new Window), you can useFindAll()
to find a specific class and cast it toAutomationElement
. Something like:AutomationElement element = [MainElement].FindAll(TreeScope.Descendants, Automation.RawViewCondition).OfType<AutomationElement>().FirstOrDefault(elm => elm.Current.ClassName.Contains("[Some Class Name]"));
– Jimi
Nov 13 at 12:18
Yes, but problem is elements are not found due to internal elements tree is incomplete for some reason
– Maxim
Nov 13 at 12:23
They're probably just inside a different container. If you don't know the structure of the Dialog you're inspecting, use Spy++ to explore it, see what the nesting is and act on it. When you have a better view of the Dialog composition, its easier to get to the right elements while parsing the Tree. You'ld have the same problem if you were usingEnumChildWindows
.
– Jimi
Nov 13 at 12:27
I've inspected structure with inspectors and I see elements I need. As I wrote in my question, if I just switch to another window (while Open dialog is opened), elements are found. Also I print all structure recursively to log and don't see those elements. So there is no problem with how I search for them.
– Maxim
Nov 13 at 12:29
What is this Dialog? Is it the Shell'sBrowseForFolder
one?
– Jimi
Nov 13 at 12:31
When you have found the
AutomationElement
(corresponding to the new Window), you can use FindAll()
to find a specific class and cast it to AutomationElement
. Something like: AutomationElement element = [MainElement].FindAll(TreeScope.Descendants, Automation.RawViewCondition).OfType<AutomationElement>().FirstOrDefault(elm => elm.Current.ClassName.Contains("[Some Class Name]"));
– Jimi
Nov 13 at 12:18
When you have found the
AutomationElement
(corresponding to the new Window), you can use FindAll()
to find a specific class and cast it to AutomationElement
. Something like: AutomationElement element = [MainElement].FindAll(TreeScope.Descendants, Automation.RawViewCondition).OfType<AutomationElement>().FirstOrDefault(elm => elm.Current.ClassName.Contains("[Some Class Name]"));
– Jimi
Nov 13 at 12:18
Yes, but problem is elements are not found due to internal elements tree is incomplete for some reason
– Maxim
Nov 13 at 12:23
Yes, but problem is elements are not found due to internal elements tree is incomplete for some reason
– Maxim
Nov 13 at 12:23
They're probably just inside a different container. If you don't know the structure of the Dialog you're inspecting, use Spy++ to explore it, see what the nesting is and act on it. When you have a better view of the Dialog composition, its easier to get to the right elements while parsing the Tree. You'ld have the same problem if you were using
EnumChildWindows
.– Jimi
Nov 13 at 12:27
They're probably just inside a different container. If you don't know the structure of the Dialog you're inspecting, use Spy++ to explore it, see what the nesting is and act on it. When you have a better view of the Dialog composition, its easier to get to the right elements while parsing the Tree. You'ld have the same problem if you were using
EnumChildWindows
.– Jimi
Nov 13 at 12:27
I've inspected structure with inspectors and I see elements I need. As I wrote in my question, if I just switch to another window (while Open dialog is opened), elements are found. Also I print all structure recursively to log and don't see those elements. So there is no problem with how I search for them.
– Maxim
Nov 13 at 12:29
I've inspected structure with inspectors and I see elements I need. As I wrote in my question, if I just switch to another window (while Open dialog is opened), elements are found. Also I print all structure recursively to log and don't see those elements. So there is no problem with how I search for them.
– Maxim
Nov 13 at 12:29
What is this Dialog? Is it the Shell's
BrowseForFolder
one?– Jimi
Nov 13 at 12:31
What is this Dialog? Is it the Shell's
BrowseForFolder
one?– Jimi
Nov 13 at 12:31
|
show 3 more comments
1 Answer
1
active
oldest
votes
up vote
0
down vote
I finally came to this workaround:
- the dialog is opened with textbox focused, so get handle to currently focused control;
- get
AutomationElement
by the handle; - send Alt + O using
SendKeys.SendWait
.
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
I finally came to this workaround:
- the dialog is opened with textbox focused, so get handle to currently focused control;
- get
AutomationElement
by the handle; - send Alt + O using
SendKeys.SendWait
.
add a comment |
up vote
0
down vote
I finally came to this workaround:
- the dialog is opened with textbox focused, so get handle to currently focused control;
- get
AutomationElement
by the handle; - send Alt + O using
SendKeys.SendWait
.
add a comment |
up vote
0
down vote
up vote
0
down vote
I finally came to this workaround:
- the dialog is opened with textbox focused, so get handle to currently focused control;
- get
AutomationElement
by the handle; - send Alt + O using
SendKeys.SendWait
.
I finally came to this workaround:
- the dialog is opened with textbox focused, so get handle to currently focused control;
- get
AutomationElement
by the handle; - send Alt + O using
SendKeys.SendWait
.
answered Nov 14 at 15:12
Maxim
8181716
8181716
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53280665%2fui-automation-open-file-dialog-elements-tree-contains-not-all-elements%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
When you have found the
AutomationElement
(corresponding to the new Window), you can useFindAll()
to find a specific class and cast it toAutomationElement
. Something like:AutomationElement element = [MainElement].FindAll(TreeScope.Descendants, Automation.RawViewCondition).OfType<AutomationElement>().FirstOrDefault(elm => elm.Current.ClassName.Contains("[Some Class Name]"));
– Jimi
Nov 13 at 12:18
Yes, but problem is elements are not found due to internal elements tree is incomplete for some reason
– Maxim
Nov 13 at 12:23
They're probably just inside a different container. If you don't know the structure of the Dialog you're inspecting, use Spy++ to explore it, see what the nesting is and act on it. When you have a better view of the Dialog composition, its easier to get to the right elements while parsing the Tree. You'ld have the same problem if you were using
EnumChildWindows
.– Jimi
Nov 13 at 12:27
I've inspected structure with inspectors and I see elements I need. As I wrote in my question, if I just switch to another window (while Open dialog is opened), elements are found. Also I print all structure recursively to log and don't see those elements. So there is no problem with how I search for them.
– Maxim
Nov 13 at 12:29
What is this Dialog? Is it the Shell's
BrowseForFolder
one?– Jimi
Nov 13 at 12:31