Discussion :

[giova_fr]

Bonsoir.

Je m'embrouille un peu l'esprit, pourriez vous eclairer ma lanterne en parlant du lien (si il existe) entre les Winform, les evenements, et les messages...

Rapidement quelques questions qui exposent ma confusion
(les lire toutes plutot que de répondre une a une sera préférable je pense)

Un message windows n'est pas un evenement n'est ce pas?

Prennons un exemple : peut on dire que lorsqu'une fenetre doit etre redessinée, il y a postage du message WM_PAINT qui une fois lu par WndProc déclenche l'évenement Paint ?

Si je fais un programme avec plusieurs Forms affichées. Est ce que chaque Form a son propre QueueMessage? Si oui, ca doit jouer sur les performances non?


Je viens de faire un executable, sans Form, juste avec un notifyicon et son ContextMenu. La dessus, pas de probleme. Mais je veux intercepter ses messages, comme on le ferait en dérivant WndProc dans une Form. Seulement je ne trouve pas la methode.... Quelqu'un aurait une piste la dessus svp?

[SirJulio]

Salut,

juste pour le notifyicon, en fait le probleme, est que il existe bien un wndproc (qui en fait capte, les wndproc d'une form créé pour l'occasion) mais tout est private. En clair, a part recréer complement une classe de notifyicon, tu ne pourras pas intercepter ces messages.

J'ai été confronté au probleme, et je n'ai pas trouvé de solution (hormis la recreation d'une classe notifyicon).

Bon courage. =)

[giova_fr]

salut.

Merci pour ta réponse, je tournais en rond à la recherche de cette methode...
Je vais tenter de faire plus simple que "recréer completement la notifyicon". J'ai visual 2008 d'installé, et avec, on a acces aux codes sources des assembly du .NET

Je vais donc chercher la classe notifyicon, et me faire une dll avec une version modifié de celle ci, juste pour changer la visibilité de WndProc

Alors, elle est pas belle la nuit?

[SirJulio]

Juste pour info, il existe des addons pour Reflector qui te permettent de dumper directement une classe d'un assembly en un .cs (plus le nom en tete par contre), pas specialement besoin de VS 2008. =)

Bon courage.

J'ajouterai quand meme, de faire attention, avec ce que tu veux en faire. La licence de 'crosoft sur ces sources est assez stricts.

[giova_fr]

Bon la tache est (sans surprise ) tres fastidieuse, mais aussi extremement instructive !

Je ne pense pas que je vais aller jusqu'au bout de cette idée de reprendre la classe notifyicon.

1. Deja parceque c'est un long travail, il y a surement des solutions plus rapides.
2. Ensuite parceque je suis obligé de reprendre des membres auquel je n'ai pas acces (notamment ce qui se trouve dans System.Windows.Form.NativeMethods) et du coup je risque d'inserer du bug.
3. Et puis comme tu dis ca n'est pas vraiment apprécié par crosoft quand on lis l'entete des sources

Comme dirait mon boss, demain il fera jour, j'y verrai plus clair.

PS : tu parlais peut etre de Lutz Roeder Net Reflector? Si oui, l'avantage de VS 2008, c'est que tu exploite le code directement dans le debugeur, ce qui est tres pratique/rapide/ et instructif...

[tomlev]

Pour répondre à tes autres questions:

Un message windows n'est pas un evenement n'est ce pas?

Ca dépend de la définition que tu donnes à "évènement"... mais ce n'est en effet pas un évènement au sens .NET du terme.

Prennons un exemple : peut on dire que lorsqu'une fenetre doit etre redessinée, il y a postage du message WM_PAINT qui une fois lu par WndProc déclenche l'évenement Paint ?

Oui, c'est exactement ce qui se passe... enfin il me semble

Si je fais un programme avec plusieurs Forms affichées. Est ce que chaque Form a son propre QueueMessage? Si oui, ca doit jouer sur les performances non?

Oui, chaque Form a sa propre boucle de messages, et généralement son propre thread. Bien sûr ça peut avoir un impact sur les perfs, mais à moins que ton appli ait plusieurs dizaines de Forms je doute que tu t'en rendes compte...

