[MFC] Question sur les messages Windows en général....

Salut,

Je me posais quelques questions vis a vis de la gestion faite par Windows des messages.

Ainsi, par exemple, lorsqu'une appli envoie un WM_COPYDATA message a une fenetre (on va dire "a une autre appli"), en arriere plan, bien au dela des simples parametres wParam et lParam, toute une structure est copiée de l'espace d'adressage de la 1ere appli a celui de la 2nde appli, la taille de la copie étant basée sur un des membre du COPYDATASTRUCT passé en parametre.

En fait, j'aimerais savoir "qui" se charge de tout ce travail, et surtout, si je crée mes propres messages Windows, quel travail va etre fait en arriere plan? Si je décidait de créer un message faisant le meme travail que WM_COPYDATA, que me faudrait il faire? Est ce seulement possible?

SI je fais un #define MYMESSAGE WM_USER

et que ensuite, je fais un:

::SendMessage(hWnd, MYMESSAGE, param1, param2)

Que se passe t il pour Param1 et Param2?
Sont ils simplement copiés dans l'espace d'adressage du processus gérant hWnd?

Merci

salut,
Salut dans le cas du sendmessage c’est très simple tu transmet une adresse pas le contenu.
Et comme le sendmessage attend le retour cette adresse peut être un simple variable locale à une fonction (pile) .
:D

Salut,

Je ne suis pas sur de comprendre...

Si je fais:

int a=100;
int b=200;
::SendMessage(hWnd, MY_MESSAGE, (WPARAM)a, (LPARAM)b);

Qu'est ce qui est transmis?

et dans le cas de:

PCOPYDATASTRUCT pMyCopyData;
//initialisation de pMyCopyData
::SendMessage(hWnd, MY_MESSAGE, (WPARAM)myWnd, (LPARAM)pMyCopyData);

?

et bien tu transmets 100 et 200.
si tu fais (WPARAM)&a tu transmettras l'adresse de ta variable a .

:D

D'accord:

En faisant :

(WPARAM)&a

Je transmettrai l'adresse de ma variable a, mais celle ci n'aura aucun sens pour ma fenetre cible, n'est ce pas? (car l'espace d'adressage sera différent)

J'en reviens donc a maquestion intiale...
Comment ca se passe pour des messages de type WM_COPYDATA ou meme WM_SETTEXT, "qui" s'occupe de l'allocation mémoire?

Car j'ai fait des tests, et par exemple, dans

::SendMessage(hWnd, WM_SETTEXT, 0, lpsz); //Processus envoyant le message

et dans mon

LRESULT CMyView::OnSetText(UINT wParam, LONG lParam)

(sachant que j'ai fait un ON_MESSAGE(WM_SETTEXT ,OnSetText)),

lpsz (pour le processus envoyant le message) et lParam (pour le processus recevant le message) ne sont pas identiques (ce qui est logique car les espaces d'adressage sont différents)
Ca signifie bien qu'un buffer a été crée en ménoire pour que le processus appel ait acces au message...

lParam et wParam ne sont donc pas toujours "betement" transmis, mais il y a un traitement effectué, non?

ON_MESSAGE(WM_SETTEXT ,OnSetText)

oui ,
bon j'ai pas trouvé sur MSDN l'article qui en parle ,mais oui dans le cas de message WM_SETTEXT c'est une copie du buffer puisque pour le prototype on a :

Code:

---

1 2 3 4 5 6 7

SendMessage( (HWND) hWnd, // handle to destination window WM_SETTEXT, // message to send (WPARAM) wParam, // not used; must be zero (LPARAM) lParam // window-text string (LPCTSTR) );

---

le dernier argument attend bien un string se terminant par un zero .
c'est le cas particulier ...
:D

D'accord,

Donc, pour certains types de messages, il ya bien un traitement spécial en arriere plan, qui va au dela de la recopie de parametres 32 bits d'un esapce d'adressage a un autre.

Mais d'un point de vue utilisateur, quand on définit nos propres messages (ainsi que le traitement qui va avec dans les processus susceptibles de les recevoir), peut etre avoir un traitement plus évolué que la simple recopie de parametres?
Par exemple, serait on capables de créer un message WM_MYSETTEXT ayant les memes memes vertus que WM_SETTEXT?

En gros, ca utilise un memory-mapped file pour les messages systemes. (sachant que WM_COPYDATA en est un et a été spécialement concu pour faire transiter ses propres données)

Citation:

---

Envoyé par Yoyo@

Par exemple, serait on capables de créer un message WM_MYSETTEXT ayant les memes memes vertus que WM_SETTEXT?

---

Non, surtout pas !

Si t'as t'interesses, j'ai une doc sur le sujet (en anglais)

Oui, ca m'intéresse grandement.

Comment faire pour récupérer la doc? (je me connecte par contre avec une connection Modem 56k...)

je te donne le lien en MP, 5,7 Mo

sinon voir la fonction RegisterWindowMessage
regarde l'exemple Twins.exe
sur MSDN.

Citation:

---

SAMPLE: Twins.exe Uses RegisterWindowMessage for Interapp Comm.

Q66246

SUMMARY
The RegisterWindowMessage() function associates a unique message number with a given message name. This message number is guaranteed to be unique throughout the system but may change between Windows sessions. The new message is typically used for communication between two cooperating applications.

---

:D

Ceci dis pour de la communication inter-processus je préfère comme je l’ai déjà dis créer un fichier mappé en mémoire de la taille que je veux.
Et utiliser le sendmessage avec WM_SETTEXT pour faire la synchro d’accès au fichier mémoire.
Le deuxième niveau c’est d’utiliser des events pour se passer du message.
apres tu fais ce que tu veux dans le fichier mappé lecture /ecriture des deux cotés ,ce qui n'est pas le cas de copydata.
:D

D'accord,

Merci a vous deux pour ces infos!

WM_COPYDATA effectue un traitement spécial, les données sont copiées et mappées, c'est pour ça que tu peux pas t'en servir pour partager un buffer modifiable. Si tu fais des messages persos, c'est à toi d'assurer le marshaling.
Il est important d'utiliser PostMessage aussi et non pas SendMessage entre applis différentes.
http://msdn.microsoft.com/library/en-us/winui/winui/windowsuserinterface/windowing/messagesandmessagequeues/messagesandmessagequeuesreference/messagesandmessagequeuesfunctions/postmessage.asp

Citation:

---

The system only does marshalling for system messages (those in the range 0 to WM_USER). To send other messages (those above WM_USER) to another process, you must do custom marshalling

---

D'accord, je vois le truc.

Lol, je ne savais meme pas ce qu'était le marshalling, mais ct en tout cas bel et bien le terme qui correspondait a ce que je voulais savoir...

Merci ;)