comment acheminer un message vers le standard WNDPROC du contrôle

Lorsqu’un contrôle de fenêtre standard (par exemple un contrôle "EDIT" ) est créé, son WNDPROC est défini comme faisant partie de la classe de fenêtre (par exemple, "EDIT" possède un WNDPROC spécifique conçu pour que la fenêtre s’affiche et se comporte comme un contrôle d’édition). ).

MFC vous permet d’interagir avec de tels contrôles via leurs classes wrapper, telles que les wrappers CEdit les messages spécialisés pour un contrôle de fenêtre "EDIT" .

MFC vous permet également de lier une instance d’une fenêtre "EDIT" à une sous-classe C ++ de CEdit, par exemple CMyEdit , où vous pouvez remplacer les fonctions virtuelles héritées de CEdit et CWnd , et définir une table de messages pour accéder / remplacer les messages envoyé à l’instance de la fenêtre elle-même.

Il y a CWnd :: Default () , qui appelle this-> DefWndProc avec les arguments de message actuels. Cela semble rechercher le WNDPROC pour le HWND WNDPROC il est associé. Donc, est-ce la bonne réponse: appelez DefWndProc () (ou tout aussi, Default ()), qui le transmettra au WNDPROC du contrôle Windows?

Evidemment, cela diffère des autres gestionnaires de tables de messages qui peuvent renvoyer FALSE pour indiquer qu’ils ne traitaient pas le message, et MFC acheminera automatiquement le message vers la hiérarchie d’inheritance des classes vers le gestionnaire de messages suivant pour ce message ou, je suppose. , à Default () pour être géré par le WNDPROC natif?

Si je définis un gestionnaire de messages arbitraire, disons pour WM_SETTEXT, quelle est la bonne façon de transmettre ce message au WNDPROC "EDIT" ?

J’aimerais aussi savoir s’il existe un moyen de transmettre le message à une superclasse (hiérarchie de classes C ++) pour la manipulation? De nombreux gestionnaires de style OnXXX ont un moyen de le faire, mais existe-t-il un mécanisme qui fonctionne pour les gestionnaires ON_MESSAGE?

 class CDynamicMenuControlEdit : public CEdit { ... LRESULT OnSetText(WPARAM wParam, LPARAM lParam); ... } BEGIN_MESSAGE_MAP(CDynamicMenuControlEdit, CEdit) ... ON_MESSAGE(WM_SETTEXT, OnSetText) ... END_MESSAGE_MAP() LRESULT CDynamicMenuControlEdit::OnSetText( WPARAM wParam, // not used; must be zero LPARAM lParam // window-text ssortingng (LPCTSTR) ) { if (m_bHasFocus) { // do normal thing // !!! THIS IS MY QUESTION: IS THIS CALLING EDIT's WNDPROC, or ::DefWinProc()? !!! return DefWindowProc(WM_SETTEXT, wParam, lParam); } ... } 

Clarification

Vous pouvez avoir plusieurs sous-classes MFC au niveau C ++ –

C hérite donc de B qui hérite de A, où A est une classe MFC (par exemple, CEdit ).

Chacun d’entre eux peut avoir une table de messages MFC – par exemple BEGIN_MESSAGE_MAPEND_MESSAGE_MAP qui peut avoir un gestionnaire pour tout message Windows arbitraire, tel que WM_MESSAGE(WM_SETTEXT, OnSetText) – et que le membre OnSetText n’est pas nécessairement virtuel – uniquement un membre statique (chaque sous-classe MFC peut acheminer ce message de manière arbitraire).

Ma question est la suivante: comme une entrée de répartition WM_MESSAGE n’a pas de valeur de retour, comment puis-je autoriser MFC à monter les tables de dissortingbution MFC de C vers B avant de les renvoyer aux wndproc de la classe EDIT de Windows réelle?

Ou est-ce que toutes ces entrées destinées au niveau de conception du MFC NE DOIVENT PAS être parcourues? c’est-à-dire que le répartiteur de la couche la plus sous-classée est censé être le seul appelé? Et si elle souhaite exploiter un membre hérité, elle doit effectuer manuellement cet appel – MFC n’a tout simplement pas de structure générique spécifique pour cela?

L’appel de Default() provoquera le traitement “normal” qui aurait eu lieu en réponse à un message. Je ne suis pas tout à fait clair sur ce que vous essayez de réaliser, mais il me semble que l’appel de Default() est ce que vous voulez faire.

Si vous regardez beaucoup de gestionnaires de messages Windows dans les gestionnaires CWnd (et les gestionnaires de classes dérivés de CWnd tels que CEdit ), vous verrez qu’ils appellent Default() .

En d’autres termes, cette valeur Default() utilisera tous les parameters du message d’origine – vous ne pouvez pas les modifier.

Tu le fais bien. CWnd :: DefWindowProc () utilise le WINDOWPROC dont vous avez sous-classé et appelle la procédure de fenêtre de la fenêtre EDIT.