COMMUNICATION INTER-PROCESSUS (IPC)
Renfield
Messages postés
17287
Date d'inscription
mercredi 2 janvier 2002
Statut
Modérateur
Dernière intervention
27 septembre 2021
-
17 févr. 2009 à 07:48
Renfield Messages postés 17287 Date d'inscription mercredi 2 janvier 2002 Statut Modérateur Dernière intervention 27 septembre 2021 - 3 mars 2009 à 08:54
Renfield Messages postés 17287 Date d'inscription mercredi 2 janvier 2002 Statut Modérateur Dernière intervention 27 septembre 2021 - 3 mars 2009 à 08:54
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/49277-communication-inter-processus-ipc
https://codes-sources.commentcamarche.net/source/49277-communication-inter-processus-ipc
3 mars 2009 à 08:54
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...
2 mars 2009 à 23:32
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 !
2 mars 2009 à 21:39
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.
2 mars 2009 à 21:22
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.
24 févr. 2009 à 11:41
pis tu peux causer d'une machine a l'autre...
et t'interfacer à ton naviguateur...
24 févr. 2009 à 11:38
24 févr. 2009 à 09:21
concrêtement, le subclassing est plus 'naturel' qu'un dialogue a base de sockets.
moins gourmand, aussi.
après, tout est question de gouts...
23 févr. 2009 à 19:51
23 févr. 2009 à 18:38
17 févr. 2009 à 15:30
Je l'ai utilisé dans le contexte suivant :
J'ai une DLL handler pour ajouter un item dans le menu contextuel de l'explorateur. Quand l'item est cliqué, dans ma DLL j'envoie un message à mon appli principale qui tourne en tache de fond pour que celle-ci effectue une action sur le fichier sélectionné.
Concernant le subclassing, pas ma ton module je l'avait déjà survolé mais j'avais pas percuté que l'IDE ne crashait pas avec. Mais perso j'aime bien avoir des DLL (pas trop, mais pour ce genre de truc), comme ça j'ai vraiment pas à me soucier de ça, le code ne me gène pas ça fait un fichier en moins. Et vu que je me trimballe déjà avec des DLL à enregistrer, une de plus ou de moins...
L'autre avantage est que je défini les messages que je veux sousclasser, comme ça ma procédure n'est pas appelée à chaque message mais uniquement à ceux surveillés.
17 févr. 2009 à 07:48
voir=> http://www.vbfrance.com/codes/MODULE-SUBCLASSER_38442.aspx
pas mal, c'est pratique cette API.
Ca va pour discuter, mais pour un échange de données efficace, privilégier d'autres vecteurs de communication.
les Pipes ou les sockets, par exemple.