Тестирование WPF через UIAtomation
От: vaa  
Дата: 20.12.22 03:52
Оценка:
Получаю ссылку на главное окно(из Process)
получаю
AutomationElement.FromHandle(windowHandle);

Пытаюсь найти нужный или все элементы через
root.FindAll(TreeScope.Subtree, System.Windows.Automation.Condition.TrueCondition);

почему-то получаю только элементы бокового меню.
Аналогичный результат получаю при помощи
TreeWalker.RawViewWalker

А вот по точке отлично отрабатывает.
 AutomationElement.FromPoint(new Point(267, 465));

Приложение на WPF(DX).
Собственно вопрос, как не зная координат, найти искомые элементы или хотя бы все элементы принадлежащие окну?
подозреваю что нужный мне элемент находится внутри ControlType Custom(50025)
т.к. его тоже не находит FindFirst от непосредственно содержащего его элемента ControlType Group(50026)

Парадокс в том, что в обратную сторону(к родителю) путь рисуется до самого главного окна.

Пока только одна идея: поделить окно на квадраты и случайным образом сканировать искомые элементы при помощи FromPoint.

итоги: при переборе окошка 700 на 700 с шагом 50 по икс, 25 по игрик элемент в середине окошка определяется примерно за 30-40 сек. плохо конечно, но зато наверняка.

Пока остается загадкой почему в обратку цепочка ребенок — родитель строится, а прямо нет. Пробовал FLaUInspect. Он видит ровно тоже что и я.

На СО нашел что-то похожее, там решение было довольно странное — после подписания приложения обход дерева стал полным.
Еще(я проверить пока не могу — тестирую удаленно через тимку) заметили что на тачке с VS находились все элементы.

Быть может спас бы манифест
  <requestedExecutionLevel  level="highestAvailable" uiAccess="true" />

но только если приложение будет подписано, иначе "сервер возвратил ссылку"
подписал(не сборку, сам файл приложения с помощью signtool), запустил, не видит

В этой статье указывается на проблемы с DX.
и похоже решения там нет.
☭ ✊ В мире нет ничего, кроме движущейся материи.
Отредактировано 21.12.2022 4:32 Разраб . Предыдущая версия . Еще …
Отредактировано 21.12.2022 4:06 Разраб . Предыдущая версия .
Отредактировано 21.12.2022 3:35 Разраб . Предыдущая версия .
Отредактировано 21.12.2022 1:23 Разраб . Предыдущая версия .
Отредактировано 20.12.2022 7:53 Разраб . Предыдущая версия .
Отредактировано 20.12.2022 6:22 Разраб . Предыдущая версия .
Отредактировано 20.12.2022 5:55 Разраб . Предыдущая версия .
Re: Тестирование WPF через UIAtomation
От: Михаил Романов Удмуртия https://mihailromanov.wordpress.com/
Дата: 21.12.22 07:13
Оценка: 6 (1)
Здравствуйте, vaa, Вы писали:

vaa>и похоже решения там нет.

Я не супер специалист по UI Automation поэтому могу только неструктурированно набросать некоторых своих мыслей...
— кэш. У UI Automation это реально неудобное место, потому четких критериев, когда надо обновлять, а когда не обязательно я не знаю. Приходится постоянно дергать GetUpdatedCache(). Тот же FlaUI, достаточно успешно все эти обновления кэшей берет на себя (честно скажу, не смотрел как они делают, но пока на какие-то проблемы связанные с неполучением элемента из-за кэша в FlaUI, я не нарывался.
— элемент "не контрол". Т.к. вы пишите, что FLaUInspect не видит этот элемент, но в целом он находится — симптомы кажутся прямо знакомыми. Правда, вы писали, что RawViewWalker тоже не помог...
Попробуйте глянуть через стандартный Inspect, который идет в SDK. Там есть возможность посмотреть в Content и Raw режиамах (FlaUIInspect — только в Control)
— ну и обратиться к вендору я ведь правильно понимаю, что DX это DevExpress? Даже на RSDN были специалисты работавшие там и именно над WPF контролами (работают ли сейчас — не знаю).
Re[2]: Тестирование WPF через UIAtomation
От: vaa  
Дата: 22.12.22 02:37
Оценка:
Здравствуйте, Михаил Романов, Вы писали:

МР>Здравствуйте, vaa, Вы писали:


vaa>>и похоже решения там нет.

МР>Я не супер специалист по UI Automation поэтому могу только неструктурированно набросать некоторых своих мыслей...
МР>- кэш. У UI Automation это реально неудобное место, потому четких критериев, когда надо обновлять, а когда не обязательно я не знаю. Приходится постоянно дергать GetUpdatedCache(). Тот же FlaUI, достаточно успешно все эти обновления кэшей берет на себя (честно скажу, не смотрел как они делают, но пока на какие-то проблемы связанные с неполучением элемента из-за кэша в FlaUI, я не нарывался.
МР>- элемент "не контрол". Т.к. вы пишите, что FLaUInspect не видит этот элемент, но в целом он находится — симптомы кажутся прямо знакомыми. Правда, вы писали, что RawViewWalker тоже не помог...
МР>Попробуйте глянуть через стандартный Inspect, который идет в SDK. Там есть возможность посмотреть в Content и Raw режиамах (FlaUIInspect — только в Control)
МР>- ну и обратиться к вендору я ведь правильно понимаю, что DX это DevExpress? Даже на RSDN были специалисты работавшие там и именно над WPF контролами (работают ли сейчас — не знаю).

Спасибо за наводку на инспект.
Первоначально использовал аксэсибл инсайт.
а он по координатам только работает. и строит обратное дерево. тут проблем нет.
инспект и флюай работают от корня и одинаково.
Вообщем обнаружил следующее, если запустить приложение и открыть нужный раздел,
а затем запустить инспект, то все эелементы на месте, но вот после этого перейдя в другую форму, вижу только максимум кэш предыдущего элемента.
Т.е. судя по всему внутри приложения происходит какой-то сбой и он перестает нормально взаимодействовать с аутомэйшэном.
☭ ✊ В мире нет ничего, кроме движущейся материи.
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.