Discussion :

[Bobx]

bonjour,
j'ai un problème de passage de données entre une DLL et mon appli. La dll a été compilée en Delphi 7 .
J'ai une appli compilée en D7 et une autre compilée en D5.
Le paramètre pour passer les données entre la DLL et les applis est une Class assez complexe pour simplifier c'est une Tcollection de Tcollection.
Quand j'utilise l'appli D7 avec la dll, tout est OK. Par contre quand j'utilise l'appli D5, les données sont complètement erronées (caract. bizaroides, décalage entre les différentes propriétés). Je me suis dit que je devais passer des paramètres plus rudimentaires et je passe maintenant entre mon appli D5 et la DLL un tableau de record contenant lui-même un tableau de record avec des types simples (integer, double et PChar). Mais toujours le même résultat: données erronées en retour dans mon appli D5. Quelqu'un aurait une idée ? Merci

[WolffN]

bonjour

rajoute la directive stdcall dans les déclarations des fonctions de la dll

[Bobx]

salut WolffN,
Les stdcall sont bien en place mais toujours le même problême....

[franckgar]

Slt,
As tu vérifié l'alignement de tes records sous Delphi 5 ? Il doit être identique entre ta DLL et ton appli si tu veux que les 2 programmes communiquent.
Sous Delphi 7 tu peux parameter l'alignement dans les options de compilation du projet. Tu peux aussi le faire dans le code avec les options de compilation : {$A+}, {$A-}, {$A1}, {$A2}, {$A4}, ou {$A8}
Par contre sous Delphi5 je ne sais pas si ça existe.

Sinon tu peux aussi voire du côté de la directive packed pour forcer la compression de tes records.

A+

[anapurna]

salut


tu recupere quoi de ta dll ?
si c'est un objet tu risque efectivement d'avoir une incompatibilite
c'est un peu comme si tu essayer de recupere un objet d'un dll creer avec c++


@+ Phil

[souch]

Si je ne me trompe pas, si tu veut récuperer un string, tu doit lui donner une taille fixe (string -> string(255).
A tu une exception de levée lors de la lecture ?

[Reisubar]

1. Ce n'est pas possible de passer des objets entre un programme Delphi et une DLL, même Delphi. Dans ce cas là il faut utiliser des paquets.
2. Toute utilisation de tableaux dynamiques ou de string non fixés en taille (en bref tout ce qui nécessite une allocation mémoire partagée entre DLL et exécutable) ne peut se faire sans le gestionnaire mémoire de Borland (cf la prose quand tu crées une DLL avec Delphi)
3. La convention d'appel doit être la même dans la déclaration de la fonction exportée (le plus souvent STDCALL) et côté implémentation
4. Lorsque tu utilises des PChars, il faut, s'ils ne sont le résultat que de transtypages (i.e. myPChar = pchar(MySTring)) ne les utiliser qu'en lecture côté DLL (autant passer des array [0..n] of char).
5. Si ca bugge toujours, il faut ton code poste ici...

[Bobx]

Pour les chaines de caractères, je passais des tableaux fixes de 255 car, mais toujours le même problème. En essayant différentes hypothèse je me suis aperçu que le problème disparaissait (décalage des données et carac. illisibles) quand j'enlevais les var de type Double. J'ai remplacé finalement Double par Single et j'obtiens bien maintenant un tableau de données correct !!!

Merci à tous et bonne fête de fin d'année

[anapurna]

salut

je suis desolé de contredire le redacteur mais il est possible de recuperer une instance d'objet dans une dll la seul condition est d'avoir la class declaré dans le programe principale

@+ Phil

[Bobx]

Je confirme tes dires Anapurna, puisque justement dans le cas cité plus haut j'utilise bien une instance d'objet que je passe en paramètre à la dll et que je lis dans mon appli . ça marche très bien quand le compilateur est le même pour l'appli et la dll: Delphi 7 en l'occurence. La class de l'objet instancié est bien sur la même pour les 2 codes (appli et dll).

[Reisubar]

Tu peux me contredire, ca ne me dérange personnellement pas :-) Cependant, je persiste et je signe : sans passer par Sharemem, si ca marche, c'est bien mais ce n'est pas fait pour ca et tu risque d'avoir plein de problèmes, notamment dans l'utilisation des opérateurs IS et AS (si tu les utilise explicitement pas, la VCL compilée côté DLL en fait sûrement usage par contre). Si par exemple tu passes un objet TAbc, chaque module (l'exe et la DLL) est chargé à une adresse virtuelle différente qui ne permet pas de tester de manière valide si l'objet est bon ou pas. Si l'EXE est chargé à l'adresse virtuelle A et la DLL à l'adresse B, chacun voient TAbc comme une classe ayant une adresse différente puisque à TAbc est subsitué une adresse qui dépends de A côté EXE et B côté DLL. L'interopérabilité des objets entre les modules n'est pas chose simple, voilà pourquoi MS à conçu des technologies comme COM pour partager de manière fonctionnelle des objets à base d'interfaces... mais c'est une autre histoire.

[Bobx]

Effectivement ce que je disais plus haut (passage d'un objet entre dll et appli) est valable seulement si sharemem (ou fastsharemem) est dans les uses des 2

[anapurna]

salut


je ne nie pas qu'il faille certaine condition mais il aurait ete plus prudent de dire qu'il n'est pas recommander l'usage des object dans une dll plutot que de dire que cela ete impossible

@+ Phil