DDE : Qu'est ce qui pourrait perturber son fonctionnement ?

cs_Jack Messages postés 14007 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 - 19 févr. 2009 à 00:27
Renfield Messages postés 17287 Date d'inscription mercredi 2 janvier 2002 Statut Modérateur Dernière intervention 27 septembre 2021 - 19 févr. 2009 à 11:36
Bonjour à tous

Les liens DDE (Data Dynamic Exchange) permet de communiquer entre deux applications (sous XP, n'existe plus sous Vista).
Pour ma part, j'utilise un LinkExecute pour envoyer un ordre à l'application désignée comme Source.
Quand je teste sur 2 projets tout simple, cela fonctionne très bien.
Par contre, j'ai voulu rajouter cette fonctionnalité à une application déjà crée (pour devenir la Source du dialogue DDE) et mon application ne répond pas à la demande de connexion (LinkMode manuel) nécessaire avant de lancer le LinkExecute.
J'obtiens l'erreur suivante (en compilé ou en code, même comportement) :
   Erreur 282 - "Aucune application externe n'a répondu à l'appel DDE"
Bien sûr, le LinkTopic est strictement le même des deux côtés.
Quelque chose doit perturber le fonctionnement des liens DDE, mais je n'arrive pas à cerner quoi.
Cette application fonctionne très bien (à part le DDE), n'est pas très complexe et fait appel à quelques API standards

Descriptif de mon appli :
Dans le SysTray - Qu'elle soit masquée ou à l'écran, même résultat
Une seule forme active (ShowInTaskBar Yes)
Objets utilisés : SSTab, Timer (que j'ai rendu Disabled avec le même résultat)
Ma forme principale est lancée directement (pas de Sub Main)
Il n'y a pas (plus) de Hooking
4 classes

Ma question :
Qu'est ce qui pourrait bien perturber le DDE ?

Merci pour vos idées ou expériences

Jack, MVP VB
NB : Je ne répondrai pas aux messages privés

<hr />Le savoir est la seule matière qui s'accroit quand on la partage (Socrate)

7 réponses

Renfield Messages postés 17287 Date d'inscription mercredi 2 janvier 2002 Statut Modérateur Dernière intervention 27 septembre 2021 71
19 févr. 2009 à 08:02
DDE fonctionne, mais est reconnu pour sa lenteur.
tu m'apprends que ca n'existe plus sous VIsta (et 7, surement)

ceci dit, je ne saurait pas t'aider...

sachant que tu n'as pu reproduire le souci sur une petite maquette...

les deux entités sont des programmes que tu as écrits ? tu as la main sur le code des deux ? parce qu'au pire, y'a plein d'autres moyens de communiquer :p
0
cs_Jack Messages postés 14007 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 78
19 févr. 2009 à 09:24
Salut RenField
Oui, ce sont des programmes fait maison.
Le but est simple :
J'ai créé une appli qui se positionne dans le SysTray et réagit à deux raccourcis clavier.
L'utilisateur voudrait pouvoir déclencher les tâches associées à ces raccourcis depuis un bouton Excel.
Je pensais donc relancer le même exécutable, détecter qu'il tourne déjà et, dans ce cas, lancer une commande DDE avec LinkExecute à l'original pour lancer la tâche.
Dans la pratique, j'ai fait une mini-appli de test qui fonctionne bien, mais quand je l'applique à mon projet, il n'arrive pas à communiquer.
Oui, j'ai bien pensé aux Socket, mais comme cela doit tourner sur des machines industrielles, je voulais éviter les complications (serveur OPC, réseau redondant ...).
As-tu d'autres idées ?

Pour en revenir à DDE : Connais-tu un utilitaire capable de scanner les exé en cours de run afin de lister les "source" existantes ? (pour vérifier que mon appli principale est bien 'enregistrée')

Vala
Jack, MVP VB
NB : Je ne répondrai pas aux messages privés

<hr />Le savoir est la seule matière qui s'accroit quand on la partage (Socrate)
0
Renfield Messages postés 17287 Date d'inscription mercredi 2 janvier 2002 Statut Modérateur Dernière intervention 27 septembre 2021 71
19 févr. 2009 à 09:30
y'a bien plus simple, l'ami

fais de ton soft un serveur ActiveX

voir:
http://www.vbfrance.com/codes/RECUPEREZ-VOS-OBJETS-VIA-GETOBJECT_45432.aspx

lorsque tu souhaite communiquer, tu regarde si le serveur est là
si non, tu lance ton soft en tray.
te suffit de faire un GetObject pour récupérer une reference COM vers ton objet

et là c'est open bar...

appels de fonctions, déclenchement de tâches, tu peux faire ce qui te plait :p
0
cs_Jack Messages postés 14007 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 78
19 févr. 2009 à 09:44
Oui, mais j'ai pas le droit de toucher à la base de registres.
Je n'ai pas une grande liberté, j'ai déjà eu peur que les RunTime VB6 perturbent la machine ...
0

Vous n’avez pas trouvé la réponse que vous recherchez ?

Posez votre question
Renfield Messages postés 17287 Date d'inscription mercredi 2 janvier 2002 Statut Modérateur Dernière intervention 27 septembre 2021 71
19 févr. 2009 à 09:47
base de registres ?
avec un bon fichier manifest, on peut faire beaucoup...

http://www.vbfrance.com/codes/ISOLATOR-GENEREZ-FICHIERS-MANIFEST-VOS-EXE-DLL-OCX_48269.aspx
0
cs_Jack Messages postés 14007 Date d'inscription samedi 29 décembre 2001 Statut Modérateur Dernière intervention 28 août 2015 78
19 févr. 2009 à 11:30
Bah ... qui dit OCX dit enregistrement dans la base de registres, non ?
Je vais regarder ça de plus prêt ...

Merci
0
Renfield Messages postés 17287 Date d'inscription mercredi 2 janvier 2002 Statut Modérateur Dernière intervention 27 septembre 2021 71
19 févr. 2009 à 11:36
un exe qui utilise un ocx va demander a la base de registres de faire le lien entre le CLSID et l'emplacement du fichier dll a proprement parler.

en ajoutant un manifest (soit en ressources, soit dans le repertoire de l'exe) le fera charger par Windows.
quand un ocx sera necessaire, windows ira fouiner dans les infos chargées du manifest avant d'aller dans la base de registres.

le fichier manifest contient lui, l'equivalent de ce qui serait trouvé dans la registry, mais il s'agit d'un bete fichier texte.

au final, on peut ecraser une dll ou ocx par sa propre version (ce qui se fait pour le style xp, on force VB a charger une version plus recente des ocx prévus a la base)
ou on peut se promener avec des ocx, sans les enregistrer.
0