Настраиваемые одноранговые классы автоматизации

Описывает концепцию одноранговых узлов автоматизации для Microsoft модель автоматизации пользовательского интерфейса и способов предоставления поддержки автоматизации для собственного пользовательского класса пользовательского интерфейса.

модель автоматизации пользовательского интерфейса предоставляет платформу, которую клиенты автоматизации могут использовать для изучения или эксплуатации пользовательских интерфейсов различных платформ и платформ пользовательского интерфейса. Если вы пишете приложение Для Windows, классы, используемые для пользовательского интерфейса, уже предоставляют поддержку модель автоматизации пользовательского интерфейса. Вы можете наследовать существующие непечатанные классы, чтобы определить новый тип элемента управления пользовательского интерфейса или класса поддержки. В процессе этого класс может добавить поведение, которое должно иметь поддержку специальных возможностей, но что модель автоматизации пользовательского интерфейса поддержки по умолчанию не охватывает. В этом случае следует расширить существующую поддержку модель автоматизации пользовательского интерфейса путем получения от класса AutomationPeer, используемого базовой реализацией, добавления любой необходимой поддержки в одноранговую реализацию и информирования инфраструктуры управления приложениями Windows о том, что он должен создать новый одноранговый узел.

модель автоматизации пользовательского интерфейса включает не только приложения специальных возможностей и вспомогательные технологии, такие как средства чтения с экрана, но и код проверки качества (тест). В любом сценарии модель автоматизации пользовательского интерфейса клиенты могут проверять элементы пользовательского интерфейса и имитировать взаимодействие пользователя с приложением из другого кода за пределами приложения. Сведения о модель автоматизации пользовательского интерфейса на всех платформах и в более широком смысле см. в модель автоматизации пользовательского интерфейса обзоре.

Существует две отдельные аудитории, использующие платформу модель автоматизации пользовательского интерфейса.

• модель автоматизации пользовательского интерфейса клиенты вызывают API-интерфейсы модель автоматизации пользовательского интерфейса, чтобы узнать обо всем пользовательском интерфейсе, который в настоящее время отображается пользователю. Например, вспомогательные технологии, такие как средство чтения с экрана, выступает в качестве клиента модель автоматизации пользовательского интерфейса. Пользовательский интерфейс представлен в виде дерева связанных элементов автоматизации. Клиент модель автоматизации пользовательского интерфейса может быть заинтересован только в одном приложении за раз или в целом дереве. Клиент модель автоматизации пользовательского интерфейса может использовать модель автоматизации пользовательского интерфейса API для перемещения по дереву и чтения или изменения информации в элементах автоматизации.
• модель автоматизации пользовательского интерфейса поставщики вносят информацию в дерево модель автоматизации пользовательского интерфейса, реализуя API, предоставляющие элементы в пользовательском интерфейсе, которые они представили в рамках своего приложения. При создании нового элемента управления теперь следует выступать в качестве участника сценария поставщика модель автоматизации пользовательского интерфейса. В качестве поставщика необходимо убедиться, что все клиенты модель автоматизации пользовательского интерфейса могут использовать платформу модель автоматизации пользовательского интерфейса для взаимодействия с вашим элементом управления как для специальных возможностей, так и для тестирования.

Как правило, в платформе модель автоматизации пользовательского интерфейса есть параллельные API: один API для клиентов модель автоматизации пользовательского интерфейса и другой, аналогичный именованному API для поставщики модель автоматизации пользовательского интерфейса. В большинстве случаев в этом разделе рассматриваются API для поставщика модель автоматизации пользовательского интерфейса, а также классы и интерфейсы, обеспечивающие расширяемость поставщика в этой платформе пользовательского интерфейса. Иногда мы упоминаем модель автоматизации пользовательского интерфейса API, которые используются клиентами модель автоматизации пользовательского интерфейса, для предоставления некоторой перспективы или предоставления таблицы подстановки, которая сопоставляет API клиента и поставщика. Дополнительные сведения о перспективах клиента см. в руководстве модель автоматизации пользовательского интерфейса программиста клиента.

Примечание.

модель автоматизации пользовательского интерфейса клиенты обычно не используют управляемый код и обычно не реализуются как приложение UWP (обычно это классические приложения). модель автоматизации пользовательского интерфейса основан на стандарте, а не на конкретной реализации или платформе. Многие существующие клиенты модель автоматизации пользовательского интерфейса, в том числе вспомогательные технологии, такие как средства чтения с экрана, используют интерфейсы com для взаимодействия с модель автоматизации пользовательского интерфейса, системой и приложениями, работающими в дочерних окнах. Дополнительные сведения о com-интерфейсах и способах записи клиента модель автоматизации пользовательского интерфейса с помощью COM см. в разделе модель автоматизации пользовательского интерфейса Основы.

Определение существующего состояния модель автоматизации пользовательского интерфейса поддержки пользовательского класса пользовательского интерфейса

Прежде чем пытаться реализовать одноранговый узел автоматизации для пользовательского элемента управления, необходимо проверить, предоставляется ли базовый класс и его одноранговый узел автоматизации уже предоставляет необходимую поддержку специальных возможностей или автоматизации. Во многих случаях сочетание реализаций FrameworkElementAutomationPeer , конкретных одноранговых узлов и шаблонов, которые они реализуют, могут обеспечить базовый, но удовлетворительный интерфейс специальных возможностей. Правильно ли это зависит от количества изменений, внесенных в объектную модель, для элемента управления и базового класса. Кроме того, это зависит от того, сопоставляются ли ваши дополнения к функциям базового класса с новыми элементами пользовательского интерфейса в контракте шаблона или внешним видом элемента управления. В некоторых случаях изменения могут привести к новым аспектам взаимодействия с пользователем, требующим дополнительной поддержки специальных возможностей.

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

Классы одноранговых узлов автоматизации

UWP основывается на существующих методах и соглашениях модель автоматизации пользовательского интерфейса, используемых предыдущими платформами пользовательского интерфейса управляемого кода, такими как Windows Forms, Windows Presentation Foundation (WPF) и Microsoft Silverlight. Многие классы элементов управления и их функции и назначение также имеют свое происхождение в предыдущей платформе пользовательского интерфейса.

