ECHANGE DE MESSAGES WINDOWS ENTRE DEUX APPLICATIONS
cristiandan
Messages postés
52
Date d'inscription
lundi 26 novembre 2001
Statut
Membre
Dernière intervention
4 novembre 2005
-
11 mai 2004 à 09:34
totoalecole Messages postés 2 Date d'inscription lundi 12 juillet 2010 Statut Membre Dernière intervention 12 juillet 2010 - 12 juil. 2010 à 13:12
totoalecole Messages postés 2 Date d'inscription lundi 12 juillet 2010 Statut Membre Dernière intervention 12 juillet 2010 - 12 juil. 2010 à 13:12
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/22686-echange-de-messages-windows-entre-deux-applications
https://codes-sources.commentcamarche.net/source/22686-echange-de-messages-windows-entre-deux-applications
12 juil. 2010 à 13:12
Par contre, lors de l'exécution de mon code, lorsque le receveur existe, j'ai le msg suivant :
Un appel à la fonction PInvoke 'MyFoxKey!WindowsApplication1.ModuleConnection::PostMessage' a déséquilibré la pile. Cela peut se produire, car la signature PInvoke managée ne correspond pas à la signature cible non managée. Vérifiez que la convention d'appel et les paramètres de la signature PInvoke correspondent à la signature non managée cible.
faut-il la aussi declare des integer ???????????
12 juil. 2010 à 12:37
dim Resultat_Find_Appli as long = 0
Resultat_Find_Appli = FindWindow(vbNullString, "nom_de_fenetre_inexistant")
quelqu'un saurait-il pourquoi ?
8 nov. 2008 à 13:16
Merci pour cette source :)
30 janv. 2007 à 14:34
25 janv. 2006 à 23:01
Il n'y a pas de déclaration entre les deux fenètres.
L'emetteur capte tous les messages par hooking, les analyses, puis les transmets uniquement à l'application qui porte un nom bien défini au moment de l'envoi. Le nom, est celui de l'appli qui recoit : Appli_receveur. Si une deuxième appli porte le meme nom, les deux recevront l'atom. Mais il faut que l'appli réceptrice sache le traiter et soit programmer pour capter les messages...
25 janv. 2006 à 21:11
Je pense que c'est pas possible.
Les deux applis pour qu'elles communiquent on besoins de déclarations, comme dans l'exemple avec les variables WM_ENVOI_NUMERIQUE et WM_ENVOI_ATOM.
25 janv. 2006 à 18:44
Comment peut-on envoyer du texte à une fenetre que l'on ne gère pas ?
Peut-etre avec un WM_KEYDOWN à la place du WM_ENVOI_ATOM ?
13 janv. 2006 à 19:17
13 janv. 2006 à 17:15
de toutes facons, les sendkeys sont assez contraignantes car elles obligent le recepteur à etre "en attente" d'entrees clavier.
Cependant pour une utilisation d'un recepteur sans interface utilisateur, ca peut s'envisager.
13 janv. 2006 à 16:54
Tu peux utiliser les sendkeys, mais l'objectif de cette source, c'est de donner un exemple de communication entre 2 applications en utilisant les messages Windows.
a+
13 janv. 2006 à 16:45
par exemple : l'evenement keyup coté recepteur, associé avec la commande sendkeys coté emetteur.
pour une appli où les entrées au clavier ne sont pas utilisées bien sur (ou alors il faut filtrer lorsque l'entree clavier provient de l'emetteur : en commencant le message par un caractere particulier par exemple)
Je ne sais pas si ca a un sens ce que je dis :-)
13 oct. 2005 à 09:55
D'ailleurs j'ai un pb pour la conversion du code, au niveau de l'override de la fonction WndProc avec la commande AddressOf...
11 oct. 2005 à 15:33
A part quelques exceptions comme GetKeyState(), quasi toute l'API win32 retourne du 32 bits, int ou long en C donc 'Long' en VB.
11 oct. 2005 à 15:15
pour moi j'ai du tout passer en INT !
La fonction FindWindow NE RENVOIT PAS DE LONG MAIS UN INT !!!
Non mais :)
26 janv. 2005 à 22:29
L'instruction Save_WndProc_Adresse SetWindowLong(.... dans Form_Load() sert uniquement a rediriger les messages Windows dans la procédure Capture_Message_Windows du module. Cela permet de remplace l'adresse de la routine Standard windows par celle de notre procedure> Capture_Message_Windows.
Donc a ce moment tous les messages windows sont interceptes dans cette procedure. Après on filtre les messages grace au Select Case via notre uMsg.
Si uMsg est pour nous alors on le traite si non on le laisse traiter par Windows via Capture_Message_Windows = CallWindowProc(.....
Je ne sais pas si je suis clair.
Parcontre il faut faire attention dans cette procedure, il n'est pas conseillé de mettre un point d'arrêt pour voir ce qui se passe car l'application risque fortement de se figé ou voir même de planter Windows. Cela s'explique que le flux de messages est en permanence en mouvement.
C'est comme une chute d'eau, on ne peut pas arrêter l'eau de la chute.
Tous les évenements du système d'exploitation, des logiciels, des gestions souris etc... passeront par cette procédures.
Je ne comprend pas bien ta question concernant ta variable Public dans une sub située dans form1.
Si tu veux faire un compteur de messages reçu alors tu declare ta variable au niveau du module et tu l'exploites directement dans le filtre via Select Case.
Je ne peux pas en dire plus car je ne saisi pas ce que tu veux faire.
Enfin j'espère t'avoir donné une petite reponse.
Je te souhaite une bonne continuation.
a+ Nocturne
26 janv. 2005 à 18:34
Comment faire pour résoudre ce pb ?
Par exemple, au lieu d'afficher avec le Label6 le Texte_Recu, fait appel à une sub située dans form1 qui afficherait le contenu d'une variable déclarée en public dans form1, qui compterait de 1 à 100...
Tu t'appercevras que cette variable est toujours affichée à 0 dès qu'il y a 1 uMsg.
Comme j'ai ce pb, peut etre que tu as la solution ? Je suppose qu'il y a soit une astuce pour faire appel à la sub, soit une astuce pour déclarer la variable public.
Sinon 12/10 me paraissent mérités !
18 janv. 2005 à 02:43
Bonne continuation dans le monde du developpement.
A+, Nocturne
18 janv. 2005 à 00:40
phtribaudeau a raison...
Dans la fonction suivante, la longueur de la chaîne est renvoyée à Resultat, et non l'id de l'atome :
Resultat = GlobalGetAtomName(Atom_Recu, Texte_Recu, 256)
Donc quand tu fais appel à GlobalDeleteAtom avec Resultat :
Resultat = GlobalDeleteAtom(Resultat)
...soit tu ne supprimes aucun Atome, soit tu supprimes le mauvais. Donc soit la mémoire se remplit gentillement, soit le système commence à perdre sa stabilité. :p
Dans les deux cas, c'est pas bon. Tu devrais vite modifier ça.
Sinon la source est excellente, simple et efficace. 10/10
A+
22 juil. 2004 à 11:10
A+ et encore bravo pour ton code.
21 juil. 2004 à 11:09
Oui tu as raison, utilise 'Atom_Recu', mais ca a l air de marche avec Resultat.
Merci pour la remarque.
a+
21 juil. 2004 à 10:11
je viens de regarder ton code que je trouve génial. Merci beaucoup.
Par contre, avec un collègue, nous pensons avoir trouvé une erreur : dans ton module 'Module_Receveur.Bas', dans la fonction 'Capture_Message_Windows()', la fonction GlobalDeleteAtom() doit avoir pour parametre le numero d'atome recu : 'Atom_Recu', et non pas la variable 'Resultat'.
Qu'en penses-tu ?
11 mai 2004 à 20:30
Je ne sais pas exactement, je me suis egalement posé la question.
Je sais qu'il y a une API qui permet de lister les processus à distance sur un autre PC mais après je ne sais pas comment faire pour gérer les messages Windows sur le poste destinataire.
Si quelqu'un a une idée sur la question, qu'il nous informe de la démarche a effectuer.
Autrement il y aurait bien une solution dans le contexte Client/Serveur mais ca veut dire de faire une application sur le poste destinataire qui permetrait de faire cela.
Si tu trouves qq chose informe moi.
Bonne prog à toi.
Nocturne
11 mai 2004 à 17:19
11 mai 2004 à 11:15
Bonne prog.
a+
11 mai 2004 à 09:34