Implementacja dostawcy automatyzacji interfejsu użytkownika po stronie serwera

  • Artykuł

Uwaga

Ta dokumentacja jest przeznaczona dla deweloperów programu .NET Framework, którzy chcą używać zarządzanych klas automatyzacja interfejsu użytkownika zdefiniowanych w System.Windows.Automation przestrzeni nazw. Aby uzyskać najnowsze informacje na temat automatyzacja interfejsu użytkownika, zobacz Interfejs API usługi Windows Automation: automatyzacja interfejsu użytkownika.

W tej sekcji opisano sposób implementowania dostawcy automatyzacja interfejsu użytkownika po stronie serwera dla kontrolki niestandardowej.

Implementacja elementów windows Presentation Foundation (WPF) i elementów innych niż WPF (takich jak te przeznaczone dla windows Forms) jest zasadniczo inna. Elementy WPF zapewniają obsługę automatyzacja interfejsu użytkownika za pośrednictwem klasy pochodzącej z AutomationPeerklasy . Elementy inne niż WPF zapewniają obsługę za pośrednictwem implementacji interfejsów dostawcy.

Zagadnienia związane z zabezpieczeniami

Dostawcy powinni być napisani, aby mogli pracować w środowisku częściowo zaufanym. Ponieważ UIAutomationClient.dll nie jest skonfigurowany do uruchamiania w ramach częściowego zaufania, kod dostawcy nie powinien odwoływać się do tego zestawu. Jeśli tak się stanie, kod może być uruchamiany w środowisku o pełnym zaufaniu, ale następnie kończy się niepowodzeniem w środowisku częściowego zaufania.

W szczególności nie należy używać pól z klas w UIAutomationClient.dll, takich jak te w pliku AutomationElement. Zamiast tego użyj równoważnych pól z klas w UIAutomationTypes.dll, takich jak AutomationElementIdentifiers.

Implementacja dostawcy przez elementy programu Windows Presentation Foundation

Aby uzyskać więcej informacji na ten temat, zobacz automatyzacja interfejsu użytkownika niestandardowej kontrolki WPF.

Implementacja dostawcy przez elementy inne niż WPF

Kontrolki niestandardowe, które nie są częścią struktury WPF, ale są zapisywane w kodzie zarządzanym (najczęściej są to kontrolki Windows Forms), zapewniają obsługę automatyzacja interfejsu użytkownika przez zaimplementowanie interfejsów. Każdy element musi zaimplementować co najmniej jeden z interfejsów wymienionych w pierwszej tabeli w następnej sekcji. Ponadto jeśli element obsługuje co najmniej jeden wzorzec sterowania, musi zaimplementować odpowiedni interfejs dla każdego wzorca kontrolki.

Projekt dostawcy automatyzacja interfejsu użytkownika musi odwoływać się do następujących zestawów:

  • UIAutomationProviders.dll

  • UIAutomationTypes.dll

  • Windowsbase.dll

Interfejsy dostawcy

Każdy dostawca automatyzacja interfejsu użytkownika musi zaimplementować jeden z następujących interfejsów.

Interfejs opis
IRawElementProviderSimple Udostępnia funkcje prostej kontrolki hostowanej w oknie, w tym obsługę wzorców i właściwości kontrolek.
IRawElementProviderFragment Dziedziczy z obiektu IRawElementProviderSimple. Dodaje funkcje elementu w złożonej kontrolce, w tym nawigację w obrębie fragmentu, ustawianie fokusu i zwracanie prostokąta ograniczenia elementu.
IRawElementProviderFragmentRoot Dziedziczy z obiektu IRawElementProviderFragment. Dodaje funkcje elementu głównego w złożonej kontrolce, w tym lokalizowanie elementu podrzędnego na określonych współrzędnych i ustawianie stanu koncentracji uwagi dla całej kontrolki.

Następujące interfejsy zapewniają dodatkowe funkcje, ale nie są wymagane do zaimplementowania.

