Partager via

Contrôles ActiveX MFC : sous-classement d'un contrôle Windows

  • Article

Cet article explique le processus de sous-classement d'un contrôle Windows commun pour créer un contrôle ActiveX. Le sous-classement d'un contrôle Windows existant est un moyen rapide de développer un contrôle ActiveX. Le nouveau contrôle a les fonctionnalités du contrôle Windows sous-classé, telles que la peinture et la réponse aux clics de souris. L’exemple DE BOUTON des contrôles ActiveX MFC est un exemple de sous-classe d’un contrôle Windows.

Important

ActiveX est une technologie héritée qui ne doit pas être utilisée pour le nouveau développement. Pour plus d’informations sur les technologies modernes qui remplacent ActiveX, consultez Contrôles ActiveX.

Pour sous-classer un contrôle Windows, effectuez les tâches suivantes :

Substitution de IsSubclassedControl et PreCreateWindow

Pour remplacer PreCreateWindow et IsSubclassedControlajouter les lignes de code suivantes à la protected section de la déclaration de classe de contrôle :

virtual BOOL PreCreateWindow(CREATESTRUCT& cs);
BOOL IsSubclassedControl();

Dans le fichier d'implémentation du contrôle (.CPP), ajoutez les lignes de code suivantes pour implémenter les fonctions remplacées :

// CMyAxSubCtrl::PreCreateWindow - Modify parameters for CreateWindowEx

BOOL CMyAxSubCtrl::PreCreateWindow(CREATESTRUCT& cs)
{
   cs.lpszClass = _T("BUTTON");
   return COleControl::PreCreateWindow(cs);
}

// CMyAxSubCtrl::IsSubclassedControl - This is a subclassed control

BOOL CMyAxSubCtrl::IsSubclassedControl()
{
   return TRUE;
}

Notez que, dans cet exemple, le contrôle de bouton Windows est spécifié dans PreCreateWindow. Toutefois, tous les contrôles Windows standard peuvent être sous-classés. Pour plus d’informations sur les contrôles Windows standard, consultez Contrôles.

Lors de la sous-classe d’un contrôle Windows, vous pouvez spécifier des indicateurs de style de fenêtre (WS_) ou de style de fenêtre étendu (WS_EX_) à utiliser pour créer la fenêtre du contrôle. Vous pouvez définir des valeurs pour ces paramètres dans la PreCreateWindow fonction membre en modifiant les cs.style champs de structure et les champs de cs.dwExStyle structure. Les modifications apportées à ces champs doivent être effectuées à l’aide d’une opération OR pour conserver les indicateurs par défaut définis par classe COleControl. Par exemple, si le contrôle sous-classe le contrôle BUTTON et que vous voulez un contrôle qui apparaisse comme une case à cocher, insérez la ligne de code suivante dans l'implémentation de CSampleCtrl::PreCreateWindow, avant l'instruction RETURN :

cs.style |= BS_CHECKBOX;

Cette opération ajoute l’indicateur de style BS_CHECKo OX, tout en laissant l’indicateur de style par défaut (WS_CHILD) de la classe COleControl intacte.

Modification de la fonction membre OnDraw

Si vous souhaitez que votre contrôle sous-classé conserve la même apparence que le contrôle Windows correspondant, la fonction membre OnDraw du contrôle doit contenir un seul appel à la fonction membre DoSuperclassPaint, comme dans l'exemple suivant :

void CMyAxSubCtrl::OnDraw(CDC* pdc, const CRect& rcBounds, const CRect& /*rcInvalid*/)
{
   if (!pdc)
      return;

   DoSuperclassPaint(pdc, rcBounds);
}

La fonction membre DoSuperclassPaint, implémentée par COleControl, utilise la procédure de fenêtre du contrôle Windows pour dessiner le contrôle dans le contexte matériel spécifié, au sein du rectangle englobant. Cela rend le contrôle visible même s'il n'est pas actif.

Remarque

La DoSuperclassPaint fonction membre fonctionne uniquement avec les types de contrôle qui permettent à un contexte d’appareil d’être transmis en tant que wParam d’un message WM_PAINT. Cela inclut certains des contrôles Windows standard, tels que SCROLLBAR et BUTTON, et tous les contrôles courants. Pour les contrôles qui ne prennent pas en charge ce comportement, vous devez fournir votre propre code pour afficher un contrôle inactif correctement.

