Communication inter-processus (ipc)

Soyez le premier à donner votre avis sur cette source.

Vue 7 621 fois - Téléchargée 918 fois

Télécharger le projet
Commenter

Description

Bonjour à tous,

Voilà rien de nouveau, je ne suis même pas l'auteur de cette source, elle vient directement de la MSDN. Si je la poste, c'est que j'ai galéré plusieurs jours avant de tomber dessus par hasard, et que tout était déjà fait.
C'est donc pour pouvoir la diffuser que je la poste.

Il s'agit d'un exemple très simple de communication entre 2 applications (ou processus) différents. Si vous avez 2 programmes, et que vous voulez échanger des informations entre eux, voilà donc un exemple. La méthode employée est d'utiliser un message dédié à cela : WM_COPYDATA.

Ainsi, dans l'application A, vous récupérer le handle de la fenêtre de B qui va recevoir le message, et vous faites un SendMessage(hwnd, WM_COPYDATA, wParam, lParam).

Dans l'application B, la fenêtre destinée à recevoir le message doit être sous-classée (afin de pouvoir recevoir le message personnalisé). Lorsque l'évènement WM_COPYDATA arrive, il ne reste plus qu'à lire les données qui ont été transférées avec le message.

Présentation plus détaillée de la méthode :
http://blogs.codes-sources.com/madmatt/archive/2009/02/15/communication-inter-processus-sous-windows-ipc.aspx

Ici, la données transférée est une chaine de caractère.
Le subclassing est fait grace à la DLL de vbAccelerator (version assembleur pour pas de plantage dans l'IDE).

Conclusion :


Voici le lien original dans la MSDN :
http://support.microsoft.com/kb/176058

En espérant que ça vous serve,

MadMatt
Télécharger le projet

Codes Sources

A voir également

Ajouter un commentaire Commentaires
Renfield Messages postés 17287 Date d'inscription mercredi 2 janvier 2002 Statut Modérateur Dernière intervention 27 septembre 2021 75
3 mars 2009 à 08:54
"ce n'est pas un problème en mode compilé (... à surveiller quand même)."

NON... ca n'est pas un soucis en compilé. Marginal (et encore) en VB, les applications graphiques Windows sont baties sur cette gestion des messages.
Tu imagine bien que depuis le temps...

Par la force des choses, moins de messages sont transmis a windows pour une appli qui vient de crasher (plus de messages souris, etc.)
mais windows sait a quel processus est liée la fenetre dont le handle est transmis et saura si le process est là ou non.
Du coup non. Pas de soucis en compilé.

Comme l'évoquait MadM@tt, le seule soucis est en mode debug.
La fenetre est là. On a demandé a recevoir les message la concernant dans une procédure VB.
mais lorsque le programme plante, VB6.exe reste là. C'est à lui que sont liées les fenetres créées. Du coup, les messages continuent d'arriver et crash.
C'est la même chose lorsque l'on stoppe le programme. Encore le même crash lorsque l'on place un point d'arret, puisque le programme n'est pas en mesure de traiter le message recu.

avec des solutions mises en oeuvre ici, par exemple :
http://www.vbfrance.com/codes/MODULE-SUBCLASSER_38442.aspx

les messages sont redirigés vers un mini morceau de code assembleur, lequel reste chargé en mémoire. Il teste si on est en mode debug (execution en pause) ou non.
Si oui, on refile les messages au traitement standard.
Si non, on est bon, on refiles les billes a la procedure de subclassing VB6.

J'ai pas eu de crash jusque là.

A noter également que ce test du mode debug ou non n'est pas fait, lors de l'execution du code en .exe

Au final, le fait de détacher le subclassing rend les choses plus propres.
Il est conseillé de le faire. Mais si l'appli a crashé, le mal est fait ^^

Je me tiens a ta disposition pour tout éclaircissement...
cs_titicar Messages postés 181 Date d'inscription jeudi 30 mai 2002 Statut Membre Dernière intervention 19 août 2012
2 mars 2009 à 23:32
MadM@tt : C'est ce que j'appelle une réaction rapide !
Tu me rassures sur un point : ce n'est pas un problème en mode compilé (... à surveiller quand même).
Du coup, je vais m'y intéresser, et comme tu l'as dit, en regardant des sources plus simples ou complètes que le code de VbAccelerator. Ce ne sont sans doute pas les exemples qui manquent sur VBFrance.
Et merci pour ta réponse rapide !
MadM@tt Messages postés 2167 Date d'inscription mardi 11 novembre 2003 Statut Membre Dernière intervention 16 juillet 2009 1
2 mars 2009 à 21:39
Tu viens de soulever le plus gros inconvénient du subclassing (mis à part qu'il est fastidieux à mettre en place) : quand on stoppe l'exécution, ou que le programme termine brutalement en non-compilé, l'IDE plante. Je ne peut pas trop t'expliquer pourquoi (je ne connais pas les détails), mais en gros Windows essaye d'envoyer des messages à une fonction d'un programme qui n'existe plus.
Ce n'est pas un problème en mode compilé (mais je ne sais pas en détail ce que deviennent les messages dans ce cas) puisque ça n'arrive que lorsque l'application est déjà en train de planter.
Il est possible d'utiliser certains codes qui évitent ce phénomène (avec de l'injection assembleur par exemple). J'utilise dans ce code une DLL (pas de moi) qui gère ce problème. Tu peux jeter un coup d'oeil au code si tu veux, mais avant d'utiliser ce genre de DLL je te conseille d'essayer de regarder un code de subclassing complet avant, pour bien comprendre le fonctionnement.

Je me souviens avant d'avoir touché au subclassing, ça me paraissait une montagne, mais en fait c'est pas si compliqué (il faut passer au delà des appels d'API) et ça t'aide à comprendre la structure des fenêtres windows et ce qu'il se cache derrière tes évènements VB.
cs_titicar Messages postés 181 Date d'inscription jeudi 30 mai 2002 Statut Membre Dernière intervention 19 août 2012
2 mars 2009 à 21:22
Bonjour,
J'ai souvent regardé sur ce site plusieurs sources concernant cette communication entre plusieurs prog, ou subclassing. On y est tous confronté un jour ou l'autre. Mais je ne l'ai pas encore utilisé.
Déjà, c'est d'un niveau 'pas pour tout le monde'. Et surtout, j'ai une grosse question sans réponse : dans tous les cas que j'ai vu, il faut 'fermer' cette communication avant de quitter le prog (chez MadM@tt : 'DetachMessage Me, Me.hwnd, WM_COPYDATA' dans Form\Unload). Mais que se passe t-il si notre prog se ferme brutalement (face à une erreur non gérée et sans doute, sans passer par Unload)? Windows va t-il continuer d'envoyer un message à un prog qui ne tourne plus?
C'est sûr, je ne suis vraiment pas initié dans ce domaine... D'où cette question.
Renfield Messages postés 17287 Date d'inscription mercredi 2 janvier 2002 Statut Modérateur Dernière intervention 27 septembre 2021 75
24 févr. 2009 à 11:41
je vois pas d'avantage flagrant... peut etre plus simple a mettre en place... (un Winsock a poser, ca roule...)
pis tu peux causer d'une machine a l'autre...
et t'interfacer à ton naviguateur...
S'inscrire maintenant

Vous n'êtes pas encore membre ?

inscrivez-vous, c'est gratuit et ça prend moins d'une minute !

Les membres obtiennent plus de réponses que les utilisateurs anonymes.

Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.

Le fait d'être membre vous permet d'avoir des options supplémentaires.

Du même auteur (MadM@tt)