В соответствии с соглашением имена одноранговых классов начинаются с имени класса элемента управления, к которому добавляется строка "AutomationPeer". Например, ButtonAutomationPeer — это одноранговый класс для класса элемента управления Button.

Примечание.

В этой статье мы рассмотрим свойства, связанные с специальными возможностями, как более важные при реализации однорангового узла управления. Но для более общей концепции поддержки модель автоматизации пользовательского интерфейса следует реализовать одноранговый узел в соответствии с рекомендациями, описанными в руководстве программиста модель автоматизации пользовательского интерфейса поставщика и модель автоматизации пользовательского интерфейса основы. Эти разделы не охватывают определенные API AutomationPeer, которые вы будете использовать для предоставления сведений в платформе UWP для модель автоматизации пользовательского интерфейса, но они описывают свойства, которые определяют класс или предоставляют другие сведения или взаимодействие.

Одноранговые элементы, шаблоны и типы элементов управления

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

Шаблоны элементов управления позволяют классифицировать и предоставлять функции элемента управления независимо от типа или внешнего вида элемента управления. Например, элемент управления, представляющий табличный интерфейс, использует шаблон элемента управления Grid для предоставления количества строк и столбцов в таблице, а также для включения модель автоматизации пользовательского интерфейса клиента для получения элементов из таблицы. Как и в других примерах, клиент модель автоматизации пользовательского интерфейса может использовать шаблон элемента управления Invoke для элементов управления, которые можно вызвать, такие как кнопки, и шаблон элемента управления Scroll для элементов управления с полосами прокрутки, такими как поля списка, представления списка или поля со списком. Каждый шаблон элемента управления представляет отдельный тип функциональных возможностей, а шаблоны элементов управления можно объединить, чтобы описать полный набор функций, поддерживаемых определенным элементом управления.

Шаблоны элементов управления относятся к пользовательскому интерфейсу, так как интерфейсы связаны с COM-объектами. В COM можно запросить объект, чтобы узнать, какие интерфейсы она поддерживает, а затем использовать эти интерфейсы для доступа к функциям. В модель автоматизации пользовательского интерфейса клиенты модель автоматизации пользовательского интерфейса могут запрашивать модель автоматизации пользовательского интерфейса элемент, чтобы узнать, какие шаблоны элементов управления она поддерживает, а затем взаимодействовать с элементом и его одноранговым элементом управления с помощью свойств, методов, событий и структур, предоставляемых поддерживаемыми шаблонами элементов управления.

Одним из основных целей однорангового узла автоматизации является отправка отчета клиенту модель автоматизации пользовательского интерфейса, который управляет шаблонами элемента пользовательского интерфейса, который может поддерживать его одноранговый узел. Для этого модель автоматизации пользовательского интерфейса поставщики реализуют новые одноранговые узлы, которые изменяют поведение метода GetPattern, переопределяя метод GetPatternCore. модель автоматизации пользовательского интерфейса клиенты вызывают вызовы, которые поставщик модель автоматизации пользовательского интерфейса сопоставляет с вызовом GetPattern. модель автоматизации пользовательского интерфейса клиенты запрашивают каждый конкретный шаблон, с которыми они хотят взаимодействовать. Если одноранговый узел поддерживает шаблон, он возвращает ссылку на объект. в противном случае возвращает значение NULL. Если возвращаемое значение не равно NULL, клиент модель автоматизации пользовательского интерфейса ожидает, что он может вызывать API-интерфейсы интерфейса шаблона в качестве клиента, чтобы взаимодействовать с этим шаблоном управления.

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

• модель автоматизации пользовательского интерфейса шаблонов элементов управления: тип элемента управления может поддерживать несколько шаблонов, каждый из которых представляет другую классификацию сведений или взаимодействия. Каждый тип элемента управления имеет набор шаблонов элементов управления, которые элемент управления должен поддерживать, набор, который является необязательным, и набор, который элемент управления не должен поддерживать.
• модель автоматизации пользовательского интерфейса значения свойств: каждый тип элемента управления имеет набор свойств, которые элемент управления должен поддерживать. Это общие свойства, как описано в модель автоматизации пользовательского интерфейса Обзор свойств, а не те, которые относятся к шаблону.
• модель автоматизации пользовательского интерфейса события: каждый тип элемента управления имеет набор событий, которые элемент управления должен поддерживать. Опять же, они являются общими, а не шаблонными, как описано в модель автоматизации пользовательского интерфейса обзоре событий.
• модель автоматизации пользовательского интерфейса структура дерева: каждый тип элемента управления определяет, как элемент управления должен отображаться в структуре дерева модель автоматизации пользовательского интерфейса.

Независимо от того, как реализованы пиринги автоматизации для платформы, модель автоматизации пользовательского интерфейса клиентские функции не привязаны к UWP, и на самом деле, вероятно, что существующие модель автоматизации пользовательского интерфейса клиенты, такие как вспомогательные технологии, будут использовать другие модели программирования. например COM. В COM клиенты могут запрашивать ЗапросInterface для интерфейса шаблона управления COM, реализующего запрошенный шаблон или общую платформу модель автоматизации пользовательского интерфейса для свойств, событий или проверки дерева. Для шаблонов модель автоматизации пользовательского интерфейса платформы маршалирует код интерфейса в код UWP, выполняемый для поставщика модель автоматизации пользовательского интерфейса приложения и соответствующего однорангового узла.

При реализации шаблонов элементов управления для платформы управляемого кода, например приложения UWP с помощью C# или Microsoft Visual Basic, можно использовать интерфейсы платформа .NET Framework для представления этих шаблонов вместо использования представления интерфейса COM. Например, интерфейс шаблона модель автоматизации пользовательского интерфейса для реализации поставщика Microsoft .NET для шаблона Invoke — IInvokeProvider.

Список шаблонов элементов управления, интерфейсов поставщиков и их назначения см. в разделе "Шаблоны элементов управления" и "Интерфейсы". Список типов элементов управления см. в разделе модель автоматизации пользовательского интерфейса Обзор типов элементов управления.

Руководство по реализации шаблонов элементов управления

