Discussion :

[xwindoo]

Bonjour à tous,

j'essaie actuellement de créer un contrôle de toutes pièces, c'est-à-dire comme on ferait pour créer une fenêtre classique : j'enregistre ma classe (RegisterClass) et je gère les messages dans une fonction WndProc; mais avec des propriétés particulières (comme n'importe quel contrôle de base de windows : bouton...). Je ne souhaite pas partir d'un contrôle déjà existant (même simple comme un static) et redéfinir ma propre WndProc.

Voici mon problème :
Pour faire simple : que dois-je gérer dans ma fonction WndProc ? Quels messages doivent obligatoirement être traités et que retourner pour les messages non gérés ? J'ai essayé DefWindowProc, mais ce n'est pas très concluant, je me retrouve avec une barre de titre et une bordure bleues. J'ai également essayé de retourner 0 : dans ce cas, ça fige la fenêtre parent. Dans tous les cas, mon contrôle ne se déplace pas avec la fenêtre.

Pour le moment je ne gère pas grand chose : WM_NCCREATE et WM_NCDESTROY, qui me permettent de gérer une structure de donnée propre au contrôle (WndExtra de WNDCLASSEX). J'ai remarqué que retourner 1 lors de l'envoie de WM_NCACTIVATE, empêchait de figer la fenêtre parent.

Voila, j'espère avoir été assez clair.
Merci d'avance,
XWindoo

[Médinoc]

Je dirais surtout WM_PAINT + WM_PRINTCLIENT, ainsi que WM_GETDLGCODE.
Pour les bordures, tu peux soit supposer que l'utilisateur sait ce qu'il fait et n'activera pas WS_BORDER ou WS_CAPTION (qui inclus WS_BORDER), ou tu peux carrément te faire une bordure personalisée (WM_NCCALCSIZE + WM_NCHITTEST + WM_NCPAINT)

Si tu veux que le contrôle puisse avoir le focus, en plus de le préciser dans WM_GETDLGCODE, tu dois aussi indiquer graphiquement que tu l'as ou non, en réponse à WM_GETFOCUS et WM_KILLFOCUS.

[xwindoo]

Merci pour ta réponse.

lorsque je créer mon contrôle, je met pour le moment que le style WS_VISIBLE. Mais lorsque je fais appel à DefWindowProc, je me retrouve quand même avec une barre de titre et de bordures.

Sinon pour les messages, WM_PAINT je suis d'accord, mais WM_PRINTCLIENT n'est pas destiné à l'utilisateur du contrôle ? J'ai lu ça sur MSDN. WM_GETDLGCODE, je ne pense pas m'en servir tout de suite.


Dois-je utilisé DefWindowProc quand même ?
Et quel message gérer pour que le contrôle se déplace en même temps que la fenêtre ?

[xwindoo]

Voici les message envoyé au contrôle, dans l'ordre juste après la création (récupérés en débugant) :

WM_GETMINMAXINFO
WM_NCCREATE
WM_NCCALCSIZE
WM_CREATE
WM_SHOWWINDOW
WM_WINDOWPOSCHANGING
WM_NCACTIVATE
WM_ACTIVATE
WM_SETFOCUS
WM_NCPAINT
WM_ERASEBKGND
WM_WINDOWPOSCHANGED
WM_GETTEXT
WM_NCCALCSIZE
WM_NCPAINT
WM_ERASEBKGND
WM_SIZE
WM_MOVE
WM_SYNCPAINT
WM_NCACTIVATE
WM_PAINT

[Médinoc]

1. Un contrôle doit être WS_CHILD.
2. DefWindowProc() doit être appelée pour tous les messages non-traités. Les exceptions sont des fenêtres spéciales qui appellent une autre DefXxxxxProc() (par exemple, les fenêtres d'une Multi-Document Interface (MDI) utilisent DefFrameProc() et DefMDIChildProc()), mais dans tous les cas, DefWindowProc() est appelée quelque part.
3. WM_PRINTCLIENT est plus ou moins facultatif, mais c'est bien au contrôle qu'il est destiné.

[xwindoo]

Je viens de tester WS_CHILD, ça va déjà beaucoup mieux . DefWindowProc ne pose plus de problème. Merci beaucoup.

Il vaut mieux utiliser WM_PAINT ou WM_PRINTCLIENT ou les deux ?

[Médinoc]

WM_PAINT est obligatoire. WM_PRINTCLIENT est moins utilisé, mais il est de bon ton d'implémenter les deux.

[xwindoo]

Ok. Merci pour toutes ces réponses