Как я автоматизировал UI в Windows: UIAutomation и Win32

Привет, меня зовут Алексей, я C# разработчик. Я разрабатывал библиотеку для автоматизации взаимодействия с различными UI-элементами и их захвата. Одной из поддерживаемых сред в такой библиотеке обязательно должна быть Windows и в ней так же требуется: находить кнопки, поля, окна, списки, нажимать на них, читать значения, вводить текст и в целом обращаться с интерфейсом не как пользователь с мышкой, а как программа.

На первый взгляд задача звучит просто: нашли элемент, кликнули, пошли дальше. Но в реальных приложениях у элемента может не быть (считай не будет) нормального AutomationId, у нескольких окон может быть один и тот же заголовок, дерево интерфейса может прогружаться не сразу, а старое desktop-приложение вообще не предназначено для взаимодействия с современными API для автоматизации.

В итоге в моей библиотеке появилось два основных Windows-подхода:

• UIAutomation — когда приложение нормально отдаёт дерево элементов и поддерживает паттерны взаимодействия

• Win32 — когда приходится работать ближе к системе: через hwnd, положение элементов, со старыми интерфейсами

Самое важное и сложное оказалось в том, чтобы просто однозначно описать элемент для повторного поиска. Если вдруг у кого-то есть задачи в этом направлении, то надеюсь что мой опыт будет полезен.

Структурируем элемент

Элемент интерфейса по понятным причинам не может храниться как набор координат или RuntimeId, нас интересуют неизменные признаки которые будут у элемента на любой машине при любом положении элементов. Набор таких признаков может быть разным и, как правило, устанавливается опытным путём с каждым конкретным элементом, а значит не все признаки обязаны участвовать в поиске, но чем больше выбор тем лучше. Требуется структура, где видна вовлечённость конкретного свойства в поиск:

class ElementProperty{    string Name;    object Value;    bool IsMatched;    MatchType MatchType;}enum MatchType{    Equal,    NotEqual,    Regex,    Wildcard}

В идеале мы всегда должны определять элемент по таким свойствам, как: имя, тип, AutomationId, класс. Но очень часто они будут либо пустые, либо много совпадений с другими элементами, поэтому при автоматизации нельзя забывать про экземпляр процесса в котором мы хотим работать, текст окна, видимость, размеры, индекс среди похожих элементов и другие признаки.

Тема привязки к правильному процессу очень важна и очевидно, что привязка по одному только ProcessId не сработает. Он не переживёт перезапуск приложения, а даже если вы получите его по имени процесса, то дочерние процессы никто не отменял. Например, в Windows 11 даже калькулятор имеет дочерний процесс в котором уже рендерятся кнопки, а внешним и перекрывающим будет ApplicationFrameHost.exe. В своём решении я внутри проверяю такие цепочки и проверяю что элемент точно соответствует окну, внутри которого мы сейчас работаем.

MatchType нужен в случае если мы хотим проверить, например, заголовок окна вида «Заявка — №123». Номер в таком случае это нестабильный текст, поэтому можно применить Wildcard/Regex и записать в Value «Заявка — *». Это простая вещь, но она сильно повышает живучесть сценариев, в UI редко бывает так, что все атрибуты стабильны.

UIAutomation: удобно, пока приложение позволяет

Для современных Windows-приложений чаще всего удобнее начинать с UIAutomation. Он позволяет работать не только с координатами, а с логическими элементами интерфейса. Например, кнопку можно нажать через InvokePattern, текстовое поле заполнить через ValuePattern, чекбокс переключить через TogglePattern.

В моём базовом классе обычный клик выглядит примерно так:

if (_element.GetCurrentPattern(UIA_PatternIds.UIA_InvokePatternId)     is IUIAutomationInvokePattern pattern){    pattern.Invoke();}

Это точно лучше клика по координатам: элемент может находиться в другом месте, окно может быть передвинуто, а действие всё равно останется логическим действием “нажать кнопку”.

Но UIAutomation не всегда даёт один идеальный путь. Например, при записи текста я сначала пробую ValuePattern:

if (_element.GetCurrentPattern(UIA_PatternIds.UIA_ValuePatternId)     is IUIAutomationValuePattern pattern){    pattern.SetValue(text);}

А если элемент этот паттерн не поддерживает, приходится ставить фокус, выделять старый текст и отправлять ввод через SendKeys. Это как раз типичный компромисс в UI-автоматизации: сначала используем правильный API, а если приложение его не поддерживает, то падаем на более общий механизм.