Шаблоны элементов управления и то, что они предназначены для них, являются частью более крупного определения платформы модель автоматизации пользовательского интерфейса и не просто применяются к поддержке специальных возможностей для приложения UWP. При реализации шаблона элемента управления необходимо убедиться, что вы реализуете его таким образом, чтобы оно соответствовало рекомендациям, как описано в этих документах, а также в спецификации модель автоматизации пользовательского интерфейса. Если вы ищете рекомендации, вы можете использовать документацию Майкрософт и не нужно ссылаться на спецификацию. Руководство по каждому шаблону описано здесь: реализация шаблонов элементов управления модель автоматизации пользовательского интерфейса. Вы заметите, что каждый раздел в этой области содержит раздел "Рекомендации по реализации и соглашения" и раздел "Обязательные члены". Руководство обычно относится к определенным API соответствующего интерфейса шаблона элемента управления в справочнике по интерфейсам шаблонов элементов управления для поставщиков . Эти интерфейсы — это собственные или COM-интерфейсы (и их API используют синтаксис стиля COM). Но все, что вы видите, имеет эквивалент в пространстве имен Windows.UI.Xaml.Automation.Provider.

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

Тем не менее вам может потребоваться дополнительное руководство по шаблонам элементов управления или типам элементов управления, чтобы следовать модель автоматизации пользовательского интерфейса рекомендациям в реализации одноранговых узлов. Это особенно верно, если вы реализуете шаблоны или типы элементов управления, которые еще не существуют в качестве реализации по умолчанию в элементе управления UWP. Например, шаблон для заметок не реализован ни в одном из элементов управления XAML по умолчанию. Но у вас может быть приложение, использующее заметки широко и поэтому вы хотите использовать эту функциональность, чтобы быть доступными. В этом сценарии одноранговый узел должен реализовать IAnnotationProvider и, вероятно, должен сообщать себя как тип элемента управления Document с соответствующими свойствами, чтобы указать, что ваши документы поддерживают заметку.

Рекомендуется использовать рекомендации, которые вы видите для шаблонов в разделе "Реализация шаблонов элементов управления модель автоматизации пользовательского интерфейса" или типов элементов управления в разделе "Вспомогательные типы элементов управления модель автоматизации пользовательского интерфейса" в качестве ориентации и общих рекомендаций. Вы даже можете попробовать выполнить некоторые ссылки API для описания и примечания по назначению API. Но для синтаксиса, необходимых для программирования приложений UWP, найдите эквивалентный API в пространстве имен Windows.UI.Xaml.Automation.Provider и используйте эти справочные страницы для получения дополнительных сведений.

Встроенные классы одноранговых узлов автоматизации

Как правило, элементы реализуют одноранговый класс автоматизации, если они принимают действия пользовательского интерфейса от пользователя или содержат сведения, необходимые пользователям вспомогательных технологий, представляющих интерактивный или значимый пользовательский интерфейс приложений. Не все визуальные элементы UWP имеют одноранговые узлы автоматизации. Примерами классов, реализующих одноранговые узлы автоматизации, являются Button и TextBox. Примеры классов, которые не реализуют одноранговые узлы автоматизации, — border and classes based Panel, например Grid и Canvas. Панель не имеет однорангового узла, так как она предоставляет только визуальное поведение макета. Пользователь не может взаимодействовать с панелью с помощью специальных возможностей. Независимо от того, какие дочерние элементы содержит панель, вместо этого сообщается, что модель автоматизации пользовательского интерфейса деревья в качестве дочерних элементов следующего доступного родительского элемента в дереве с одноранговым или элементным представлением.

границы процессов модель автоматизации пользовательского интерфейса и UWP

Как правило, модель автоматизации пользовательского интерфейса клиентский код, который обращается к приложению UWP, выполняется вне процесса. Инфраструктура платформы модель автоматизации пользовательского интерфейса позволяет получить информацию по границе процесса. Эта концепция более подробно описана в модель автоматизации пользовательского интерфейса основах.

OnCreateAutomationPeer

Все классы, производные от UIElement, содержат защищенный виртуальный метод OnCreateAutomationPeer. Последовательность инициализации объектов для одноранговых узлов автоматизации вызывает OnCreateAutomationPeer, чтобы получить одноранговый объект службы автоматизации для каждого элемента управления и таким образом создать дерево модель автоматизации пользовательского интерфейса для использования во время выполнения. модель автоматизации пользовательского интерфейса код может использовать одноранговый узел для получения сведений о характеристиках и функциях элемента управления, а также для имитации интерактивного использования с помощью шаблонов элементов управления. Настраиваемый элемент управления, поддерживающий автоматизацию, должен переопределить OnCreateAutomationPeer и вернуть экземпляр класса, наследуемого от AutomationPeer. Например, если пользовательский элемент управления является производным от класса ButtonBase, объект, возвращаемый OnCreateAutomationPeer, должен быть производным от ButtonBaseAutomationPeer.

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

Например, следующий код объявляет, что пользовательский элемент управления NumericUpDown должен использовать одноранговый узел NumericUpDownPeer для модель автоматизации пользовательского интерфейса целей.

using Windows.UI.Xaml.Automation.Peers;
...
public class NumericUpDown : RangeBase {
    public NumericUpDown() {
    // other initialization; DefaultStyleKey etc.
    }
    ...
    protected override AutomationPeer OnCreateAutomationPeer()
    {
        return new NumericUpDownAutomationPeer(this);
    }
}

Public Class NumericUpDown
    Inherits RangeBase
    ' other initialization; DefaultStyleKey etc.
       Public Sub New()
       End Sub
       Protected Overrides Function OnCreateAutomationPeer() As AutomationPeer
              Return New NumericUpDownAutomationPeer(Me)
       End Function
End Class

// NumericUpDown.idl
namespace MyNamespace
{
    runtimeclass NumericUpDown : Windows.UI.Xaml.Controls.Primitives.RangeBase
    {
        NumericUpDown();
        Int32 MyProperty;
    }
}

// NumericUpDown.h
...
struct NumericUpDown : NumericUpDownT<NumericUpDown>
{
	...
    Windows::UI::Xaml::Automation::Peers::AutomationPeer OnCreateAutomationPeer()
    {
        return winrt::make<MyNamespace::implementation::NumericUpDownAutomationPeer>(*this);
    }
};

//.h
public ref class NumericUpDown sealed : Windows::UI::Xaml::Controls::Primitives::RangeBase
{
// other initialization not shown
protected:
    virtual AutomationPeer^ OnCreateAutomationPeer() override
    {
         return ref new NumericUpDownAutomationPeer(this);
    }
};

