Share via


Alternativen zur dynamischen Anmerkung

Es gibt andere Möglichkeiten, benutzerdefinierte IAccessible-Unterstützung für UI-Elemente bereitzustellen, und in einigen Fällen sind sie die richtige Lösung. Vor der dynamischen Anmerkung waren diese alternativen Techniken die einzigen Optionen, die Entwicklern zur Verfügung standen. Dazu gehören die Implementierung aller IAccessible-Schnittstelle und programmgesteuerter Techniken.

Implementieren der gesamten IAccessible-Schnittstelle

Eine alternative Methode besteht darin, die gesamte IAccessible-Schnittstelle zu implementieren. Dieser Ansatz ist häufig für benutzerdefinierte Steuerelemente oder radikal unterschiedliche UI-Elemente erforderlich. die Entwicklungs- und Testkosten sind jedoch so erheblich, dass sie vermieden werden sollten, es sei denn, es ist wirklich notwendig. Wenn das Ziel darin besteht, eine einzelne Eigenschaft zu ändern, sind die Kosten schwer zu rechtfertigen.

Programmgesteuerte Techniken

Eine weitere Möglichkeit besteht darin, Unterklassen- und Wrappingtechniken zu verwenden, um die Informationen zu ändern, die für eine bestimmte Eigenschaft verfügbar gemacht werden. Dies ist die Technik, die die dynamische Anmerkung ersetzen soll. Um eine einzelne Eigenschaft mithilfe von Unterklassen und Wrapping außer Kraft zu setzen, muss der Entwickler die folgenden Schritte ausführen:

  1. Unterklasse des HWND des IAccessible-Objekts .
  2. Abfangen Sie die WM_GETOBJECT Nachricht für den richtigen IParam/OBJID-Wert.
  3. Leiten Sie die WM_GETOBJECT Nachricht mithilfe der CallWndProc-Rückruffunktion an die Basisklasse weiter. Wenn null zurückgegeben wird, rufen Sie CreateStdAccessibleObject auf. Rufen Sie andernfalls LresultFromObject für den zurückgegebenen Wert auf, um den nativen IAccessible-Schnittstellenzeiger des Steuerelements abzurufen.
  4. Erstellen Sie eine Wrapperklasse, die IAccessible implementiert und den IAccessible-Schnittstellenzeiger umschließt, der aus dem vorherigen Schritt zurückgegeben wurde. Diese Wrapperklasse sendet alle Methoden und Eigenschaften an den ursprünglichen IAccessible-Schnittstellenzeiger , mit Ausnahme derjenigen, die überschrieben werden sollen. Dies umfasst das Schreiben von Weiterleitungscode für alle 21 Eigenschaften und Methoden der IAccessible-Schnittstelle , unabhängig davon, wie viele tatsächlich überschrieben werden.

Außerdem müssen Entwickler die folgenden Bedingungen überprüfen:

  • Die überschriebene Methode oder Eigenschaft darf nur die erforderlichen untergeordneten IDs verarbeiten und alle anderen an den ursprünglichen IAccessible-Schnittstellenzeiger weiterleiten.
  • Das Wrapping muss auch die Schnittstellen IEnumVARIANT und IOleWindow nur weiterleiten, wenn sie vom ursprünglichen Objekt unterstützt werden.
  • Die Verweiszählung muss ordnungsgemäß behandelt werden, insbesondere wenn andere Schnittstellen unterstützt werden.
  • IDispatch-Rückgabewerte müssen ordnungsgemäß behandelt werden, insbesondere mit der ITypeInfo::Invoke-Methode , die mit einem Schnittstellenzeiger auf die Wrapperschnittstelle aufgerufen werden muss, nicht mit einem Zeiger auf die ursprüngliche IAccessible-Schnittstelle .

Diese Techniken erfordern einen erheblichen Arbeitsaufwand, auch wenn nur eine oder zwei Eigenschaften überschrieben werden müssen. Der Großteil des resultierenden Codes betrifft Unterklassen und Wrapping, und nur ein kleiner Bruchteil stellt tatsächlich die überschriebenen Informationen bereit.

Es gibt jedoch Szenarien, in denen diese Techniken erforderlich sind. Wenn Sie beispielsweise strukturelle Änderungen vornehmen, um ein Platzhalter-UI-Element zu erstellen, sollten Sie diese Techniken anstelle der dynamischen Anmerkung verwenden.

Beheben von Namen, die von Bezeichnungen abgeleitet sind