Для того чтобы библиотека покрывала реально широкий диапазон действий, я добавил типизированные обёртки вместо одного суперкласса: UiaButton, UiaComboBox, UiaWindow, UiaTable и так далее. Базовый класс умеет общие вещи: кликнуть, прочитать, записать, подсветить, получить bounds. А конкретный тип добавляет свои действия: например, ComboBox умеет раскрыться, выбрать элемент по индексу или имени, прочитать список доступных значений.

Одно из слабых мест UIAutomation — одинаковые элементы. В дереве может быть несколько кнопок “ОК”, несколько полей ввода без AutomationId, несколько окон одного процесса. Поэтому я разделил поиск на несколько этапов: от поиска корневого элемента приложения спускаюсь к поиску самого элемента.

В UIAutomation дерево уже существует как логическая структура элементов. Есть корневой элемент рабочего стола:

for (var attempt = 0; attempt < attempts; attempt++){    result = root?.FindAll(scope, condition);    if (result?.Length > 0)    {        return result;    }    Thread.Sleep(delayMs);}

От него можно искать дочерние элементы через FindFirst или FindAll, указывая область поиска:

root.FindAll(TreeScope.TreeScope_Descendants, condition);

Самое удобное в UIA — условия можно собрать из свойств элемента. Например, если мы хотим искать по AutomationId, Name, ControlType или ProcessId, для каждого свойства создаётся PropertyCondition, а потом они объединяются в одно AndCondition.

Упрощённо это выглядит так:

var conditions = new List<IUIAutomationCondition>();foreach (var property in properties){    conditions.Add(_automation.CreatePropertyCondition(        propertyId,        property.Value    ));}var condition = _automation.CreateAndConditionFromArray(conditions.ToArray());

Сначала UIA сам быстро отдаёт кандидатов по статическим атрибутам:

var allElements = appWindowElement.FindAll(    TreeScope.TreeScope_Descendants,    controlCondition);

А потом я уже прохожу по найденным элементам вручную и проверяю динамические свойства:

foreach (var prop in dynamicProperties){    var value = elem.GetCurrentPropertyValue(propertyId);    if (!AttributesComparer.Compare(        prop.Value.ToString(),        value?.ToString(),        prop.MatchType))    {        fail = true;        break;    }}

Такой подход полезен, потому что UIAutomation хорошо умеет искать по точным условиям, но не решает все задачи из реального мира. Ещё один важный момент — поиск не сразу идёт по всему рабочему столу. Сначала я пытаюсь найти окно приложения по ProcessId. Если сохранённый pid уже неактуален, используется имя процесса и индекс процесса:

После того как окно найдено, поиск идёт уже внутри него. Искать кнопку “ОК” по всему рабочему столу — плохая идея, а если искать её внутри конкретного окна конкретного процесса — уже гораздо лучше.

Win32: минимальная абстракция

В Windows до сих пор много интерфейсов, которые лучше раскрываются через Win32. Там основной идентификатор элемента — это hwnd, handle окна или элемента.

В Win32-режиме элемент описывается немного иначе. Помимо обычных свойств есть свойства родителя и корневого окна, это оказалось полезно для старых desktop-интерфейсов, где дочерний элемент сам по себе может быть почти безымянным. У него есть класс, порядковый номер среди соседей, ControlID, размеры, стиль, но часто решающим становится контекст: в каком окне он лежит, кто его родитель, какой заголовок у корневого окна.

Верхний уровень можно получить через EnumWindows, дочерние окна — через EnumChildWindows. В моей реализации рекурсивный поиск выглядит примерно так:

var hwnd = FindWindow(    User32.GetDesktopWindow(),    CreateWindowCheckFunc(descriptor.Properties));List<IntPtr> FindWindow(IntPtr parent, Func<IntPtr, int, bool> checkWindowFunc){    var (callback, result) = CreateEnumWindowCallback(checkWindowFunc);    var callbackPtr = Marshal.GetFunctionPointerForDelegate(callback);    User32.EnumChildWindows(parent, callbackPtr, IntPtr.Zero);    var (targets, children) = result.Value;    foreach (var child in children)    {        var childResult = FindWindow(child, checkWindowFunc);        return childResult;    }    throw new Exception("Not found");}

FindWindow обходит дочерние окна, проверяет каждое через функцию-фильтр и, если совпадений нет, рекурсивно спускается глубже.

Здесь есть неприятная деталь с которой я однажды столкнулся: при рекурсивном обходе Win32-окон иногда можно снова встретить уже пройденный handle, поэтому в коде хранится ещё и история обхода. Это защита от зацикливания: в теории дерево должно быть деревом, а на практике Windows-интерфейсы сильно путают своей структурой.

Интересный момент был с выбором элемента под курсором. Обычный WindowFromPoint может вернуть слишком крупный контейнер. Поэтому я сделал поиск самого маленького дочернего окна, которое содержит точку. Сначала поднимаемся до подходящего верхнего родителя, потом рекурсивно спускаемся к самому маленькому видимому дочернему окну. Для захвата элементов мышкой это даёт более точный результат.