Примечание.

Реализация OnCreateAutomationPeer не должна делать ничего больше, чем инициализировать новый экземпляр пользовательского однорангового узла автоматизации, передав элемент управления вызовом в качестве владельца и возвращая этот экземпляр. Не пытайтесь выполнить дополнительную логику в этом методе. В частности, любая логика, которая может привести к уничтожению AutomationPeer в одном вызове, может привести к неожиданному поведению среды выполнения.

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

Фактическое определение однорангового класса можно сделать в том же файле кода, что и элемент управления или в отдельном файле кода. Все определения одноранговых узлов существуют в пространстве имен Windows.UI.Xaml.Automation.Peers , которое является отдельным пространством имен из элементов управления, для которых они предоставляют одноранговые узлы. Вы также можете объявить одноранговые узлы в отдельных пространствах имен, если вы ссылаетесь на необходимые пространства имен для вызова метода OnCreateAutomationPeer.

Выбор правильного базового класса однорангового узла

Убедитесь, что служба AutomationPeer является производным от базового класса, который обеспечивает оптимальное соответствие существующей логике однорангового класса, отследимого от него. В предыдущем примере, так как NumericUpDown он является производным от RangeBase, существует класс RangeBaseAutomationPeer, на который следует опираться. Используя ближайший соответствующий одноранговый класс параллельно с производным элементом управления, можно избежать переопределения по крайней мере некоторых функций IRangeValueProvider , так как базовый одноранговый класс уже реализует его.

Базовый класс Control не имеет соответствующего однорангового класса. Если требуется одноранговый класс для соответствия пользовательскому элементу управления, наследуемому из Control, наследуется пользовательский одноранговый класс из FrameworkElementAutomationPeer.

Если вы наследуется от ContentControl напрямую, этот класс не имеет поведения однорангового узла автоматизации по умолчанию, так как отсутствует реализация OnCreateAutomationPeer, которая ссылается на одноранговый класс. Поэтому не забудьте реализовать OnCreateAutomationPeer для использования собственного однорангового узла или использовать FrameworkElementAutomationPeer в качестве однорангового узла, если этот уровень поддержки специальных возможностей подходит для вашего элемента управления.

Примечание.

Обычно вы не наследуете от AutomationPeer, а не FrameworkElementAutomationPeer. Если вы сделали производный напрямую от AutomationPeer , вам потребуется дублировать много базовой поддержки специальных возможностей, которая в противном случае будет поступать из FrameworkElementAutomationPeer.

Инициализация пользовательского однорангового класса

Одноранговый узел автоматизации должен определить типобезопасный конструктор, использующий экземпляр элемента управления владельца для инициализации базы. В следующем примере реализация передает значение владельца в базу RangeBaseAutomationPeer, а в конечном итоге — FrameworkElementAutomationPeer, которая фактически использует владельца для задания FrameworkElementAutomationPeer.Owner.

public NumericUpDownAutomationPeer(NumericUpDown owner): base(owner)
{}

Public Sub New(owner As NumericUpDown)
    MyBase.New(owner)
End Sub

// NumericUpDownAutomationPeer.idl
import "NumericUpDown.idl";
namespace MyNamespace
{
    runtimeclass NumericUpDownAutomationPeer : Windows.UI.Xaml.Automation.Peers.AutomationPeer
    {
        NumericUpDownAutomationPeer(NumericUpDown owner);
        Int32 MyProperty;
    }
}

// NumericUpDownAutomationPeer.h
...
struct NumericUpDownAutomationPeer : NumericUpDownAutomationPeerT<NumericUpDownAutomationPeer>
{
    ...
    NumericUpDownAutomationPeer(MyNamespace::NumericUpDown const& owner);
};

//.h
public ref class NumericUpDownAutomationPeer sealed :  Windows::UI::Xaml::Automation::Peers::RangeBaseAutomationPeer
//.cpp
public:    NumericUpDownAutomationPeer(NumericUpDown^ owner);

Основные методы AutomationPeer

По причинам инфраструктуры UWP переопределяемые методы однорангового узла автоматизации являются частью пары методов: общедоступный метод доступа, который поставщик модель автоматизации пользовательского интерфейса использует в качестве точки пересылки для модель автоматизации пользовательского интерфейса клиенты и защищенный метод настройки Core, которые класс UWP может переопределить, чтобы повлиять на поведение. Пара методов подключена по умолчанию таким образом, что вызов метода доступа всегда вызывает параллельный метод Core, который имеет реализацию поставщика или в качестве резервной версии, вызывает реализацию по умолчанию из базовых классов.

При реализации однорангового узла для пользовательского элемента управления переопределите любой из методов Core из базового класса однорангового узла автоматизации, где требуется предоставить поведение, уникальное для пользовательского элемента управления. модель автоматизации пользовательского интерфейса код получает сведения о вашем элементе управления путем вызова общедоступных методов однорангового класса. Чтобы предоставить сведения о вашем элементе управления, переопределите каждый метод именем, который заканчивается на "Core", когда реализация элемента управления и проектирование создают сценарии специальных возможностей или другие сценарии модель автоматизации пользовательского интерфейса, которые отличаются от того, что поддерживается базовым классом однорангового узла автоматизации.

По крайней мере при определении нового однорангового класса реализуйте метод GetClassNameCore , как показано в следующем примере.

protected override string GetClassNameCore()
{
    return "NumericUpDown";
}

Примечание.

Может потребоваться сохранить строки как константы, а не непосредственно в тексте метода, но это касается вас. Для GetClassNameCore не потребуется локализовать эту строку. Свойство LocalizedControlType используется в любой момент, когда локализованная строка требуется клиенту модель автоматизации пользовательского интерфейса, а не ClassName.

GetAutomationControlType

Некоторые вспомогательные технологии используют значение GetAutomationControlType непосредственно при составлении отчетов о характеристиках элементов в дереве модель автоматизации пользовательского интерфейса в качестве дополнительных сведений за пределами имени модель автоматизации пользовательского интерфейса. Если элемент управления значительно отличается от элемента управления, производный от него, и вы хотите сообщить о другом типе элемента управления, который сообщается базовым одноранговым классом, используемым элементом управления, необходимо реализовать одноранговый узел и переопределить GetAutomationControlTypeCore в реализации однорангового узла. Это особенно важно, если вы наследуется от обобщенного базового класса, например ItemsControl или ContentControl, где базовый одноранговый узел не предоставляет точные сведения о типе элемента управления.