Interfejs opis
IRawElementProviderAdviseEvents Umożliwia dostawcy śledzenie żądań dotyczących zdarzeń.
IRawElementProviderHwndOverride Umożliwia zmiana położenia elementów opartych na oknach w drzewie automatyzacja interfejsu użytkownika fragmentu.

Wszystkie inne interfejsy w System.Windows.Automation.Provider przestrzeni nazw są obsługiwane przez wzorzec sterowania.

Wymagania dotyczące dostawców innych niż WPF

Aby komunikować się z automatyzacja interfejsu użytkownika, kontrolka musi zaimplementować następujące główne obszary funkcjonalności:

Funkcje Implementacja
Uwidocznij dostawcę na automatyzacja interfejsu użytkownika W odpowiedzi na komunikat WM_GETOBJECT wysłany do okna sterowania zwróć obiekt, który implementuje IRawElementProviderSimple (lub interfejs pochodny). W przypadku fragmentów musi to być dostawca katalogu głównego fragmentu.
Podaj wartości właściwości Zaimplementuj GetPropertyValue , aby podać lub zastąpić wartości.
Umożliwia klientowi interakcję z kontrolką Zaimplementuj interfejsy obsługujące wzorce sterowania, takie jak IInvokeProvider. Zwróć tych dostawców wzorców w implementacji programu GetPatternProvider.
Zgłaszanie zdarzeń Wywołaj jedną ze statycznych metod wywołania AutomationInteropProvider metody , aby zgłosić zdarzenie, na które klient może nasłuchiwać.
Włączanie nawigacji i koncentracji uwagi w obrębie fragmentu Zaimplementuj IRawElementProviderFragment dla każdego elementu w obrębie fragmentu. (Nie jest to konieczne w przypadku elementów, które nie są częścią fragmentu).
Włączanie koncentracji uwagi i lokalizacji elementu podrzędnego w fragmentcie Zaimplementuj .IRawElementProviderFragmentRoot (Nie jest to konieczne w przypadku elementów, które nie są fragmentami korzeni).

Wartości właściwości w dostawcach innych niż WPF

automatyzacja interfejsu użytkownika dostawcy kontrolek niestandardowych muszą obsługiwać pewne właściwości, które mogą być używane przez system automatyzacji, a także przez aplikacje klienckie. W przypadku elementów hostowanych w systemach Windows (HWND) automatyzacja interfejsu użytkownika mogą pobrać niektóre właściwości od domyślnego dostawcy okien, ale muszą uzyskać inne od dostawcy niestandardowego.

Dostawcy kontrolek opartych na HWND zwykle nie muszą udostępniać następujących właściwości (zidentyfikowanych przez wartości pól):

Uwaga

Element RuntimeIdProperty prosty lub element główny fragmentu hostowany w oknie jest uzyskiwany z okna, jednak elementy fragmentu poniżej katalogu głównego (takie jak elementy listy w polu listy) muszą podać własne identyfikatory. Aby uzyskać więcej informacji, zobacz GetRuntimeId.

Element IsKeyboardFocusableProperty powinien zostać zwrócony dla dostawców hostowanych w kontrolce Windows Forms. W takim przypadku domyślny dostawca okien może nie być w stanie pobrać poprawnej wartości.

Element NameProperty jest zwykle dostarczany przez dostawcę hosta. Jeśli na przykład niestandardowa kontrolka pochodzi z Control, nazwa pochodzi z Text właściwości kontrolki.

Na przykład kod można znaleźć w temacie Return Properties from a automatyzacja interfejsu użytkownika Provider (Właściwości zwracane z dostawcy automatyzacja interfejsu użytkownika).

Zdarzenia w dostawcach innych niż WPF

automatyzacja interfejsu użytkownika dostawcy powinni zgłaszać zdarzenia w celu powiadamiania aplikacji klienckich o zmianach w stanie interfejsu użytkownika. Następujące metody służą do zgłaszania zdarzeń.

