Стандартные компоненты MFC изначально обеспечивают поставщиков автоматизации пользовательского интерфейса? - PullRequest
0 голосов
/ 19 октября 2019

Я - новичок в платформах приложений Microsoft, таких как WPF, Win32, и я только начал изучать некоторые материалы о доступности. что меня интересует, так это то, что MFC изначально предлагает провайдеров автоматизации пользовательского интерфейса для своих стандартных компонентов без необходимости явной реализации их для каждого из компонентов (CButton, CListBox ...).

Я прочитал документы Microsoft об автоматизации пользовательского интерфейса, MSAA и их совместимость. В UIA docs указано следующее:

"Microsoft включает поставщика для каждого из стандартных элементов управления, которые поставляются с Microsoft Win32, Windows Forms и Windows Presentation Foundation (WPF). "

Я знаю, что MFC построен как оболочка C ++ для Win32, я просто хочу убедиться, что цитата из документации также применима к MFC, потому что я не нашел никакихпрямое упоминание провайдеров UI Automation в документах MFC. Итак, мои вопросы:

  1. Если MFC не предоставляет поставщиков автоматизации пользовательского интерфейса из коробки, то почему такие инструменты, как Inspect , могут предоставить информацию об интерфейсах, реализованных заголовок uiautomationcore.h (то есть IDragProvider , ILegacyIAccessibleProvider ...) при проверке чистого приложения MFC? Выводит ли это каким-либо образом состояние этих интерфейсов из свойства «role» интерфейса IAccessible из MSAA?

  2. Если стандартные компоненты MFC неявно реализуют поставщиков UIA,почему Проверка в режиме MSAA в поле «Impl» показывает «Local oleacc proxy», как будто приложение поддерживает только MSAA, а не UIA? Поскольку приложения, которые изначально поддерживают UIA, имеют поле «Impl», установленное на «Удаленный собственный IAccessible (UIA-to-MSAA Bridge)».

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...