Реализация GetAutomationControlTypeCore описывает элемент управления, возвращая значение AutomationControlType. Хотя вы можете вернуть AutomationControlType.Custom, вы должны вернуть один из более конкретных типов элементов управления, если он точно описывает основные сценарии элемента управления. Рассмотрим пример.

protected override AutomationControlType GetAutomationControlTypeCore()
{
    return AutomationControlType.Spinner;
}

Примечание.

Если вы не укажете AutomationControlType.Custom, вам не нужно реализовать GetLocalizedControlTypeCore для предоставления значения свойства LocalizedControlType клиентам. модель автоматизации пользовательского интерфейса общая инфраструктура предоставляет переведенные строки для всех возможных Значение AutomationControlType, отличное от AutomationControlType.Custom.

GetPattern и GetPatternCore

Реализация GetPatternCore однорангового узла возвращает объект, поддерживающий шаблон, запрошенный в входном параметре. В частности, клиент модель автоматизации пользовательского интерфейса вызывает метод, переадресованный методу GetPattern поставщика, и задает значение перечисления PatternInterface, которое называет запрошенный шаблон. Переопределение GetPatternCore должно возвращать объект, реализующий указанный шаблон. Этот объект сам является одноранговым, так как одноранговый узел должен реализовать соответствующий интерфейс шаблона в любое время, когда он сообщает, что он поддерживает шаблон. Если у вашего однорангового узла нет пользовательской реализации шаблона, но вы знаете, что база однорангового узла реализует шаблон, можно вызвать реализацию Базового типа GetPatternCore из GetPatternCore. GetPatternCore однорангового узла должен возвращать значение NULL, если шаблон не поддерживается одноранговым элементом. Однако вместо возврата null непосредственно из реализации обычно следует полагаться на вызов базовой реализации, чтобы вернуть значение NULL для любого неподдерживаемого шаблона.

Если шаблон поддерживается, реализация GetPatternCore может вернуть это или Me. Ожидается, что клиент модель автоматизации пользовательского интерфейса приведет возвращаемое значение GetPattern в запрошенный интерфейс шаблона всякий раз, когда он не имеет значения NULL.

Если одноранговый класс наследует от другого однорангового узла, и все необходимые отчеты о поддержке и шаблоне уже обрабатываются базовым классом, реализация GetPatternCore не требуется. Например, если вы реализуете элемент управления диапазоном, производный от RangeBase, и одноранговый узел является производным от RangeBaseAutomationPeer, этот одноранг возвращается для PatternInterface.RangeValue и имеет рабочие реализации интерфейса IRangeValueProvider, поддерживающего шаблон.

Хотя это не литеральный код, этот пример приблизит реализацию GetPatternCore уже присутствует в RangeBaseAutomationPeer.

protected override object GetPatternCore(PatternInterface patternInterface)
{
    if (patternInterface == PatternInterface.RangeValue)
    {
        return this;
    }
    return base.GetPatternCore(patternInterface);
}

Если вы реализуете одноранговый узел, где у вас нет всей поддержки, необходимой из базового однорангового класса, или вы хотите изменить или добавить в набор базовых наследуемых шаблонов, которые может поддерживать ваш одноранговый узел, необходимо переопределить GetPatternCore, чтобы разрешить клиентам модель автоматизации пользовательского интерфейса использовать шаблоны.

Список шаблонов поставщика, доступных в реализации модель автоматизации пользовательского интерфейса поддержки UWP, см. в разделе Windows.UI.Xaml.Automation.Provider. Каждый такой шаблон имеет соответствующее значение перечисления PatternInterface, которое заключается в том, как модель автоматизации пользовательского интерфейса клиенты запрашивают шаблон в вызове GetPattern.

Одноранговый узел может сообщать о том, что он поддерживает несколько шаблонов. В этом случае переопределение должно включать логику возвращаемого пути для каждого поддерживаемого значения PatternInterface и возвращать одноранговый узел в каждом случае сопоставления. Ожидается, что вызывающий объект запрашивает только один интерфейс за раз, и вызывающий объект будет выполнять приведение к ожидаемому интерфейсу.

Ниже приведен пример переопределения GetPatternCore для пользовательского однорангового узла. Он сообщает о поддержке двух шаблонов, IRangeValueProvider и IToggleProvider. Здесь представлен элемент управления мультимедиа, который может отображаться как полноэкранный (режим переключения) и имеет индикатор хода выполнения, в котором пользователи могут выбрать позицию (элемент управления диапазоном). Этот код был получен из примера специальных возможностей XAML.

protected override object GetPatternCore(PatternInterface patternInterface)
{
    if (patternInterface == PatternInterface.RangeValue)
    {
        return this;
    }
    else if (patternInterface == PatternInterface.Toggle)
    {
        return this;
    }
    return null;
}

Переадресация шаблонов из вложенных элементов

Реализация метода GetPatternCore также может указывать вложенный элемент или часть в качестве поставщика шаблонов для своего узла. В этом примере показано, как ItemsControl передает обработку шаблонов прокрутки в одноранговый узел внутреннего элемента управления ScrollViewer. Чтобы указать вложенный элемент для обработки шаблонов, этот код получает объект подэлемента, создает одноранговый элемент для подэлемента с помощью метода FrameworkElementAutomationPeer.CreatePeerForElement и возвращает новый одноранговый узел.

protected override object GetPatternCore(PatternInterface patternInterface)
{
    if (patternInterface == PatternInterface.Scroll)
    {
        ItemsControl owner = (ItemsControl) base.Owner;
        UIElement itemsHost = owner.ItemsHost;
        ScrollViewer element = null;
        while (itemsHost != owner)
        {
            itemsHost = VisualTreeHelper.GetParent(itemsHost) as UIElement;
            element = itemsHost as ScrollViewer;
            if (element != null)
            {
                break;
            }
        }
        if (element != null)
        {
            AutomationPeer peer = FrameworkElementAutomationPeer.CreatePeerForElement(element);
            if ((peer != null) && (peer is IScrollProvider))
            {
                return (IScrollProvider) peer;
            }
        }
    }
    return base.GetPatternCore(patternInterface);
}