Je viens de faire un executable, sans Form, juste avec un notifyicon et son ContextMenu. La dessus, pas de probleme. Mais je veux intercepter ses messages, comme on le ferait en dérivant WndProc dans une Form. Seulement je ne trouve pas la methode.... Quelqu'un aurait une piste la dessus svp?

Tu peux gérer les évènements publiés par NotifyIcon, mais comme ce n'est pas une fenêtre, il n'y a pas de WndProc... d'ailleurs modifier NotifyIcon en utilisant le code source n'y changera rien, ce ne sera toujours pas une fenêtre ! Quels évènements voudrais-tu gérer au juste ?

[Guulh]

Oui, chaque Form a sa propre boucle de messages, et généralement son propre thread.

Ce n'est pas le cas par défaut, non ?

[tomlev]

Ce n'est pas le cas par défaut, non ?

Pour le thread tu veux dire ? Je dois avouer que j'ai un doute en fait... c'est pour ça que je suis resté dans le vague en disant "généralement"
Il me semble que SirJulio est assez expert sur le sujet, il faudrait lui demander...

[SirJulio]

Salut,

Tu peux gérer les évènements publiés par NotifyIcon, mais comme ce n'est pas une fenêtre, il n'y a pas de WndProc... d'ailleurs modifier NotifyIcon en utilisant le code source n'y changera rien, ce ne sera toujours pas une fenêtre ! Quels évènements voudrais-tu gérer au juste ?

Si, si, et c'est ca qui frustrant !
En fait, la classe notifyicon embarque en private une classe NativeWindow, et se sert de cette derniere pour rediriger les messages (cf. la classe dans Reflector) vers son propre wndproc. Donc en fait, si il y a bien une fenetre (du moins il y a un handle, c'est tout ce qui compte), mais vu que tout est privé (à l'inverse des autres wndproc), on ne peut rien faire.

Pour les forms, de ce que j'en sais (du moins en monde managé), un thread peut enclencher une pompe de message (par Application.Run(...) normalement) et une seule, apres un thread peut gerer un nombre non determiné de form managée (je ne sais pas si c'est limité), mais une form ne peut etre géré que par un seul thread.

[tomlev]

OK... donc par exemple, si tu crées une fenêtre en faisant comme ça:

Code C# :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
...
private Form2 f2;
 
private void btnOpenForm2_Click(object sender, EventArgs e)
{
    f2 = new Form2();
    f2.Show();
}
...

La nouvelle Form sera gérée dans le même thread ?
Oui je sais, on s'écarte du sujet, mais je suis curieux...

[SirJulio]

Vi, tout à fait.

Pour t'en convaincre, lance une appli Winform classique avec une form, et lance un thread à coté contenant juste une form. Dans le thread "principal", créé et affiche X nouvelle form, et au bout d'un moment, appelle Application.ExitThread(). Toutes les forms créé par ce thread se fermeront, car ce dernier n'a plus de loop à message (ce que fait .ExitThread()), par contre l'autre thread (et in extenso, l'autre form) sera toujours present et fonctionnel.

[giova_fr]

Donc pour synthétiser tout ce qui s'est dit, par defaut chaque nouvelle fenetre dans une appli est implicitement géré par le meme thread, partage la meme QueueMessage (ce que vous appellez pompe à message si j'ai bien compris), mais possede sa propre WndProc, c'est bien ca?

Quels évènements voudrais-tu gérer au juste ?

Je ne cherche pas à intercepter les messages du notifyicon, je veux juste éviter d'ajouter une tache continue et lourde (une QueueMessage) à mon appli alors qu'il y en a deja une active via notifyicon (ou RunApplication ... je m'embrouille un peu pour le moment)

Je compte utiliser les messages pour communiquer entre mes 2 "programmes"
(pluq d'infos à ce sujet ici)

Je vais me pencher de plus pres sur les docs pour tenter d'y voir plus clair, et reste connecté ici au cas où...

Merci encore pour vos participations.

[tomlev]

OK, c'est bon à savoir...