Einige gängige Microsoft Win32-Steuerelemente, z. B. das Bearbeitungsfeld-Steuerelement, werden fast immer mit einer Bezeichnung (einem LTEXT-Eintrag in der Ressourcendatei) oder einem Gruppenfeld (GROUPBOX in der Ressourcendatei) verwendet. Microsoft Active Accessibility leitet automatisch die Namenseigenschaft des Steuerelements von seiner Bezeichnung ab. Bei solchen Steuerelementen wird der Fenstertext (in Microsoft Visual Studio als Name oder ID-Eigenschaft angezeigt) ignoriert, da er in der Regel automatisch generiert und selten sehr beschreibend ist. beispiel: "IDC_EDIT1".

Wenn die Benutzeroberfläche der Anwendung nicht ordnungsgemäß entworfen wurde, kann Microsoft Active Accessibility den Namen möglicherweise nicht ordnungsgemäß festlegen. Um einem Steuerelement zugeordnet zu werden, muss das Bezeichnungs- oder Gruppenfeld unmittelbar vor dem dynamischen Steuerelement in der Aktivierreihenfolge platziert werden.

Die Aktivierreihenfolge kann mithilfe des Tools in Visual Studio (im Menü Format, wenn der Ressourcen-Editor geöffnet ist) oder durch direktes Bearbeiten der Ressourcendatei geändert werden.

Das folgende Beispiel zeigt die Beschreibung eines Dialogfelds in einer Ressourcendatei, das zwei beschriftete Bearbeitungsfelder enthält.

IDD_INPUTNAME DIALOGEX 22, 17, 312, 118
STYLE DS_SETFONT | DS_MODALFRAME | WS_CAPTION | WS_SYSMENU
CAPTION "Enter your name"
FONT 8, "System", 0, 0, 0x0
BEGIN
    DEFPUSHBUTTON   "OK",IDOK,179,35,30,11,WS_GROUP
    LTEXT           "First Name:",IDC_STATIC,8,16,43,8
    LTEXT           "Last Name:",IDC_STATIC,8,33,43,8
    EDITTEXT        IDC_EDITFIRSTNAME,53,15,120,12,ES_AUTOHSCROLL
    EDITTEXT        IDC_EDITLASTNAME,53,34,120,12,ES_AUTOHSCROLL
END

In diesem Beispiel werden die Bezeichnungen und Steuerelemente nicht in der richtigen Aktivierreihenfolge aufgeführt. Daher weist Microsoft Active Accessibility dem Bearbeitungsfeld "Vorname" den Namen "Nachname" und dem Bearbeitungsfeld für den Nachnamen überhaupt keinen Namen zu.

Das folgende Beispiel zeigt die richtige Ressourcenauflistung. Beachten Sie auch, dass Tastenkombinationen in den Bezeichnungen festgelegt wurden.

IDD_INPUTNAME DIALOGEX 22, 17, 312, 118
STYLE DS_SETFONT | DS_MODALFRAME | WS_CAPTION | WS_SYSMENU
CAPTION "Enter your name"
FONT 8, "System", 0, 0, 0x0
BEGIN
    LTEXT           "&First Name:",IDC_STATIC,8,16,43,8
    EDITTEXT        IDC_EDITFIRSTNAME,53,15,120,12,ES_AUTOHSCROLL
    LTEXT           "&Last Name:",IDC_STATIC,8,33,43,8
    EDITTEXT        IDC_EDITLASTNAME,53,34,120,12,ES_AUTOHSCROLL
    DEFPUSHBUTTON   "OK",IDOK,179,35,30,11,WS_GROUP
END

Wenn Steuerelemente über ergänzende Bezeichnungen verfügen, z. B. für minimale und maximale Werte auf einer Trackleiste, sollten diese Bezeichnungen nach dem Steuerelement in der Aktivierreihenfolge platziert werden. Die Standard Bezeichnung des Steuerelements muss unmittelbar vor dem Steuerelement selbst angezeigt werden.

Benennen von Steuerelementen ohne Bezeichnungen

Es ist nicht immer möglich oder wünschenswert, für jedes Steuerelement eine sichtbare Bezeichnung zu haben. Sie können jedoch weiterhin einen Namen für das Steuerelement angeben, indem Sie eine unsichtbare Bezeichnung hinzufügen. Wie immer muss die unsichtbare Bezeichnung unmittelbar vor dem Steuerelement in der Aktivierreihenfolge stehen.

Wenn Sie den Ressourcen-Editor in Microsoft Visual Studio .NET verwenden, können Sie die Visible-Eigenschaft auf False festlegen. Um die Bezeichnung beim Bearbeiten der Ressourcendatei (RC) unsichtbar zu machen, fügen Sie NOT WS_VISIBLE oder dem Stilteil des Bezeichnungssteuerelements hinzu, wie im folgenden Beispiel gezeigt.

    LTEXT           "&FullName:",IDC_STATIC,111,23,44,8,NOT WS_VISIBLE

Beachten Sie, dass jede festgelegte Tastenkombination funktioniert, obwohl die Bezeichnung unsichtbar ist.