Alternatives à l’annotation dynamique

Il existe d’autres façons de fournir des personnalisées prise en charge des éléments d’interface utilisateur et, dans certains cas, il s’agit de la solution appropriée. Avant l’annotation dynamique, ces autres techniques étaient les seules options disponibles pour les développeurs. Ils incluent l’implémentation de l’ensemble des techniques de iAccessible et programmatiques.

Implémentation de l’interface IAccessible

Une autre technique consiste à implémenter l’interface IAccessible. Cette approche est souvent nécessaire pour des contrôles personnalisés ou des éléments d’interface utilisateur radicalement différents ; toutefois, les coûts de développement et de test sont suffisamment significatifs pour éviter les coûts, sauf s’ils sont vraiment nécessaires. Si l’objectif est de modifier une propriété unique, le coût est difficile à justifier.

Techniques programmatiques

Une autre option consiste à utiliser des techniques de sous-classe et d’habillage pour modifier les informations exposées pour une propriété spécifique. Il s’agit de la technique que l’annotation dynamique est destinée à remplacer. Pour remplacer une propriété unique à l’aide de la sous-classe et de l’habillage, le développeur doit effectuer les étapes suivantes :

1. Sous-classe le HWND de l’objet IAccessible.
2. Interceptez le message WM_GETOBJECT pour la valeur IParam/OBJID correcte.
3. Transférez le message WM_GETOBJECT à la classe de base à l’aide de la fonction de rappel CallWndProc. Si zéro est retourné, appelez CreateStdAccessibleObject; sinon, appelez LresultFromObject sur la valeur retournée pour obtenir le pointeur d’interface IAccessible natif du contrôle.
4. Créez une classe wrapper, qui implémente IAccessible et encapsule le pointeur d’interface IAccessible retourné à l’étape précédente. Cette classe wrapper envoie toutes les méthodes et propriétés au pointeur d’interface iAccessible d’origine, sauf ceux à remplacer. Cela implique l’écriture de code de transfert pour toutes les les propriétés et méthodes de l’interface IAccessible 21, quel que soit le nombre de substitutions.

En outre, les développeurs doivent vérifier les conditions suivantes :

• La méthode ou la propriété substituée ne doit gérer que les ID enfants requis et transférer tous les autres vers le pointeur d’interface IAccessible d’origine.
• L’habillage doit également transférer IEnumVARIANT et interfaces IOleWindow uniquement si l’objet d’origine les prend en charge.
• Le comptage de références doit être géré correctement, en particulier si d’autres interfaces sont prises en charge.
• méthode IDispatch retour doit être gérée correctement, en particulier avec la méthode ITypeInfo ::Invoke, qui doit être appelée avec un pointeur d’interface vers l’interface wrapper, et non pas un pointeur vers l’interface IAccessible d’origine.

Ces techniques nécessitent une quantité considérable de travail, même si seules une ou deux propriétés doivent être remplacées. La majorité du code résultant concerne la sous-classe et l’habillage, et seule une petite fraction fournit réellement les informations substituées.

Toutefois, il existe des scénarios dans lesquels ces techniques sont nécessaires. Par exemple, si vous apportez des modifications structurelles pour créer un élément d’interface utilisateur d’espace réservé, vous devez utiliser ces techniques plutôt que l’annotation dynamique.

Correction des noms dérivés des étiquettes

Certains contrôles courants Microsoft Win32, tels que le contrôle de zone d’édition, sont presque toujours utilisés avec une étiquette (une entrée LTEXT dans le fichier de ressources) ou une zone de groupe (GROUPBOX dans le fichier de ressources). Microsoft Active Accessibility dérive automatiquement la propriété name du contrôle à partir de son étiquette. Pour ces contrôles, le texte de la fenêtre (affiché dans Microsoft Visual Studio comme propriété Name ou ID) est ignoré, car il est généralement généré automatiquement et rarement très descriptif ; par exemple, « IDC_EDIT1 ».

Si l’interface utilisateur de l’application n’est pas conçue correctement, Microsoft Active Accessibility peut ne pas être en mesure de définir le nom correctement. Pour être associé à un contrôle, la zone d’étiquette ou de groupe doit être placée immédiatement avant le contrôle dynamique dans l’ordre de tabulation.

L’ordre de tabulation peut être modifié à l’aide de l’outil dans Visual Studio (dans le menu Format lorsque l’éditeur de ressources est ouvert) ou en modifiant directement le fichier de ressources.

L’exemple suivant montre la description d’un fichier de ressources d’une boîte de dialogue qui contient deux zones d’édition étiquetées.

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

Dans cet exemple, les étiquettes et les contrôles ne sont pas répertoriés dans l’ordre de tabulation correct. Par conséquent, Microsoft Active Accessibility attribue le nom « Nom » à la zone de modification de prénom, et aucun nom du tout à la zone de modification du nom.

L’exemple suivant montre la liste des ressources correcte. Notez également que les touches de raccourci ont été désignées dans les étiquettes.

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

Lorsque les contrôles ont des étiquettes supplémentaires, telles que pour les valeurs minimales et maximales sur une barre de suivi, ces étiquettes doivent être placées après le contrôle dans l’ordre de tabulation. L’étiquette principale du contrôle doit apparaître immédiatement avant le contrôle lui-même.

Affectation de noms de contrôles sans étiquettes

Il n’est pas toujours possible ou souhaitable d’avoir une étiquette visible pour chaque contrôle. Toutefois, vous pouvez toujours fournir un nom pour le contrôle en ajoutant une étiquette invisible. Comme toujours, l’étiquette invisible doit immédiatement précéder le contrôle dans l’ordre de tabulation.

Si vous utilisez l’éditeur de ressources dans Microsoft Visual Studio .NET, vous pouvez définir la propriété Visible sur False. Pour rendre l’étiquette invisible lors de la modification du fichier de ressources (.rc), ajoutez NOT WS_VISIBLE ou à la partie style du contrôle d’étiquette, comme illustré dans l’exemple suivant.

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

Notez que toute touche de raccourci désignée fonctionne même si l’étiquette est invisible.