Другие основные методы

Возможно, элемент управления должен поддерживать эквиваленты клавиатуры для основных сценариев; Дополнительные сведения о том, почему это может потребоваться, см. в статье "Специальные возможности клавиатуры". Реализация поддержки ключей обязательно является частью кода элемента управления, а не одноранговым кодом, так как это является частью логики элемента управления, но одноранговый класс должен переопределить методы GetAcceleratorKeyCore и GetAccessKeyCore, чтобы сообщить модель автоматизации пользовательского интерфейса клиентам, какие ключи используются. Учитывайте, что строки, которые содержат сведения о ключе отчета, могут быть локализованы и поэтому должны поступать из ресурсов, а не жестко закодированных строк.

Если вы предоставляете одноранговый узел для класса, поддерживающего коллекцию, лучше всего наследоваться как от функциональных классов, так и от одноранговых классов, которые уже поддерживают эту коллекцию. Если этого не удается сделать, одноранговые узлы для элементов управления, которые поддерживают дочерние коллекции, может потребоваться переопределить одноранговый метод GetChildrenCore, чтобы правильно сообщить об отношениях родительского-дочернего объекта в дерево модель автоматизации пользовательского интерфейса.

Реализуйте методы IsContentElementCore и IsControlElementCore, чтобы указать, содержит ли элемент управления содержимое данных или выполняет интерактивную роль в пользовательском интерфейсе (или оба). По умолчанию оба метода возвращают значение true. Эти параметры повышают удобство использования вспомогательных технологий, таких как средства чтения с экрана, которые могут использовать эти методы для фильтрации дерева автоматизации. Если метод GetPatternCore передает обработку шаблонов в одноранговый узел подэлемента, метод IsControlElementCore подэлемента может вернуть значение false, чтобы скрыть одноранговый элемент подэлемента из дерева автоматизации.

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

GetBoundingRectangleCore и GetClickablePointCore используются главным образом для сценариев автоматического тестирования. Если вы хотите поддерживать автоматическое тестирование для элемента управления, может потребоваться переопределить эти методы. Это может потребоваться для элементов управления типами диапазона, где вы не можете предложить только одну точку, так как пользователь щелкает в пространстве координат другого влияния на диапазон. Например, одноранговый узел автоматизации ScrollBar по умолчанию переопределяет GetClickablePointCore, чтобы вернуть значение точки "не число".

GetLiveSettingCore влияет на значение элемента управления LiveSetting по умолчанию для модель автоматизации пользовательского интерфейса. Это может потребоваться переопределить, если вы хотите, чтобы элемент управления возвращал значение, отличное от AutomationLiveSetting.Off. Дополнительные сведения о том, что представляет LiveSetting, см. в разделе AutomationProperties.LiveSetting.

Вы можете переопределить GetOrientationCore, если элемент управления имеет свойство ориентации settable, которое может сопоставить с AutomationOrientation. Это делают классы ScrollBarAutomationPeer и SliderAutomationPeer.

Базовая реализация в FrameworkElementAutomationPeer

Базовая реализация FrameworkElementAutomationPeer предоставляет некоторые модель автоматизации пользовательского интерфейса сведения, которые можно интерпретировать из различных свойств макета и поведения, определенных на уровне платформы.

• GetBoundingRectangleCore: возвращает структуру Rect на основе известных характеристик макета. Возвращает 0-значение Rect, если IsOffscreen имеет значение true.
• GetClickablePointCore: возвращает структуру точки на основе известных характеристик макета, если существует ненулевое значение BoundingRectangle.
• GetNameCore: более обширное поведение, чем можно свести здесь; см. статью GetNameCore. В основном он пытается преобразовать строку в любое известное содержимое ContentControl или связанных классов с содержимым. Кроме того, если для LabeledBy есть значение, значение имени этого элемента используется в качестве имени.
• HasKeyboardFocusCore: вычисляется на основе свойств FocusState владельца и IsEnabled. Элементы, которые не являются элементами управления, всегда возвращают значение false.
• IsEnabledCore: вычисляется на основе свойства IsEnabled владельца, если это элемент управления. Элементы, которые не являются элементами управления, всегда возвращают значение true. Это не означает, что владелец включен в обычном смысле взаимодействия; Это означает, что одноранговый узел включен, несмотря на то, что владелец не имеет свойства IsEnabled .
• IsKeyboardFocusableCore: возвращает значение true, если владелец является элементом управления; в противном случае — значение false.
• IsOffscreenCore: Видимость свернутого элемента владельца или любого из его родителей приравнивается к истинному значению IsOffscreen. Исключение: объект Всплывающего окна может быть видимым, даже если родители его владельца не являются.
• SetFocusCore: вызовы фокуса.
• GetParent: Вызывает FrameworkElement.Parent от владельца и ищет соответствующий одноранговый узел. Это не переопределение пары с методом Core, поэтому вы не можете изменить это поведение.

Примечание.

Одноранговые узлы UWP по умолчанию реализуют поведение с помощью внутреннего машинного кода, реализующего UWP, не обязательно используя фактический код UWP. Вы не сможете увидеть код или логику реализации с помощью отражения среды CLR или других методов. Кроме того, вы не увидите отдельные справочные страницы для переопределения подклассов базового однорангового поведения. Например, может быть дополнительное поведение для GetNameCore элемента TextBoxAutomationPeer, которое не будет описано на странице ссылок AutomationPeer.GetNameCore, и нет ссылочной страницы для TextBoxAutomationPeer.GetNameCore. Нет даже страницы ссылок TextBoxAutomationPeer.GetNameCore . Вместо этого ознакомьтесь со справочным разделом для наиболее немедленного однорангового класса и найдите заметки о реализации в разделе "Примечания".

Пиринги и AutomationProperties

Одноранговый узел автоматизации должен предоставлять соответствующие значения по умолчанию для сведений о специальных возможностях элемента управления. Обратите внимание, что любой код приложения, использующий элемент управления, может переопределить некоторые из этих действий, включив значения присоединенного свойства AutomationProperties в экземплярах элементов управления. Вызывающие элементы могут сделать это либо для элементов управления по умолчанию, либо для пользовательских элементов управления. Например, следующий КОД XAML создает кнопку с двумя настраиваемыми свойствами модель автоматизации пользовательского интерфейса:<Button AutomationProperties.Name="Special" AutomationProperties.HelpText="This is a special button."/>

