J'ai une form principal qui contient de nombreuse forme enfant. J'aurais
besoin d'avoir un évènement qui se déclenche à chaque click de la souris à
quelques endroits que celui soit fait.
En fait, je pourrait emplémenter tous les évènements click des contrôles et
déclencher un évènement dans la forme principale mais cela serait atrocement
long. J'aurais donc besoin d'un évènement qui se déclenche dans la form
principale des que l'utilisateur click sur la souris (c'est pour faire
disparaitre un menu)
> Moi j'aimerais savoir qu'elles sont les conséquences de chinder le système des messages ainsi ?
En terme de performance et surtout de sécurité ?
Aun niveau performance, on ralentit la gestion de tous les autres messages, le temps d'exécuter un if, ce qui est totalement négligeable pour une IHM. Niveau sécurité : on substitue une méthode d'une classe parent : soit on respecte son contrat et alors pas de problème, soit on fait n'importe quoi et alors là il y a évidemment risque de comportements inattendus, mais ça c'est valable tout le temps.
-- Zazar
> Moi j'aimerais savoir qu'elles sont les conséquences de chinder le système
des messages ainsi ?
En terme de performance et surtout de sécurité ?
Aun niveau performance, on ralentit la gestion de tous les autres messages,
le temps d'exécuter un if, ce qui est totalement négligeable pour une IHM.
Niveau sécurité : on substitue une méthode d'une classe parent : soit on
respecte son contrat et alors pas de problème, soit on fait n'importe quoi
et alors là il y a évidemment risque de comportements inattendus, mais ça
c'est valable tout le temps.
> Moi j'aimerais savoir qu'elles sont les conséquences de chinder le système des messages ainsi ?
En terme de performance et surtout de sécurité ?
Aun niveau performance, on ralentit la gestion de tous les autres messages, le temps d'exécuter un if, ce qui est totalement négligeable pour une IHM. Niveau sécurité : on substitue une méthode d'une classe parent : soit on respecte son contrat et alors pas de problème, soit on fait n'importe quoi et alors là il y a évidemment risque de comportements inattendus, mais ça c'est valable tout le temps.
-- Zazar
Julien Adam
Je pense plutot pour ma part que c'est "caché" parce que ça fait partie de la "legacy win32" que Microsoft essaye petit à petit de faire disparaitre au profit d'interfaces de plus haut niveau comme les Windows.Forms. Ce qui ne veut pas dire que ça ne marche pas ou que ça entraine des problème particuliers.
Et en plus, ce n'est pas vraiment caché. Si il y a une fonction protected WndProc c'est bien pour ça. Si vraiment c'était un truc à bannir totalement, Microsoft aurait mis private au lieu de protected.
Toute appli Win32 gère une boucle de messages et intercepte ou du moins, peut intercepter, ce genre de messages. Je pense que le mécanisme a fait ses preuves ...
Julien Adam
"Bismark Prods" <xanaia#nospam#@urbanet.ch> wrote in message news:eul%
Bonjour Patrick,
Je ne parle évidemment pas de la sécurité anti-virus ! mais de la sécurité et la stabilité dans les threads ! Si il était anodin d'utiliser et d'intercepter les messages systèmes destinés à l'application, cette possibilité serait offerte de façon transparente, Or ce n'est pas le cas.
Alors ma tendance naturelle à ne pas bénir le pain gratuit me fait douter ... C'est pas parce qu'on peut faire qqch que c'est forcément bien...
Bonne journée
Bismark
Je pense plutot pour ma part que c'est "caché" parce que ça fait partie de
la "legacy win32" que Microsoft essaye petit à petit de faire disparaitre au
profit d'interfaces de plus haut niveau comme les Windows.Forms. Ce qui ne
veut pas dire que ça ne marche pas ou que ça entraine des problème
particuliers.
Et en plus, ce n'est pas vraiment caché. Si il y a une fonction protected
WndProc c'est bien pour ça. Si vraiment c'était un truc à bannir totalement,
Microsoft aurait mis private au lieu de protected.
Toute appli Win32 gère une boucle de messages et intercepte ou du moins,
peut intercepter, ce genre de messages. Je pense que le mécanisme a fait ses
preuves ...
Julien Adam
"Bismark Prods" <xanaia#nospam#@urbanet.ch> wrote in message
news:eul%23F5hcEHA.1152@TK2MSFTNGP09.phx.gbl...
Bonjour Patrick,
Je ne parle évidemment pas de la sécurité anti-virus ! mais de la sécurité
et la stabilité dans les threads ! Si il était anodin d'utiliser et
d'intercepter les messages systèmes destinés à l'application, cette
possibilité serait offerte de façon transparente, Or ce n'est pas le cas.
Alors ma tendance naturelle à ne pas bénir le pain gratuit me fait douter
... C'est pas parce qu'on peut faire qqch que c'est forcément bien...
Je pense plutot pour ma part que c'est "caché" parce que ça fait partie de la "legacy win32" que Microsoft essaye petit à petit de faire disparaitre au profit d'interfaces de plus haut niveau comme les Windows.Forms. Ce qui ne veut pas dire que ça ne marche pas ou que ça entraine des problème particuliers.
Et en plus, ce n'est pas vraiment caché. Si il y a une fonction protected WndProc c'est bien pour ça. Si vraiment c'était un truc à bannir totalement, Microsoft aurait mis private au lieu de protected.
Toute appli Win32 gère une boucle de messages et intercepte ou du moins, peut intercepter, ce genre de messages. Je pense que le mécanisme a fait ses preuves ...
Julien Adam
"Bismark Prods" <xanaia#nospam#@urbanet.ch> wrote in message news:eul%
Bonjour Patrick,
Je ne parle évidemment pas de la sécurité anti-virus ! mais de la sécurité et la stabilité dans les threads ! Si il était anodin d'utiliser et d'intercepter les messages systèmes destinés à l'application, cette possibilité serait offerte de façon transparente, Or ce n'est pas le cas.
Alors ma tendance naturelle à ne pas bénir le pain gratuit me fait douter ... C'est pas parce qu'on peut faire qqch que c'est forcément bien...
Bonne journée
Bismark
Bismark Prods
C'est parce que vous m'avez mal compris ! Mon idée était plus directement orientée sur ce qui doit être fait par le processeur ... dans une optique *assembleur*
> je ne vois pas par quelle opération du saint-esprit je > pourrais gérer 20 objets sans écrire au minimum 20 lignes ? à un endroit ou > à un autre ? non ? est-ce que j'ai tord ?
Foreach (IMyInterface myObj in myCollection) myObj.DoSomething();
2 lignes pour effectuer une action sur autant d'objets que vous voulez. Personnellement, j'ai tendance, à considérer que si je dois effectuer le même genre d'actions sur des objets, et que je n'ai pas un moyen simple de le faire sur tous en même temps, c'est que j'ai un problème
d'architecture.
J'irais même à dire que c'est indispensable pour maintenir l'application, sinon si dans 2 mois vous voulez rajouter un n+1 ième objet du même genre, il va falloir retrouver toutes les parties de votre code où vous avez
besoin
de le manipuler.
-- Zazar
C'est parce que vous m'avez mal compris ! Mon idée était plus directement
orientée sur ce qui doit être fait par le processeur ... dans une optique
*assembleur*
"Zazar" <DILAVNI.nicolas.prats@iie.cnam.fr.INVALID> a écrit dans le message
de news:eEZBl0tcEHA.4092@TK2MSFTNGP11.phx.gbl...
Bonjour,
> je ne vois pas par quelle opération du saint-esprit je
> pourrais gérer 20 objets sans écrire au minimum 20 lignes ? à un endroit
ou
> à un autre ? non ? est-ce que j'ai tord ?
Foreach (IMyInterface myObj in myCollection)
myObj.DoSomething();
2 lignes pour effectuer une action sur autant d'objets que vous voulez.
Personnellement, j'ai tendance, à considérer que si je dois effectuer le
même genre d'actions sur des objets, et que je n'ai pas un moyen simple de
le faire sur tous en même temps, c'est que j'ai un problème
d'architecture.
J'irais même à dire que c'est indispensable pour maintenir l'application,
sinon si dans 2 mois vous voulez rajouter un n+1 ième objet du même genre,
il va falloir retrouver toutes les parties de votre code où vous avez
C'est parce que vous m'avez mal compris ! Mon idée était plus directement orientée sur ce qui doit être fait par le processeur ... dans une optique *assembleur*
> je ne vois pas par quelle opération du saint-esprit je > pourrais gérer 20 objets sans écrire au minimum 20 lignes ? à un endroit ou > à un autre ? non ? est-ce que j'ai tord ?
Foreach (IMyInterface myObj in myCollection) myObj.DoSomething();
2 lignes pour effectuer une action sur autant d'objets que vous voulez. Personnellement, j'ai tendance, à considérer que si je dois effectuer le même genre d'actions sur des objets, et que je n'ai pas un moyen simple de le faire sur tous en même temps, c'est que j'ai un problème
d'architecture.
J'irais même à dire que c'est indispensable pour maintenir l'application, sinon si dans 2 mois vous voulez rajouter un n+1 ième objet du même genre, il va falloir retrouver toutes les parties de votre code où vous avez
besoin
de le manipuler.
-- Zazar
Zazar
> C'est parce que vous m'avez mal compris ! Mon idée était plus directement orientée sur ce qui doit être fait par le processeur ... dans une optique *assembleur*
Ca mériterait de définir opération et objets référencés, et il y aurait quelques trucs à dire, mais je comprends ce que vous vouliez dire.
-- Zazar
> C'est parce que vous m'avez mal compris ! Mon idée était plus directement
orientée sur ce qui doit être fait par le processeur ... dans une optique
*assembleur*
> C'est parce que vous m'avez mal compris ! Mon idée était plus directement orientée sur ce qui doit être fait par le processeur ... dans une optique *assembleur*
