Hi Allan,
As far as I understand the problem, it is related to the dynamic nature of the windowsUI.
I observe, that depending on object recognition method, the results are different.
“Selector” recognise only static shape of object, which can be not relevant to the actual its state. “Recorder” is able to unveil desired object in sequence of activities. When I highlighted an interesting field, first “click” inform “recorder” to “write down” pointed object. But this “click” also change the type of the field. As I am interested in this second face (class?) of the field, I have to click second time to tell “recorder” - “write it down”… And now I got a typical for edit fields behaviour, assign dialogue.
Unfortunately, I see some issues in this workflow. As I work mainly with FF and “open file” OS window, I expected that, as “selector” do, “recorder” will recognise child process. Even “recorder” correctly highlighted “search” field, first click results in NM.Get_Element (FF), second on the same highlight creates Windows.Get_Element with second face of the field.
I tried to compound both recognition and make a sequence “first face” - “click” - “second face” - “assignment”, but the “click” seems does not change the field face, even not virtual and with focus or the item is not properly passed between sequences.
Workflow ends with “Cannot locate element” message.
How to deal with this case?
I needs “search” field, as I know only name of file (unique id), but types can be various.
Kind regards,
Andy
first “face” of “search”
{
“ClassName”: “ModernSearchBox”,
“Name”: “SearchEditBox”,
“ControlType”: “Edit”,
“FrameworkId”: “Win32”
}
second “face” of “search”
{
“ClassName”: “RichEditBox”,
“Name”: “Pole wyszukiwania”,
“ControlType”: “Edit”,
“AutomationId”: “SearchTextBox”,
“FrameworkId”: “XAML”
}