Discussion :

[wimbish]

Bonjour à tous,

Je souhaiterais pouvoir récupérer le résultat d'une procédure Windev 14 à partir d'une application Windev 55.

Dans un premier temps, je tente sans résultat de récupérer depuis un exe 14 la valeur retournée par ma procédure après l'avoir intégrée dans un assemblage .net.

L'utilisation de AppelDLL32 me renvoie l'erreur:
Vous avez appelé la fonction AppelDLL32.
La fonction 'test.pgExt.ReturnEntier' n'a pas été trouvée dans la DLL test.DLL
Même chose avec 'ReturnEntier' ou 'WL.pgTest.ReturnEntier' etc..

Avez vous des idées sur ce sujet ou sur une autre méthode a utiliser pour faire communiquer un exe 55 et un 14 ?

[mogwai162]

Bonjour.

Utiliser les DLLs me parait impossible. par contre si tu veux communiquer il te reste mles fichiers tu peux même avoir dans Windev 14 un fichier Windev 5.5.

[devwd]

Tu peux créer un exe en 14 qui écrit le résultat dans un fichier texte.

Tu appelles l'exe depuis ton appli 5.5.

DDELANCE("exe14.exe NomFic.txt")

+ lecture du fichier texte pour avoir le résultat

[wimbish]

Merci pour cette réponse.
Cependant, le problème persiste car les fichiers HF 55 et 14 sont dissociés.

je peux lancer facilement mon exécutable 14 depuis le 55 en envoyant en ligne de commande des paramètres (idPersonne etc..) mais je ne peux récupérer qu'un code d'exécution du programme en retour (vrai,faux)

Je peux contourner le problème en enregistrant le résultat de ma procédure 14 dans un fichier texte par exemple, et le lire depuis le 55 quand l'exe 14 se ferme.

Ce n'est pas très pratique et cela m'oblige a "ouvrir" l'exe 14 (même si je le rend invisible) pour obtenir le résultat.

La création d'une dll contenant les procédures 14 aurait été la meilleur solution je pense.
Pouvoir créer une application pilotable (par automation comme office) serait bien aussi mais est ce possible ???

Si quelqu'un a une piste ...

Merci.

[mogwai162]

...Cependant, le problème persiste car les fichiers HF 55 et 14 sont dissociés...

Oui sans doute mais si tu ajoute la dscription du fichier 5.5 à l'analyse en 14, tu pourras en lui laissant le format en 5.5 l'ouvrir depuis un exe en 14

[mail.spam]

Oui sans doute mais si tu ajoute la dscription du fichier 5.5 à l'analyse en 14, tu pourras en lui laissant le format en 5.5 l'ouvrir depuis un exe en 14

D'après ce que j'ai compris son problème c'est accéder à partir d'un programme 5.5 à des fonction de windev 14.

Il est vrai que ça peut être pratique.
Ne pas être obligé de re-développer un programme WD55 dans une nouvelle version de windev mais pouvoir utiliser un programme windev récent avec une version WD55.

Soit dis en passant tu peux peut-être utiliser sendmessage et transfert.
Ainsi tu passe à ton programme Wd14 le handle de ton programme Wd55 puis tu fais ton transfert vers ta vraiable Wd55.

Ce n'est qu'une hypothèse car je ne l'ai jamais tester et je ne sais même pas si la fonction transfert existe en Wd5.5.

[wimbish]

Merci encore,
je vais retenir la solution du fichier texte car après les tests donnent des temps de réponse sont acceptables.

[OnePoint]

Salut.

Il y avait bien un projet de Vincent ROY pour créer une DLL capable d'accéder à une ou plusieurs procédures d'un projet Windev.

C'était pour WD12.
Peut-être que depuis d'autres versions de Windev sont prises en charge ?

Je te donne le lien vers le projet:
Création de DLL pour Windev

[OnePoint]

Je souhaiterais pouvoir récupérer le résultat d'une procédure Windev 14 à partir d'une application Windev 55.

Dans un premier temps, je tente sans résultat de récupérer depuis un exe 14 la valeur retournée par ma procédure après l'avoir intégrée dans un assemblage .net.

L'utilisation de AppelDLL32 me renvoie l'erreur:
Vous avez appelé la fonction AppelDLL32.
La fonction 'test.pgExt.ReturnEntier' n'a pas été trouvée dans la DLL test.DLL
Même chose avec 'ReturnEntier' ou 'WL.pgTest.ReturnEntier' etc..

Avez vous des idées sur ce sujet ou sur une autre méthode a utiliser pour faire communiquer un exe 55 et un 14 ?

La piste .NET était intéressante.
Mais une DLL .NET est une DLL particulière qui ne peut pas être utilisée via AppelDLL32, ça n'a rien à voir.

Le problème c'est que WD 5.5 ne permet pas d'exploiter .NET, en revanche il peut utiliser l'automation, non ?

Et, théoriquement il est possible d'invoquer une DLL .NET via automation/COM:
Lire ceci: Créer un assemblage .NET depuis WinDev
et voir ce qui se rapporte aux propriétés avancées de l'assemblage, qui donne accès à ceci: Créer un assemblage .NET accessible par COM

Conclusion, il semble possible pour un projet WD55 d'utiliser l'automation pour invoquer les procédures contenues dans un DLL .NET développée en WD16.

Au plan de l'architecture, .NET/COM c'est plus compliqué et plus lourd que l'envoi de messages entre applications, comme suggéré par mail.spam.