Я пытаюсь решить следующую проблему с помощью API автоматизации пользовательского интерфейса Windows:
Учитывая точку на рабочем столе (x, y), я хочу определить ОЧЕНЬ БЫСТРО (менее 100 мсек) следующее:
- Элемент автоматизации под (x, y)
- Набор элементов AutomationElements, представляющих путь от указанного элемента до корня (или до окна верхнего уровня).
Проблема 1 кажется простой: вызов ElementFromPoint (x, y). Простое тестирование на случайных точках дает результат в среднем около 20 мсек, в зависимости от того, насколько сложным и насколько глубоко был выбран элемент в визуальном дереве.
Проблема 2 более сложная: мне кажется, я не могу найти способ использовать кэширование для ускорения перехода к визуальному дереву:
- кэширование всего визуального дерева слишком медленное и может никогда не закончиться согласно документу; даже если мне удастся все кешировать, после нескольких действий пользователя он становится недействительным и нуждается в обновлении
- ограниченное кэширование для Предков недопустимо (идея состоит в том, что при углублении пользовательского интерфейса верхние уровни визуального дерева уже кэшируются и не требуют обновления)
- Найти все кликабельные элементы вместе с их предками, кажется, тоже медленно
Идея, стоящая за этим, состоит в том, чтобы вычислить XPath для каждого элемента, на который щелкают, в графическом интерфейсе во время выполнения глобальной ловушки мыши перед вызовом следующего обработчика ловушки. Если обработчик работает медленно, это влияет на взаимодействие с пользователем и, в конечном итоге, Windows отменяет подписку на обработчик. Основываясь на некотором чтении, если обработчик занимает более 100 мс, GUI начинает чувствовать себя вялым.
Я знаю, что Windows не является операционной системой реального времени, и использование абсолютного времени на самом деле не применимо, поэтому примите 100 мсек "как достаточно быстрые, чтобы пользователь не заметил".
Я надеюсь, что кто-то там уже решил эту проблему и может дать некоторые рекомендации. Еще лучше, я надеюсь, что кто-то, кто имеет внутренние знания об этом API, может дать некоторое представление о целесообразности плана или альтернативы ему.
Большое спасибо !!!