Discussion :

[frednain]

Bonjour.
J'ai un projet à mener à terme, qui entre autre consiste en une DLL instanciée à partir d'une application.
Je suis sensé récupérer le HWND (l'appli appelerait une fonction exportée de la DLL) de la fenêtre de l'appli pour dessiner dedans à partir de la DLL ainsi que de récupérer les évènements windows pour pouvoir moi aussi interagir.
Je ne suis pas spécialiste windows, vous l'aurez compris. Cependant, j'ai tout de même eu affaire à ça il y a quelques années.
Ma dll ne créera pas la fenêtre, je ne sais pas du coup comment avoir un MainProc() à moi aussi, et l'idée d'avoir à faire des GetMessage() dans une tâche de fond m'ennuie profondément.
Aussi, je ne suis pas certain que de dessiner de mon propre thread ou à la réception d'un message soit tout à fait valide au niveau concurrence. Qu'en pensez vous?

Si vous avez des avis, des idées, des liens, merci beaucoup d'avance. Je prends tout ce qui passe.

[rigobert]

Je ne suis pas sûr d'avoir bien saisi le problème, mais je prends le risque de répondre une ânerie :

en "subclassant" la fenêtre dont tu connais le handle, il me semble que tu dois pouvoir partager les événements avec le thread GUI de l'appli.

maintenant concernant l'affichage, je ne vois pas trop comment partager, à moins de savoir exactement ce que contient la fenêtre et ce qu'affiche déjà l'appli par défaut.

[Médinoc]

Rigobert: Post croisé, et je pense en effet que tu es passé à coté du problème.

Déjà, je déconseillerais de jouer avec une fenêtre pour deux threads. Donc pour l'instant, on va dire un seul thread.
Donc, nous avons une fenêtre avec une boucle de message quelque part.

• La première chose à faire, c'est de savoir où mettre la boucle de messages en question (application ou DLL).
• Ensuite, savoir où mettre la WindowProc: Si elle doit appartenir à la DLL ou à l'application utilisatrice (ou bien, si on en met deux, laquelle doit avoir la priorité: voir point suivant).
  Note: C'est indépendant de l'emplacement de la boucle de messages.
• Ensuite, on sait que l'application doit, si j'ai bien compris, réagir à certains événements, tandis que la DLL doit réagir à d'autres (notamment le dessin). Il faudra donc bien à un moment donné que la WindowProc appelle des fonctions d'un module à l'autre.

Ce que je préconiserais, c'est une fenêtre avec dans l'un des deux modules une WindowProc qui, dans son default:, appellerait une fonction de l'autre module (au lieu d'appeler DefWindowProc()). Cette fonction aurait elle aussi un switch, et appellerait DefWindowProc() dans son default:.

[rigobert]

Ce qui n'est pas clair (à mon sens en tout cas ), c'est q'on ne sait pas si le projet porte sur uniquement la DLL ou bien la DLL et l'appli.

Medinoc: dans le 1er cas, tes propositions ne semblent pas faisables.

[Médinoc]

En effet.

[frednain]

Wow, des réponses. Merci! Merci!.

Je ne suis responsable que de la DLL (et du bazard qui est derrière, mais c'est une toute autre histoire )
Je dois m'intégrer dans une appli existante et ma dll est sensée être un module indépendant du système.

Ce qui est embêtant, c'est que ma DLL est asynchrone avec l'application la gérant. Elle peut en théorie aller afficher dans la fenêtre à n'importe quel moment (cependant, ca peut être restreint de façon à ce que les rafraîchissements ne se déroulent que lors de la réception d'un [edit] message windows)

A priori, j'ai été victime (de ma faute) d'un problème lexical sur "évènement", alors que j'aurais dù dire "message". Je cherche à avoir les messages windows, et non les évènements. (je suis en train de me renseigner au sujet de ces derniers)

En ce qui concerne les messages, on vient de me dire de substituer le pointeur windowProc de la fenêtre qu'on me passera par le mien, puis d'appeler l'ancien pointeur en fin de mes traitements. Je trouve ça fortement cradingue, (si il y a au moins trois modules échangeant les pointeurs et qu'ils ne sont pas remis exactement dans l'ordre inverse, certains ne recevront plus les messages ) mais il parait que c'est 'normal'.
Bon, ok, je m'incline, mais ça fait peur.