Metoda opis
RaiseAutomationEvent Wywołuje różne zdarzenia, w tym zdarzenia wyzwalane przez wzorce kontrolek.
RaiseAutomationPropertyChangedEvent Zgłasza zdarzenie, gdy właściwość automatyzacja interfejsu użytkownika uległa zmianie.
RaiseStructureChangedEvent Wywołuje zdarzenie, gdy struktura drzewa automatyzacja interfejsu użytkownika uległa zmianie, na przykład przez usunięcie lub dodanie elementu.

Celem zdarzenia jest powiadomienie klienta o czymś, co ma miejsce w interfejsie użytkownika, niezależnie od tego, czy działanie jest wyzwalane przez sam system automatyzacja interfejsu użytkownika. Na przykład zdarzenie zidentyfikowane przez InvokedEvent element powinno być zgłaszane za każdym razem, gdy kontrolka jest wywoływana, za pośrednictwem bezpośredniego wprowadzania danych przez użytkownika lub przez aplikację kliencą wywołującą metodę Invoke.

Aby zoptymalizować wydajność, dostawca może selektywnie zgłaszać zdarzenia lub zgłaszać żadne zdarzenia, jeśli żadna aplikacja kliencka nie jest zarejestrowana w celu ich odbierania. Poniższe metody są używane do optymalizacji.

Metoda opis
ClientsAreListening Ta właściwość statyczna określa, czy wszystkie aplikacje klienckie zasubskrybowały zdarzenia automatyzacja interfejsu użytkownika.
IRawElementProviderAdviseEvents Implementacja tego interfejsu przez dostawcę w katalogu głównym fragmentu umożliwia jej informowanie, gdy klienci rejestrują i wyrejestruj programy obsługi zdarzeń dla zdarzeń w fragmentcie.

Nawigacja dostawcy spoza WPF

Dostawcy prostych kontrolek, takich jak przycisk niestandardowy hostowany w oknie (HWND), nie muszą obsługiwać nawigacji w drzewie automatyzacja interfejsu użytkownika. Nawigacja do i z elementu jest obsługiwana przez domyślnego dostawcę dla okna hosta, który jest określony w implementacji programu HostRawElementProvider. Podczas implementowania dostawcy dla złożonej kontrolki niestandardowej należy jednak obsługiwać nawigację między węzłem głównym fragmentu i jego elementami podrzędnymi oraz między węzłami równorzędnymi.

Uwaga

Elementy fragmentu innego niż główny muszą zwracać null odwołanie z HostRawElementProviderelementu , ponieważ nie są one bezpośrednio hostowane w oknie, a żaden domyślny dostawca nie może obsługiwać nawigacji do i z nich.

Struktura fragmentu jest określana przez implementację .Navigate Dla każdego możliwego kierunku z każdego fragmentu ta metoda zwraca obiekt dostawcy dla elementu w tym kierunku. Jeśli w tym kierunku nie ma żadnego elementu, metoda zwraca null odwołanie.

Katalog główny fragmentu obsługuje nawigację tylko do elementów podrzędnych. Na przykład pole listy zwraca pierwszy element na liście, gdy kierunek to FirstChild, a ostatni element, gdy kierunek to LastChild. Katalog główny fragmentu nie obsługuje nawigacji do elementu nadrzędnego lub równorzędnego; Jest to obsługiwane przez dostawcę okna hosta.

Elementy fragmentu, które nie są elementem głównym, muszą obsługiwać nawigację do elementu nadrzędnego oraz do wszystkich elementów równorzędnych i elementów podrzędnych, które mają.

Reparenting dostawcy innego niż WPF

Okna podręczne są w rzeczywistości oknami najwyższego poziomu, dlatego domyślnie są wyświetlane w drzewie automatyzacja interfejsu użytkownika jako elementy podrzędne pulpitu. W wielu przypadkach okna podręczne są jednak logicznie dziećmi innych kontrolek. Na przykład lista rozwijana pola kombi jest logicznie elementem podrzędnym pola kombi. Podobnie okno podręczne menu jest logicznie elementem podrzędnym menu. automatyzacja interfejsu użytkownika zapewnia obsługę ponownego uruchamiania wyskakujących okienek tak, aby wydawały się być dziećmi skojarzonej kontrolki.