В Win32-режиме часть действий можно делать через оконные сообщения. Например, кнопку можно нажать так:

User32.PostMessage(_hwnd, User32.WindowMessage.WM_BM_CLICK, IntPtr.Zero, IntPtr.Zero);

Текст можно читать и записывать через WM_GETTEXT и WM_SETTEXT. Окно можно закрыть через WM_CLOSE, развернуть через ShowWindow, передвинуть через SetWindowPos. Это удобно, потому что действие не обязательно требует реального перемещения мыши. Сценарий становится менее зависимым от положения окна и состояния курсора.

Но полностью от “глобальных” действий уйти нельзя. Иногда элемент не поддерживает нужный паттерн, иногда приложение реагирует только на настоящий ввод. Поэтому в библиотеке остались методы вроде GlobalClickCentre, Drag, Drop, SendKeys. Это нормальная практика: сначала использовать самый надёжный логический способ, а если он невозможен — переходить к более низкому уровню.

Retry и Wait: интерфейс живёт не по нашему таймеру

Это отдельная часть, без которой UI-автоматизация быстро превращается в набор случайных ненадёжных Thread.Sleep, а интерфейс никогда не работает синхронно с нашим кодом.

Когда мы нажимаем кнопку, нам кажется, что действие завершилось. Но для приложения это часто только начало: событие попало в очередь сообщений, данные начали грузиться, элементы начали появляться в UI-дереве. Визуально пользователь может уже видеть форму, но для UIAutomation часть элементов ещё недоступна. Или наоборот: элемент уже есть в дереве, но ещё disabled, перекрыт, не сфокусирован или не готов принимать ввод.

Retry я использую внутри низкоуровневого поиска. Например, если FindAll прямо сейчас не вернул кандидатов, это ещё не значит, что элемента нет. Возможно, дерево просто не успело обновиться. Поэтому можно сделать несколько коротких попыток:

for (var attempt = 0; attempt < attempts; attempt++){  result = root?.FindAll(scope, condition);  if (result?.Length > 0)  {    return result;  }  Thread.Sleep(delayMs);} 

Это не полноценное ожидание бизнес-состояния, а скорее защита от мелких гонок интерфейса. Его задача — сгладить ситуации вида “элемент появился через 100 мс после того, как мы начали искать”. А вот Wait — это уже часть сценария. Он должен отвечать не на вопрос “прошло ли 5 секунд?”, а на вопрос “интерфейс пришёл в нужное состояние?”. Например:

• элемент появился;

• окно стало активным;

• поле получило фокус;

• кнопка стала доступной;

• значение атрибута изменилось;

В библиотеке для этого есть WaitCondition. Условно сценарий должен выглядеть так:

Click();Wait(10, new [] {  new WaitCondition(element, Condition.Exists, Comparison.Equal, true)}); // ждём 10 секунд пока не появится элементFindControl(element).Read(); 

Разница кажется небольшой, но для стабильности она огромная. В первом случае мы просто надеемся, что 5 секунд хватит, а во втором мы ждём появления результата. Ещё полезнее ждать не только наличие элемента, а его состояние. Окно может открыться, но не стать активным. Поэтому хороший сценарий должен проверять состояние максимально близкое к следующему действию.

Если следующий шаг — ввод текста, лучше дождаться фокуса или доступности поля. Если следующий шаг — чтение результата, лучше дождаться изменения текста. Если следующий шаг — нажатие кнопки, лучше убедиться, что кнопка существует и enabled.

Есть ещё один нюанс: ожидания не должны скрывать плохой поиск. Если локатор нестабильный, большой timeout только замаскирует проблему. Поэтому я стараюсь разделять ответственность:

• селектор должен уметь надёжно найти элемент по дескриптору;

• retry должен сгладить короткие технические задержки дерева;

• wait должен ждать понятное состояние интерфейса;

• ошибка должна объяснять, чего именно не дождались.

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

Что я понял в процессе

Главный вывод для меня: автоматизация Windows UI — это не один API и не одна правильная техника.UIAutomation даёт красивую модель элементов и паттернов. Win32 даёт доступ к старым и не очень дружелюбным интерфейсам. SendKeys и глобальные клики остаются запасным выходом. А поверх всего этого нужен нормальный слой дескрипторов, чтобы пользователь мог сохранить элемент один раз и потом находить его не по координате, а по набору устойчивых признаков.

Если бы я формулировал практическое правило, оно было бы таким: не начинайте с клика. Начинайте с вопроса “как я найду этот элемент в следующий раз?”. Клик — это уже последняя, самая простая часть.