je souhaiterais cr=E9er un contr=F4le de toutes pi=E8ces, donc sans reparti=
r
m=EAme sur la base d'un contr=F4le simple (static). Pour cela j'enregistre
une classe comme on pourrai le faire pour une fen=EAtre classique
(RegisterClass); et je traite les messages envoy=E9s dans ma fonction
WndProc : WM_NCCREATE, WM_CREATE, WM_NCDESTROY, WM_PAINT
principalement (J'appelle DefWindowProc pour tous les messages non
g=E9r=E9s).
Est-ce une bonne solution de le faire de cette mani=E8re (apparemment
non) ? Si non, Comment faut-t-il s'y prendre ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Christian ASTOR
XWindoo wrote:
je souhaiterais créer un contrôle de toutes pièces, donc sans repartir même sur la base d'un contrôle simple (static). Pour cela j'enregistre une classe comme on pourrai le faire pour une fenêtre classique (RegisterClass); et je traite les messages envoyés dans ma fonction WndProc : WM_NCCREATE, WM_CREATE, WM_NCDESTROY, WM_PAINT principalement (J'appelle DefWindowProc pour tous les messages non gérés).
Est-ce une bonne solution de le faire de cette manière (apparemment non) ? Si non, Comment faut-t-il s'y prendre ?
La méthode standard est par Superclassing (à partir d'un Static ou autre) Car rien que pour un Static par exemple, la Window procedure originale traite un très grand nombre de messages standards qu'il serait trop lourd de recoder (genre WM_GETDLGCODE, WM_ENABLE, WM_SETFONT, etc...)
XWindoo wrote:
je souhaiterais créer un contrôle de toutes pièces, donc sans repartir
même sur la base d'un contrôle simple (static). Pour cela j'enregistre
une classe comme on pourrai le faire pour une fenêtre classique
(RegisterClass); et je traite les messages envoyés dans ma fonction
WndProc : WM_NCCREATE, WM_CREATE, WM_NCDESTROY, WM_PAINT
principalement (J'appelle DefWindowProc pour tous les messages non
gérés).
Est-ce une bonne solution de le faire de cette manière (apparemment
non) ? Si non, Comment faut-t-il s'y prendre ?
La méthode standard est par Superclassing (à partir d'un Static ou autre)
Car rien que pour un Static par exemple, la Window procedure originale
traite un très grand nombre de messages standards qu'il serait trop
lourd de recoder (genre WM_GETDLGCODE, WM_ENABLE, WM_SETFONT, etc...)
je souhaiterais créer un contrôle de toutes pièces, donc sans repartir même sur la base d'un contrôle simple (static). Pour cela j'enregistre une classe comme on pourrai le faire pour une fenêtre classique (RegisterClass); et je traite les messages envoyés dans ma fonction WndProc : WM_NCCREATE, WM_CREATE, WM_NCDESTROY, WM_PAINT principalement (J'appelle DefWindowProc pour tous les messages non gérés).
Est-ce une bonne solution de le faire de cette manière (apparemment non) ? Si non, Comment faut-t-il s'y prendre ?
La méthode standard est par Superclassing (à partir d'un Static ou autre) Car rien que pour un Static par exemple, la Window procedure originale traite un très grand nombre de messages standards qu'il serait trop lourd de recoder (genre WM_GETDLGCODE, WM_ENABLE, WM_SETFONT, etc...)
Vincent Burel
Pour faire un control à soi, un control sur mesure. je propose un tutorial ici : http://pagesperso-orange.fr/vb-audio/fr/pub/programming/Lesson04/Lesson04.htm
Et pour répondre à votre question, OUI c'est presque obligatoire, à partir du moment où vous voulez faire un controle qui ne ressemble à aucun de ceux fournits par le système, il faut se le faire soi même. D'ailleurs faire une application sous Windows commence le plus souvent par la fabrication d'un control sur mesure : la fenetre principale.
VB
"XWindoo" wrote in message news: Bonjour à tous,
je souhaiterais créer un contrôle de toutes pièces, donc sans repartir même sur la base d'un contrôle simple (static). Pour cela j'enregistre une classe comme on pourrai le faire pour une fenêtre classique (RegisterClass); et je traite les messages envoyés dans ma fonction WndProc : WM_NCCREATE, WM_CREATE, WM_NCDESTROY, WM_PAINT principalement (J'appelle DefWindowProc pour tous les messages non gérés).
Est-ce une bonne solution de le faire de cette manière (apparemment non) ? Si non, Comment faut-t-il s'y prendre ?
Je vous remercie par avance, XWindoo
Pour faire un control à soi, un control sur mesure.
je propose un tutorial ici :
http://pagesperso-orange.fr/vb-audio/fr/pub/programming/Lesson04/Lesson04.htm
Et pour répondre à votre question, OUI c'est presque obligatoire, à partir
du moment où vous voulez faire un controle qui ne ressemble à aucun de ceux
fournits par le système, il faut se le faire soi même. D'ailleurs faire une
application sous Windows commence le plus souvent par la fabrication d'un
control sur mesure : la fenetre principale.
VB
"XWindoo" <khan.temujin@gmail.com> wrote in message
news:452cadd1-634f-4675-bbf5-1e429f2d5c64@b38g2000prf.googlegroups.com...
Bonjour à tous,
je souhaiterais créer un contrôle de toutes pièces, donc sans repartir
même sur la base d'un contrôle simple (static). Pour cela j'enregistre
une classe comme on pourrai le faire pour une fenêtre classique
(RegisterClass); et je traite les messages envoyés dans ma fonction
WndProc : WM_NCCREATE, WM_CREATE, WM_NCDESTROY, WM_PAINT
principalement (J'appelle DefWindowProc pour tous les messages non
gérés).
Est-ce une bonne solution de le faire de cette manière (apparemment
non) ? Si non, Comment faut-t-il s'y prendre ?
Pour faire un control à soi, un control sur mesure. je propose un tutorial ici : http://pagesperso-orange.fr/vb-audio/fr/pub/programming/Lesson04/Lesson04.htm
Et pour répondre à votre question, OUI c'est presque obligatoire, à partir du moment où vous voulez faire un controle qui ne ressemble à aucun de ceux fournits par le système, il faut se le faire soi même. D'ailleurs faire une application sous Windows commence le plus souvent par la fabrication d'un control sur mesure : la fenetre principale.
VB
"XWindoo" wrote in message news: Bonjour à tous,
je souhaiterais créer un contrôle de toutes pièces, donc sans repartir même sur la base d'un contrôle simple (static). Pour cela j'enregistre une classe comme on pourrai le faire pour une fenêtre classique (RegisterClass); et je traite les messages envoyés dans ma fonction WndProc : WM_NCCREATE, WM_CREATE, WM_NCDESTROY, WM_PAINT principalement (J'appelle DefWindowProc pour tous les messages non gérés).
Est-ce une bonne solution de le faire de cette manière (apparemment non) ? Si non, Comment faut-t-il s'y prendre ?
Je vous remercie par avance, XWindoo
XWindoo
Merci pour vos réponses.
Donc, il vaut mieux partir d'un contrôle et en crée un nouveau par superclassing. Mais la méthode générale, excepté le point de départ, reste celle qu'il faut employer !?
Vincent Burel > Merci pour le lien, il va peut-être m'aider ;)
XWindoo
Merci pour vos réponses.
Donc, il vaut mieux partir d'un contrôle et en crée un nouveau par
superclassing.
Mais la méthode générale, excepté le point de départ, reste celle
qu'il faut employer !?
Vincent Burel > Merci pour le lien, il va peut-être m'aider ;)
Donc, il vaut mieux partir d'un contrôle et en crée un nouveau par superclassing. Mais la méthode générale, excepté le point de départ, reste celle qu'il faut employer !?
Vincent Burel > Merci pour le lien, il va peut-être m'aider ;)
XWindoo
Vincent Burel
"XWindoo" wrote in message news: Merci pour vos réponses.
Donc, il vaut mieux partir d'un contrôle et en crée un nouveau par
superclassing.
Mais la méthode générale, excepté le point de départ, reste celle
qu'il faut employer !?
Non, on utilise généralement le sous-classement (subclassing) quand on veux modifier le comportement d'un control Window.
Si vous avez besoin d'un control particulier, qui n'a rien à voir avec un controle Windows usuel, il faut vous créer un controle perso, avec votre classe de fenetre etc...
Vincent Burel > Merci pour le lien, il va peut-être m'aider ;)
j'espère bien ! :-)
VB
"XWindoo" <khan.temujin@gmail.com> wrote in message
news:a7473f56-b752-4d5e-848e-6c39e8aa09eb@r37g2000prr.googlegroups.com...
Merci pour vos réponses.
Donc, il vaut mieux partir d'un contrôle et en crée un nouveau par
superclassing.
Mais la méthode générale, excepté le point de départ, reste celle
qu'il faut employer !?
Non, on utilise généralement le sous-classement (subclassing) quand on veux
modifier le comportement d'un control Window.
Si vous avez besoin d'un control particulier, qui n'a rien à voir avec un
controle Windows usuel, il faut vous créer un controle perso, avec votre
classe de fenetre etc...
Vincent Burel > Merci pour le lien, il va peut-être m'aider ;)
"XWindoo" wrote in message news: Merci pour vos réponses.
Donc, il vaut mieux partir d'un contrôle et en crée un nouveau par
superclassing.
Mais la méthode générale, excepté le point de départ, reste celle
qu'il faut employer !?
Non, on utilise généralement le sous-classement (subclassing) quand on veux modifier le comportement d'un control Window.
Si vous avez besoin d'un control particulier, qui n'a rien à voir avec un controle Windows usuel, il faut vous créer un controle perso, avec votre classe de fenetre etc...
Vincent Burel > Merci pour le lien, il va peut-être m'aider ;)
j'espère bien ! :-)
VB
Jerome
Vincent Burel wrote:
"XWindoo" wrote in message news: Merci pour vos réponses.
Donc, il vaut mieux partir d'un contrôle et en crée un nouveau par
superclassing.
Mais la méthode générale, excepté le point de départ, reste celle
qu'il faut employer !?
Non, on utilise généralement le sous-classement (subclassing) quand on veux modifier le comportement d'un control Window.
Si vous avez besoin d'un control particulier, qui n'a rien à voir avec un controle Windows usuel, il faut vous créer un controle perso, avec votre classe de fenetre etc...
C'est là qu'on fait le "superclassing", pour les controles "custom" C'est inutile de repartir de rien.
Vincent Burel wrote:
"XWindoo" <khan.temujin@gmail.com> wrote in message
news:a7473f56-b752-4d5e-848e-6c39e8aa09eb@r37g2000prr.googlegroups.com...
Merci pour vos réponses.
Donc, il vaut mieux partir d'un contrôle et en crée un nouveau par
superclassing.
Mais la méthode générale, excepté le point de départ, reste celle
qu'il faut employer !?
Non, on utilise généralement le sous-classement (subclassing) quand on veux
modifier le comportement d'un control Window.
Si vous avez besoin d'un control particulier, qui n'a rien à voir avec un
controle Windows usuel, il faut vous créer un controle perso, avec votre
classe de fenetre etc...
C'est là qu'on fait le "superclassing", pour les controles "custom"
C'est inutile de repartir de rien.
"XWindoo" wrote in message news: Merci pour vos réponses.
Donc, il vaut mieux partir d'un contrôle et en crée un nouveau par
superclassing.
Mais la méthode générale, excepté le point de départ, reste celle
qu'il faut employer !?
Non, on utilise généralement le sous-classement (subclassing) quand on veux modifier le comportement d'un control Window.
Si vous avez besoin d'un control particulier, qui n'a rien à voir avec un controle Windows usuel, il faut vous créer un controle perso, avec votre classe de fenetre etc...
C'est là qu'on fait le "superclassing", pour les controles "custom" C'est inutile de repartir de rien.
Vincent Burel
"Jerome" wrote in message news:gf6f06$dra$
Vincent Burel wrote: > "XWindoo" wrote in message >
news:
> Merci pour vos réponses. > >> Donc, il vaut mieux partir d'un contrôle et en crée un nouveau par > superclassing. >> Mais la méthode générale, excepté le point de départ, reste celle > qu'il faut employer !? > > Non, on utilise généralement le sous-classement (subclassing) quand on
veux
> modifier le comportement d'un control Window. > > Si vous avez besoin d'un control particulier, qui n'a rien à voir avec
un
> controle Windows usuel, il faut vous créer un controle perso, avec votre > classe de fenetre etc...
C'est là qu'on fait le "superclassing", pour les controles "custom" C'est inutile de repartir de rien.
Chacun fait comme il veut, mais pour faire un nouveau controle, faire du subclassing est aussi lourd (voire plus) que de déclarer sa classe de fenêtre. De plus faire du sous-classement d'un controle existant , c'est prendre le risque d'avoir un controle qui a un comportement non cerné, non défini dans son entier.
VB
PS: ca fait deux fois que je vois le terme "superclassing", on dit plus "SubClassing" ? ou on parle pas de la même chose ?
"Jerome" <jerome@park.com> wrote in message
news:gf6f06$dra$1@news.albasani.net...
Vincent Burel wrote:
> "XWindoo" <khan.temujin@gmail.com> wrote in message
>
> Merci pour vos réponses.
>
>> Donc, il vaut mieux partir d'un contrôle et en crée un nouveau par
> superclassing.
>> Mais la méthode générale, excepté le point de départ, reste celle
> qu'il faut employer !?
>
> Non, on utilise généralement le sous-classement (subclassing) quand on
veux
> modifier le comportement d'un control Window.
>
> Si vous avez besoin d'un control particulier, qui n'a rien à voir avec
un
> controle Windows usuel, il faut vous créer un controle perso, avec votre
> classe de fenetre etc...
C'est là qu'on fait le "superclassing", pour les controles "custom"
C'est inutile de repartir de rien.
Chacun fait comme il veut, mais pour faire un nouveau controle, faire du
subclassing est aussi lourd (voire plus) que de déclarer sa classe de
fenêtre. De plus faire du sous-classement d'un controle existant , c'est
prendre le risque d'avoir un controle qui a un comportement non cerné, non
défini dans son entier.
VB
PS: ca fait deux fois que je vois le terme "superclassing", on dit plus
"SubClassing" ? ou on parle pas de la même chose ?
Vincent Burel wrote: > "XWindoo" wrote in message >
news:
> Merci pour vos réponses. > >> Donc, il vaut mieux partir d'un contrôle et en crée un nouveau par > superclassing. >> Mais la méthode générale, excepté le point de départ, reste celle > qu'il faut employer !? > > Non, on utilise généralement le sous-classement (subclassing) quand on
veux
> modifier le comportement d'un control Window. > > Si vous avez besoin d'un control particulier, qui n'a rien à voir avec
un
> controle Windows usuel, il faut vous créer un controle perso, avec votre > classe de fenetre etc...
C'est là qu'on fait le "superclassing", pour les controles "custom" C'est inutile de repartir de rien.
Chacun fait comme il veut, mais pour faire un nouveau controle, faire du subclassing est aussi lourd (voire plus) que de déclarer sa classe de fenêtre. De plus faire du sous-classement d'un controle existant , c'est prendre le risque d'avoir un controle qui a un comportement non cerné, non défini dans son entier.
VB
PS: ca fait deux fois que je vois le terme "superclassing", on dit plus "SubClassing" ? ou on parle pas de la même chose ?
Christian ASTOR
On 10 nov, 09:27, "Vincent Burel" wrote:
PS: ca fait deux fois que je vois le terme "superclassing", on dit plus "SubClassing" ? ou on parle pas de la même chose ?
C'est différent; le Superclassing, c'est pour faire une nouvelle classe de fenêtre à partir de GetClassInfo() Il y a des vieux docs MSDN http://msdn.microsoft.com/en-us/library/ms997565 .aspx
On 10 nov, 09:27, "Vincent Burel" <vincent.bu...@nospam.wanadoo.fr>
wrote:
PS: ca fait deux fois que je vois le terme "superclassing", on dit plus
"SubClassing" ? ou on parle pas de la même chose ?
C'est différent; le Superclassing, c'est pour faire une nouvelle
classe de fenêtre à partir de GetClassInfo()
Il y a des vieux docs MSDN http://msdn.microsoft.com/en-us/library/ms997565 .aspx
PS: ca fait deux fois que je vois le terme "superclassing", on dit plus "SubClassing" ? ou on parle pas de la même chose ?
C'est différent; le Superclassing, c'est pour faire une nouvelle classe de fenêtre à partir de GetClassInfo() Il y a des vieux docs MSDN http://msdn.microsoft.com/en-us/library/ms997565 .aspx
Vincent Burel
ha ok, je ne connaissais pas cette possibilité. Mais je la trouve encore plus lourde le sous-classement...
"Christian ASTOR" wrote in message news: On 10 nov, 09:27, "Vincent Burel" wrote:
PS: ca fait deux fois que je vois le terme "superclassing", on dit plus "SubClassing" ? ou on parle pas de la même chose ?
C'est différent; le Superclassing, c'est pour faire une nouvelle classe de fenêtre à partir de GetClassInfo() Il y a des vieux docs MSDN http://msdn.microsoft.com/en-us/library/ms997565.aspx
ha ok, je ne connaissais pas cette possibilité.
Mais je la trouve encore plus lourde le sous-classement...
"Christian ASTOR" <castorix@club-internet.fr> wrote in message
news:3bf54b90-609c-4d0d-a276-6cc00fa09fae@v13g2000pro.googlegroups.com...
On 10 nov, 09:27, "Vincent Burel" <vincent.bu...@nospam.wanadoo.fr>
wrote:
PS: ca fait deux fois que je vois le terme "superclassing", on dit plus
"SubClassing" ? ou on parle pas de la même chose ?
C'est différent; le Superclassing, c'est pour faire une nouvelle
classe de fenêtre à partir de GetClassInfo()
Il y a des vieux docs MSDN
http://msdn.microsoft.com/en-us/library/ms997565.aspx
ha ok, je ne connaissais pas cette possibilité. Mais je la trouve encore plus lourde le sous-classement...
"Christian ASTOR" wrote in message news: On 10 nov, 09:27, "Vincent Burel" wrote:
PS: ca fait deux fois que je vois le terme "superclassing", on dit plus "SubClassing" ? ou on parle pas de la même chose ?
C'est différent; le Superclassing, c'est pour faire une nouvelle classe de fenêtre à partir de GetClassInfo() Il y a des vieux docs MSDN http://msdn.microsoft.com/en-us/library/ms997565.aspx
