Discussion :

[Neilos]

Bonjour à tous,

j'ai une fonction dans une DLL qui prend en paramètre un pointeur sur une structure.

Mon programme fourni ce pointeur qui est en fait l'adresse d'une variable locale dans une fonction.

Parfois cela fonctionne parfois pas (en fonction de la DLL alors qu'il n'y a pas de différence dans cette fonction là, c'est moi qui les ais écrites).

Donc je me demandais s'il ne fallait pas mettre se pointeur dans une zone accessible à la fois à la DLL et au programme.

Cela se fait avec des filemapping si je me souviens bien.

[Trap D]

Salut
Si je comprends bien, ton pointeur est l'adresse d'une variable locale à une fonction : celà ne peut pas marcher puisque après le retour de cette fonction l'adresse de la variable devient invalide (la valeur de la variable peut avoir été modifiée par un appel à une autre fonction). Il faudrait que cette variable soit déclarée "static" pour que ça marche.

[henderson]

Salut !

Ca devrait fonctionner si on suppose que la fonction effectue un traitement
ponctuel sur cette variable, la fonction appelante reprenant son execution
après le retour de la fonction appelée. Ce ne serait plus vrai si la fonction est appelée
en dehors de ce cadre bien précis, et en particulier si l'adresse de cette variable
est stockée dans la dll, pour une utilsation ultérieure par la dll, ce qui irait dans le
sens de la réponse de Trap_D.

Problème de cohérence au niveau des adresses de la pile entre l'exe et la dll ? L'exe est-il compilé comme un autosuffisant, sans les dll de gestion mémoire dynamique ?

Vérifies bien ce que tu fais.

A plus !

[Neilos]

Alors voila en gros ce que je fais :

J'ai un type (Infos) structure qui contient 2 AnsiString (s1 et s2) et un entier (i).

La fonction de ma DLL :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
void ma_fonction_dll( Infos *infos )
{
   infos->s1 = "Chaine 1";
   infos->s2 = "Chaine 2";
   infos->i = 5;
}

Et ma fonction dans mon programme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
void ma_fonction_exe ( void )
{
   Infos infos;
   // Autres variables
 
   // Autres traitements
   ma_fonction_dll( &infos );
 
   // Autres traitements
}

En fait je suis entrain d'écrire une application utilisant des modules (des dlls) qui exportent toutes cette fonction.
Avec un module ça fonctionne. Et avec un autre pas....à priori j'ai pas trouvé d'erreur dans le module où ça plante puisque j'ai pris la fonction du module qui marche et j'ai juste changé les valeurs.

Et pour répondre à henderson...non l'exe utilise les dlls de gestion de mémoire dynamique...je me rappel plus où on enlève ce truc

[henderson]

Salut !

Tester si le problème persiste avec :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
Info *info = new Info;
...
...
delete info;

A plus !

[Neo41]

Salut,

essayes de faire un pointeur de pointeur (non testé mais à priori ca doit marcher):

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
void ma_fonction_dll( Infos **infos )
{
   (*infos)->s1 = "Chaine 1";
   (*infos)->s2 = "Chaine 2";
   (*infos)->i = 5;
}

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
void ma_fonction_exe ( void )
{
   Infos *infos = new Infos();
   // Autres variables
 
   // Autres traitements
   ma_fonction_dll( &infos );
 
   // Autres traitements
}

Parce que si tu instancies ta variable infos à l'intérieur de la DLL, c'est pas garantie que la zone mémoire qui lui est allouée reste toujours accessible dans ton programme.

[Neilos]

Parce que si tu instancies ta variable infos à l'intérieur de la DLL, c'est pas garantie que la zone mémoire qui lui est allouée reste toujours accessible dans ton programme.

Je ne vois pas en quoi j'instancie ma variable infos dans la DLL. Au contraire dans mon code elle est instanciée dans ma fonction de l'exe et je passe l'adresse de cette variable en paramètre à ma fonction de la DLL.

Enfin bon je vais quand même essayer

[Neo41]

Parce que si tu instancies ta variable infos à l'intérieur de la DLL, c'est pas garantie que la zone mémoire qui lui est allouée reste toujours accessible dans ton programme.

Je ne vois pas en quoi j'instancie ma variable infos dans la DLL. Au contraire dans mon code elle est instanciée dans ma fonction de l'exe et je passe l'adresse de cette variable en paramètre à ma fonction de la DLL.

Enfin bon je vais quand même essayer

Je n'ai pas dis que tu l'instanciais dans la DLL, c'était juste une mise en garde ;-)

[Neilos]

lol merci...moi ce qui m'étonnes c'est que ça fonctionne impec avec un certain module et pas du tout avec un autre....

[Trap D]

Si je me souviens bien, il est déconseillé d'utiliser les AnsiString dans les Dll je crois.

[Neo41]

Si je me souviens bien, il est déconseillé d'utiliser les AnsiString dans les Dll je crois.

Humm ca m'a l'air un peu familier tout ça.
Quand on crée un nouveau projet avec l'expert DLL de builder, il y a tout un commentaire quant à l'utilisation des strings, mais ça concerne seulement le passage en paramètres et le retour de fonctions. Je ne sais pas si ça peut aider...

Voici le commentaire en question:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
 
//---------------------------------------------------------------------------
//   Remarque importante à propos de la gestion mémoire de la DLL lorsque votre
//   DLL utilise la version statique de la Bibliothèque d'exécution :
//
//   Si votre DLL exporte des fonctions passant des objets String (ou des structures
//   ou classes contenant des Strings) comme paramètres ou résultats de fonctions,
//   vous devez ajouter la bibliothèque MEMMGR.LIB à votre projet DLL et à tous
//   les projets utilisant la DLL.  Vous devez également utiliser MEMMGR.LIB si
//   d'autres projets qui utilisent la DLL effectuent des opérations de création ou de
//   suppression sur des classes non dérivées de TObject, exportées par la DLL.
//   Ajouter MEMMGR.LIB à votre projet DLL modifie la DLL et les EXE appelant
//   pour qu'ils utilisent BORLNDMM.DLL comme gestionnaire de mémoire. Dans ce
//   cas, le fichier BORLNDMM.DLL doit être déployé en même temps que la DLL.
//
//   Pour éviter d'utiliser BORLNDMM.DLL, passez les chaînes comme paramètres
//   "char" ou ShortString.
//
//   Si votre DLL utilise la version dynamique de la RTL, vous n'avez pas besoin
//   d'ajouter MEMMGR.LIB car cela est fait automatiquement.
//---------------------------------------------------------------------------

[Neilos]

Bon j'ai enlevé tous les paquets qui servaient à rien et compagnie.....et ça marche.

Je cherche plus à comprendre lol !

Merci beaucoup à tous

[Neilos]

Oui si on utilise des AnsiString...ben déjà c'est pas compatible avec d'autres langages (à part Delphi) et ensuite on doit obligatoirement publier borlndmm.dll (ou qqc comme ça) avec le projet.