Дополнительные сведения о присоединенных свойствах AutomationProperties см. в разделе "Основные сведения о специальных возможностях".

Некоторые методы AutomationPeer существуют из-за общего контракта того, как поставщики модель автоматизации пользовательского интерфейса должны сообщать сведения, но эти методы обычно не реализуются в одноранговых элементах управления. Это связано с тем, что эта информация должна предоставляться значениями AutomationProperties , применяемыми к коду приложения, который использует элементы управления в определенном пользовательском интерфейсе. Например, большинство приложений определяют связь меток между двумя разными элементами управления в пользовательском интерфейсе, применяя значение AutomationProperties.LabeledBy . Однако LabeledByCore реализуется в определенных одноранговых узлах, представляющих связи данных или элементов в элементе управления, например использование части заголовка для маркировки части поля данных, маркировки элементов с контейнерами или аналогичных сценариев.

Реализация шаблонов

Давайте рассмотрим, как написать одноранговый узел для элемента управления, реализующего поведение разворачивания, реализуя интерфейс шаблона элемента управления для развертывания и свертывание. Одноранговый узел должен включить специальные возможности для поведения развертывания, возвращая себя при вызове GetPattern со значением PatternInterface.ExpandCollapse. Затем одноранговый узел должен наследовать интерфейс поставщика для этого шаблона (IExpandCollapseProvider) и предоставлять реализации для каждого члена этого интерфейса поставщика. В этом случае интерфейс имеет три члена для переопределения: Развернуть, Свернуть, Развернуть, РазвернутьCollapseState.

Рекомендуется заранее спланировать специальные возможности в проектировании API самого класса. Если у вас есть поведение, которое потенциально запрашивается либо в результате типичных взаимодействий с пользователем, работающим в пользовательском интерфейсе, либо с помощью шаблона поставщика автоматизации, укажите один метод, который может вызывать ответ пользовательского интерфейса или шаблон автоматизации. Например, если в элементе управления есть части кнопки с проводными обработчиками событий, которые могут развернуть или свернуть элемент управления и имеют эквиваленты клавиатуры для этих действий, то эти обработчики событий вызывают тот же метод, который вызывается из текста реализации expand или collapse для IExpandCollapseProvider в одноранговом узле. Использование общего метода логики также может быть полезным способом, чтобы убедиться, что визуальные состояния элемента управления обновляются для отображения логического состояния в единообразном режиме независимо от способа вызова поведения.

Типичная реализация заключается в том, что API-интерфейсы поставщика сначала вызывают владельца для доступа к экземпляру элемента управления во время выполнения. Затем можно вызвать необходимые методы поведения для этого объекта.

public class IndexCardAutomationPeer : FrameworkElementAutomationPeer, IExpandCollapseProvider {
    private IndexCard ownerIndexCard;
    public IndexCardAutomationPeer(IndexCard owner) : base(owner)
    {
         ownerIndexCard = owner;
    }
}

Альтернативная реализация заключается в том, что сам элемент управления может ссылаться на его одноранговый узел. Это распространенный шаблон, если вы создаете события автоматизации из элемента управления, так как метод RaiseAutomationEvent является одноранговым методом.

события модель автоматизации пользовательского интерфейса

модель автоматизации пользовательского интерфейса события делятся на следующие категории.

Мероприятие	Description
Изменение свойства	Возникает при изменении свойства в элементе модель автоматизации пользовательского интерфейса или шаблоне элемента управления. Например, если клиенту требуется отслеживать элемент управления флажка приложения, он может зарегистрировать для прослушивания события изменения свойства в свойстве ToggleState . Если флажок установлен или снят, поставщик запускает событие, и клиент может действовать по мере необходимости.
Действие элемента	Возникает при изменении пользовательского интерфейса из пользовательского интерфейса или программного действия; например, когда кнопка нажимается или вызывается с помощью шаблона Вызова .
Изменение структуры	Возникает при изменении структуры дерева модель автоматизации пользовательского интерфейса. Структура изменяется, когда новые элементы пользовательского интерфейса становятся видимыми, скрытыми или удаленными на рабочем столе.
Глобальные изменения	Возникает при возникновении действий глобального интереса к клиенту, например при перемещении фокуса с одного элемента на другой или при закрытии дочернего окна. Некоторые события необязательно означают, что состояние пользовательского интерфейса изменилось. Например, если пользователь вкладывается в поле записи текста, а затем нажимает кнопку, чтобы обновить поле, событие TextChanged запускается, даже если пользователь фактически не изменил текст. При обработке события клиентскому приложению может потребоваться проверить, действительно ли что-либо изменилось, перед выполнением действия.

Идентификаторы AutomationEvents

события модель автоматизации пользовательского интерфейса идентифицируются по Значения AutomationEvents. Значения перечисления однозначно определяют тип события.

Инициирование событий

модель автоматизации пользовательского интерфейса клиенты могут подписаться на события автоматизации. В одноранговой модели автоматизации одноранговые узлы для пользовательских элементов управления должны сообщать об изменениях состояния управления, которые относятся к специальным возможностям путем вызова метода RaiseAutomationEvent. Аналогичным образом, если значение свойства ключа модель автоматизации пользовательского интерфейса изменяется, одноранговые узлы пользовательского элемента управления должны вызывать метод RaisePropertyChangedEvent.

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

if (AutomationPeer.ListenerExists(AutomationEvents.PropertyChanged))
{
    NumericUpDownAutomationPeer peer =
        FrameworkElementAutomationPeer.FromElement(nudCtrl) as NumericUpDownAutomationPeer;
    if (peer != null)
    {
        peer.RaisePropertyChangedEvent(
            RangeValuePatternIdentifiers.ValueProperty,
            (double)oldValue,
            (double)newValue);
    }
}

Навигация по одноранговым узлам