Gestion des messages de fenêtre Réflexions ed

Les contrôles Windows envoient généralement certains messages de fenêtre à leur fenêtre parente. Certains de ces messages, tels que WM_COMMAND, fournissent une notification d’une action par l’utilisateur. D’autres, comme WM_CTLCOLOR, sont utilisées pour obtenir des informations à partir de la fenêtre parente. Un contrôle ActiveX communique généralement avec la fenêtre parente par d'autres moyens. Les notifications sont communiquées en expédiant des événements (envoi de notifications d'événements) et des informations sur le conteneur de contrôle sont obtenues lors de l'accès aux propriétés ambiantes du conteneur. Comme ces techniques de communication existent, les conteneurs de contrôle ActiveX ne sont pas sensés traiter les messages de fenêtre envoyés par le contrôle.

Pour empêcher le conteneur de recevoir les messages de fenêtre envoyés par un contrôle Windows sous-classé, COleControl crée une fenêtre supplémentaire pour servir de parent du contrôle. Cette fenêtre supplémentaire, appelée "réflecteur", n'est créée que pour un contrôle ActiveX qui sous-classe un contrôle Windows et a la même taille et position que la fenêtre de contrôle. La fenêtre réflecteur intercepte certains messages de fenêtre et les envoie au contrôle. Le contrôle, dans sa procédure de fenêtre, peut ensuite traiter ces messages réfléchis en utilisant les actions appropriées pour un contrôle ActiveX (par exemple, déclencher un événement). Consultez les ID de message de fenêtre Réflexions ed pour obtenir la liste des messages windows interceptés et leurs messages reflétés correspondants.

Un conteneur de contrôles ActiveX peut être conçu pour effectuer le renvoi de message lui-même, éliminant le besoin de COleControl de créer la fenêtre de réflection et de réduire la charge d'exécution pour un contrôle Windows sous-classé. COleControldétecte si le conteneur prend en charge cette fonctionnalité en case activée ing pour une propriété message Réflexions ambiante avec la valeur TRUE.

Pour traiter un message de fenêtre réfléchi, ajoutez une entrée à la table des messages de contrôle et implémentez une fonction gestionnaire. Comme les messages réfléchis ne font pas partie de l'ensemble standard de messages définis par Windows, l'Affichage de classes ne prend pas en charge l'ajout de ces gestionnaires de messages. Toutefois, il n'est pas difficile d'ajouter un gestionnaire manuellement.

Pour ajouter un gestionnaire de messages pour un message de fenêtre réfléchi manuellement, procédez comme suit :

  • Dans le fichier .H de la classe de contrôle, déclarez une fonction gestionnaire. La fonction doit avoir un type de retour LRESULTet deux paramètres, avec les types WPARAM et LPARAM, respectivement. Par exemple :

    class CMyAxSubCtrl : public COleControl
{

    protected:
   LRESULT OnOcmCommand(WPARAM wParam, LPARAM lParam);
};

  • Dans la classe de contrôle . Fichier CPP, ajoutez une entrée ON_MESSAGE à la carte des messages. Les paramètres de cette entrée doivent être l'identificateur de message et le nom de la fonction gestionnaire. Par exemple :

    BEGIN_MESSAGE_MAP(CMyAxSubCtrl, COleControl)
   ON_MESSAGE(OCM_COMMAND, &CMyAxSubCtrl::OnOcmCommand)
END_MESSAGE_MAP()

  • Aussi dans le . Fichier CPP, implémentez la OnOcmCommand fonction membre pour traiter le message réfléchi. Les paramètres wParam et lParam sont identiques à ceux du message de fenêtre d’origine.

Pour obtenir un exemple de traitement des messages réfléchis, reportez-vous à l’exemple DE BOUTON des contrôles ActiveX MFC. Il illustre un OnOcmCommand gestionnaire qui détecte le code de notification BN_CLICKED et répond en mettant (envoyant) un Click événement.

Voir aussi

Contrôles ActiveX MFC