Aby powtórzyć okno podręczne:

  1. Utwórz dostawcę dla okna podręcznego. Wymaga to wcześniejszej nazwy klasy okna podręcznego.

  2. Zaimplementuj wszystkie właściwości i wzorce jak zwykle dla tego wyskakującego okienka, tak jakby była to kontrolka we własnym zakresie.

  3. Zaimplementuj HostRawElementProvider właściwość, aby zwracała wartość uzyskaną z HostProviderFromHandleklasy , gdzie parametr jest uchwytem okna okna okna podręcznego.

  4. Zaimplementuj Navigate okno podręczne i jego element nadrzędny, aby nawigacja została prawidłowo obsłużona z logicznego elementu nadrzędnego do elementów podrzędnych logicznych i między elementami podrzędnych elementów równorzędnych.

Gdy automatyzacja interfejsu użytkownika napotka okno podręczne, rozpoznaje, że nawigacja jest zastępowana od domyślnej i pomija okno podręczne po napotkaniu go jako elementu podrzędnego pulpitu. Zamiast tego węzeł będzie dostępny tylko za pośrednictwem fragmentu.

Reparenting nie jest odpowiedni w przypadkach, w których kontrolka może hostować okno dowolnej klasy. Na przykład pasek rebar może hostować dowolny typ HWND w swoich pasmach. Aby obsłużyć te przypadki, automatyzacja interfejsu użytkownika obsługuje alternatywną formę relokacji HWND zgodnie z opisem w następnej sekcji.

Zmiana położenia dostawcy spoza WPF

automatyzacja interfejsu użytkownika fragmenty mogą zawierać co najmniej dwa elementy, które znajdują się w oknie (HWND). Ponieważ każdy HWND ma własnego domyślnego dostawcę, który uważa, że HWND jest elementem podrzędnym zawierającego HWND, drzewo automatyzacja interfejsu użytkownika będzie domyślnie pokazywać wartości HWND w fragmentze jako elementy podrzędne okna nadrzędnego. W większości przypadków jest to pożądane zachowanie, ale czasami może prowadzić do nieporozumień, ponieważ nie pasuje do logicznej struktury interfejsu użytkownika.

Dobrym przykładem jest kontrolka paska pomocniczego. Pasek nawigacyjny zawiera paski, z których każda może z kolei zawierać kontrolkę opartą na HWND, taką jak pasek narzędzi, pole edycji lub pole kombi. Domyślny dostawca okien dla paska ponownego HWND widzi kontrolki pasma HWND jako elementów podrzędnych, a dostawca paska pomocniczego widzi pasma jako elementy podrzędne. Ponieważ dostawca HWND i dostawca paska pomocniczego pracują w tandemie i łączą swoje dzieci, zarówno zespoły, jak i kontrolki oparte na HWND pojawiają się jako elementy podrzędne paska pomocniczego. Logicznie jednak tylko pasma powinny być wyświetlane jako elementy podrzędne paska pomocniczego, a każdy dostawca pasm powinien być powiązany z domyślnym dostawcą HWND dla kontrolki, która zawiera.

W tym celu dostawca główny fragmentu paska pomocniczego uwidacznia zestaw elementów podrzędnych reprezentujących pasma. Każdy zespół ma jednego dostawcę, który może uwidaczniać właściwości i wzorce. W implementacji dostawcy przedziału HostRawElementProviderzwraca domyślnego dostawcę okien dla kontrolki HWND, który uzyskuje przez wywołanie HostProviderFromHandlemetody , przekazując uchwyt okna kontrolki. Na koniec dostawca główny fragmentu dla paska pomocniczego implementuje IRawElementProviderHwndOverride interfejs, a w jego implementacji GetOverrideProviderForHwnd zwraca odpowiedniego dostawcę pasm dla kontrolki zawartej w określonym HWND.

Zobacz też