После поиска однорангового узла автоматизации клиент модель автоматизации пользовательского интерфейса может перемещаться по структуре однорангового приложения, вызывая методы GetChildren и GetParent однорангового объекта. Навигация между элементами пользовательского интерфейса в элементе управления поддерживается реализацией метода GetChildrenCore однорангового узла. Система модель автоматизации пользовательского интерфейса вызывает этот метод для создания дерева вложенных элементов, содержащихся в элементе управления. Например, элементы списка в поле списка. Метод GetChildrenCore по умолчанию в FrameworkElementAutomationPeer проходит визуальное дерево элементов для создания дерева одноранговых узлов автоматизации. Пользовательские элементы управления могут переопределить этот метод, чтобы предоставить другому представлению дочерних элементов клиентам автоматизации, возвращая одноранговые узлы автоматизации элементов, которые передают информацию или разрешают взаимодействие с пользователем.

Поддержка собственных шаблонов автоматизации для шаблонов текста

Некоторые одноранговые узлы автоматизации приложений UWP по умолчанию обеспечивают поддержку шаблона элемента управления для текстового шаблона (PatternInterface.Text). Но они обеспечивают эту поддержку с помощью собственных методов, и участвующие одноранговые узлы не отмечают интерфейс ITextProvider в наследовании (управляемого). Тем не менее, если управляемый или неуправляемый модель автоматизации пользовательского интерфейса клиент запрашивает одноранговый узел для шаблонов, он сообщает о поддержке текстового шаблона и предоставляет поведение для частей шаблона при вызове клиентских API.

Если вы планируете наследовать один из элементов управления текстом приложения UWP, а также создать пользовательский одноранговый узел, производный от одного из текстовых одноранговых узлов, проверьте разделы "Примечания" для однорангового узла, чтобы узнать больше о поддержке шаблонов на собственном уровне. Вы можете получить доступ к собственному базовому поведению в пользовательском одноранговом узле, если вызвать базовую реализацию из реализаций интерфейса управляемого поставщика, но трудно изменить то, что делает базовая реализация, так как собственные интерфейсы как в одноранговом, так и его элементе управления владельцем не предоставляются. Как правило, следует использовать базовые реализации как есть (только для вызова) или полностью заменить функциональные возможности собственным управляемым кодом и не вызывать базовую реализацию. Последний является расширенным сценарием, вам потребуется хорошее знакомство с платформой текстовых служб, используемой вашим элементом управления, для поддержки требований к специальным возможностям при использовании этой платформы.

AutomationProperties.AccessibilityView

Помимо предоставления пользовательского однорангового узла, можно также настроить представление представления дерева для любого экземпляра элемента управления, задав AutomationProperties.AccessibilityView в XAML. Это не реализовано в рамках однорангового класса, но мы рассмотрим его здесь, так как это немецкий язык для общей поддержки специальных возможностей либо для пользовательских элементов управления, либо для шаблонов, которые вы настраиваете.

Основным сценарием использования AutomationProperties.AccessibilityView является намеренное опущение определенных элементов управления в шаблоне из представлений модель автоматизации пользовательского интерфейса, так как они не имеют существенного вклада в представление специальных возможностей всего элемента управления. Чтобы предотвратить это, задайте для параметра AutomationProperties.AccessibilityView значение Raw.

Создание исключений из одноранговых узлов автоматизации

Api, которые вы реализуете для поддержки одноранговой службы автоматизации, могут вызывать исключения. Ожидается, что все модель автоматизации пользовательского интерфейса клиенты, которые прослушивают, достаточно надежны, чтобы продолжить работу после возникновения большинства исключений. Во всей вероятности, что прослушиватель смотрит на дерево автоматизации все вверх, которое включает приложения, отличные от ваших собственных, и это неприемлемый дизайн клиента, чтобы привести весь клиент только потому, что одна область дерева вызвала одноранговое исключение, когда клиент назвал его API.

Для параметров, передаваемых в одноранговый узел, можно проверить входные данные и, например, вызвать АргументNullException, если он был передан null, и это недопустимое значение для реализации. Однако если есть последующие операции, выполняемые вашим одноранговым элементом, помните, что взаимодействие однорангового узла с элементом управления размещением имеет для них что-то асинхронное. Все, что одноранговый элемент не обязательно блокирует поток пользовательского интерфейса в элементе управления (и, вероятно, не должен). Таким образом, вы можете иметь ситуации, когда объект был доступен или имел определенные свойства при создании однорангового узла или при первом вызове метода однорангового узла автоматизации, но в то же время состояние элемента управления изменилось. В таких случаях существует два выделенных исключения, которые поставщик может вызвать:

• Создайте исключение ElementNotAvailableException , если вы не можете получить доступ к владельцу однорангового узла или связанному элементу однорангового узла на основе исходной информации, которую был передан API. Например, у вас может быть одноранговый узел, который пытается запустить методы, но владелец с тех пор был удален из пользовательского интерфейса, например модальное диалоговое окно, которое было закрыто. Для клиента non-.NET это сопоставляется с UIA_E_ELEMENTNOTAVAILABLE.
• Вызов elementNotEnabledException, если по-прежнему существует владелец, но этот владелец находится в режиме, например IsEnabled=false, который блокирует некоторые из определенных программных изменений, которые ваш одноранговый узел пытается выполнить. Для клиента non-.NET это сопоставляется с UIA_E_ELEMENTNOTENABLED.

Помимо этого, одноранговые узлы должны быть относительно консервативными в отношении исключений, которые они бросают из их поддержки одноранговых узлов. Большинство клиентов не смогут обрабатывать исключения из одноранговых узлов и превратить их в интерактивные варианты, которые их пользователи могут сделать при взаимодействии с клиентом. Поэтому иногда нет-оп и перехват исключений без повторного увеличения в одноранговых реализациях является лучшей стратегией, чем вызывает исключения каждый раз, когда одноранговый элемент пытается сделать не работает. Рассмотрим также, что большинство клиентов модель автоматизации пользовательского интерфейса не написаны в управляемом коде. Большинство записываются на COM и просто проверяют наличие S_OK в HRESULT всякий раз, когда они вызывают метод модель автоматизации пользовательского интерфейса клиента, который заканчивается доступом к одноранговой системе.

См. также

• Специальные возможности
• Пример специальных возможностей XAML
• FrameworkElementAutomationPeer
• AutomationPeer
• OnCreateAutomationPeer
• Шаблоны и интерфейсы элементов управления