Discussion :

[NGeVtC87]

Bonjour,

Je fais un test d'envoi de messages entre deux applications windows (.exe). Je veux envoyer un message à partir d'une application développée en C++ vers la deuxième. comme indiqué ci-dessous:

Code :

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

1
2
3
4
5
6
7
8
9
10
 
// Exemple application 1 Emetteur
#define WM_TestMsg WM_APP+950
 
int _tmain(int argc, _TCHAR* argv[])
{
 
  LRESULT _ret = SendMessage(HWND_BROADCAST, WM_TestMsg, 0, 0);
  return 0;
}

J'essaie de réceptionner ce message dans la deuxième application (Delphi) mais ça ne marche pas. Le message WM_TestMsg est aussi définie de manière équivalente dans l'application destination. Par contre l'envoie de ce message et la réception marche bien quand c'est réalisé dans la même application.

Vous auriez une solution à ce problème d'envoi de message entre deux application ?

Merci

[bacelar]

Vous n'êtes clairement pas dans les clous, RTFM.
https://msdn.microsoft.com/fr-fr/lib...(v=vs.85).aspx

"WM_APP" n'est pas une constante immuable, elle peut changer d'une compilation à l'autre et vous polluez toutes les applications et pas uniquement votre application "victime" avec des messages qui peuvent interpréter ce message de travers voir planter.

C'est quoi votre besoin initial ?
Pas faire tout péter j'espère.

[NGeVtC87]

Mon besoin est d'envoyer des messages d'une application vers une autre pour lancer les différents processus de cette dernière. Oui c'est WM_APP est plutôt utilisé au niveau de la même application.

[bacelar]

Vous êtes clairement dans les choix.

Pour la communication inter-processus, c'est les IPC, il y en a pour tous les goûts mais l'option je déglingue toutes les applications juste pour dire "coucou" à mon application "copine" n'en fait clairement pas partie.

La solution la plus "approchée" de votre Armageddon, et la plus archaïque, c'est celle plus ou moins documentée dans la documentation que j'ai donné en lien dans mon précédent post : usage de "RegisterWindowMessage".
Et vous devez comprendre tous les aspects abordés par la documentation et pas faire des tests au doigt mouillé.

Mais il y a tellement de manière plus safe et plus souple de faire de l'IPC, que faire du broadcast comme un portc, c'est vraiment du masochisme.

Pourquoi ne pas faire un dialogue directionnel en trouvant l'handle de fenêtre de l'application qui vous intéresse ?
Pourquoi ne pas passer par du DDE, du COM, des pipes, des sockets, ...

Que le système filtre des broadcast de sauvage, c'est de "salubrité publique".

[NGeVtC87]

Effectivement. La solution de communication entre deux application avec RegisterWindowMessage pour retourner un identifiant est nettement meilleur.

Merci

[Médinoc]

Normalement, WM_APP+xxx (qui est documenté comme ayant la valeur 0x8000) est utilisable pour deux applications qu'on contrôle complètement... tant qu'on est sûr de n'envoyer ça qu'au destinataire voulu (et qu'il n'y aura pas de conflits avec, par exemple, des plug-ins dans la même application). RegisterWindowMessage() est plus sûr, mais à utiliser avec modération (il n'y a que 16384 valeurs disponibles en tout et il n'est pas garanti qu'une soit désenregistrée quand tous les processus l'ayant enregistrée se terminent).

Ensuite, pour éviter de broadcaster comme un porc, on utilise FindWindow(). Reste à savoir si en Delphi on peut contrôler le nom de la classe de fenêtre utilisée (on ne peut pas en .Net, par exemple).
Si ce n'est pas possible, il faudra alors tenter une autre forme de communication inter-processus (tubes nommés, DCOM, etc.)

Pour finir, un message "normal" ne peut pas transmettre de pointeurs d'un processus à l'autre (le pointeur ne sera pas valide dans le processus de destination). Mais le message WM_COPYDATA n'est pas un message normal.