Partager via


Exposition de contrôles basés sur des contrôles système

Vous devez envisager d’utiliser une certaine forme d’annotation dynamique (Direct, Value Map ou Server) avant d’essayer la technique décrite dans cette section. Pour plus d’informations, consultez API d’annotation dynamique.

Dans la plupart des cas, Microsoft Active Accessibility expose des informations sur les contrôles surclassés ou sous-classés. La superclassation et la sous-classification permettent aux développeurs d’applications de créer un contrôle personnalisé avec les fonctionnalités de base d’un contrôle système et d’inclure les améliorations fournies par l’application. Un contrôle surclassé a un nom de classe de fenêtre différent de celui du contrôle système sur lequel il est basé. Un contrôle sous-classé a le même nom de classe de fenêtre. Pour plus d’informations sur la superclasse et la sous-classification, consultez la documentation du Kit de développement logiciel (SDK) Windows.

Étant donné que Microsoft Active Accessibility expose des informations sur les contrôles fournis par le système, Microsoft Active Accessibility expose le contrôle modifié, sauf si un contrôle surclassé ou sous-classé est sensiblement différent du contrôle de base. Pour déterminer si le contrôle modifié est accessible, les développeurs d’applications doivent utiliser des utilitaires tels que Inspect et Accessible Event Watcher pour comparer le comportement du contrôle modifié avec le contrôle de base.

Si, après avoir utilisé ces utilitaires, vous déterminez que le contrôle modifié n’est pas accessible, vous devez le traiter comme tout autre contrôle personnalisé. Le contrôle doit déclencher des événements, et la procédure de fenêtre de l’application doit répondre au message WM_GETOBJECTen fournissant une interface IAccessible que les applications clientes utilisent pour obtenir des informations sur le contrôle.

CreateStdAccessibleProxy et CreateStdAccessibleObject

Si la totalité ou la plupart des propriétés IAccessible du contrôle modifié sont identiques au contrôle de base, utilisez CreateStdAccessibleProxy ou CreateStdAccessibleObject pour simplifier l’implémentation de l’interface IAccessible du contrôle.

Notes

Lorsque vous superclassez ou sous-classez un contrôle accessible, n’oubliez pas que l’objet récupéré par la fonction CreateStdAccessibleObject peut implémenter plus que l’interface IAccessible . Il peut inclure d’autres interfaces telles que IEnumVARIANT. Vous devrez peut-être inclure ces interfaces supplémentaires pour conserver la prise en charge de l’accessibilité fournie par l’implémentation d’origine du contrôle.

 

Les fonctions CreateStdAccessibleProxy et CreateStdAccessibleObject récupèrent un pointeur d’interface IAccessible pour le contrôle système spécifié. La différence dans ces fonctions est que CreateStdAccessibleObject utilise le nom de classe de fenêtre obtenu à partir de son paramètre hwnd tandis que CreateStdAccessibleProxy utilise le nom de classe de fenêtre spécifié dans son paramètre szClassName . Par conséquent, si vous décidez d’utiliser ces fonctions, utilisez CreateStdAccessibleProxy pour exposer des informations sur les contrôles surclassés, et l’une ou l’autre des fonctions avec des contrôles sous-classés.

Après avoir obtenu un pointeur d’interface IAccessible vers le contrôle système, utilisez le pointeur dans votre implémentation de l’interface IAccessible pour le contrôle modifié. Si une propriété ou une méthode pour le contrôle modifié est identique au contrôle de base, utilisez le pointeur IAccessible pour retourner les informations fournies par le contrôle de base. Si une propriété pour le contrôle modifié est différente du contrôle de base, remplacez la propriété du contrôle de base.

Dans l’exemple suivant, CAccCustomButton est la classe définie par l’application dérivée de IAccessible. La variable membre m_pAccDefaultButton est un pointeur vers une interface IAccessible récupérée à partir de CreateStdAccessibleObject pendant la procédure d’initialisation du contrôle. Dans cet exemple, la propriété Role du contrôle personnalisé étant identique à la propriété Role du contrôle système, la propriété Role du contrôle de base est retournée. Toutefois, la propriété Description étant différente de celle du contrôle de base, cette propriété est remplacée.

HRESULT CAccCustomButton::Initialize( HWND hWnd, HINSTANCE hInst )
{
.
.
.
    hr = CreateStdAccessibleObject( m_hWnd, 
                                    OBJID_CLIENT, 
                                    IID_IAccessible, 
                                    (void **) &m__pAccDefaultButton );
.
.
.
}

STDMETHODIMP CAccCustomButton::get_accRole( VARIANT varID )
{
    return m_pAccDefaultButton->get_accRole(varID);
}


STDMETHODIMP CAccCustomButton::get_accDescription( VARIANT varChild,
                                                   BSTR* pszDesc )
{
    TCHAR   szString[256];
    OLECHAR wszString[256];

    LoadString( m_hInst, ID_DESCRIPTION, szString, 256 );
    MultiByteToWideChar( CP_ACP, 0, szString, -1, wszString, 256 );
   *pszDesc = SysAllocString( wszString );
   if ( !pszDesc )
       return S_OK;
   else
       return E_OUTOFMEMORY;
}

Pour plus d’informations sur les propriétés et méthodes IAccessible des contrôles système, consultez Annexe A : Informations de référence sur les éléments d’interface utilisateur pris en charge.