Voilà je dois faire ça : pour l'instant je l'ai fait en Statique mais ce serait mieux en Dyn : alors comment que j'fais ?

- LoadLibrary qui te renvoie un THandle après avoir chargé la DLL
- GetProcAddress qui te renvoie la fonction quand tu lui donne le THandle
- FreeLibrary qui "relâche" la DLL
 

 
(par exemple, attention si tu veux passer des paramètres AnsiString/LongString/string il faut inclure ShareMem ou FastShareMem, sachant que le premier est lent et requiert borlndmm.dll et que le second est dispo ici)

Ben pê que ça va me servir parce que j'ai réussi à lancer ma DLL mais lors de la fermeture de celle-ci, le système appelant se ferme alors qu'il est pas sensé le faire.
 
ça c en débug, si je le fais sous windows, là windows me balance 22 message d'erreurs (je les compté : ils sont tous du style : Un exception a été crée à l'adresse 58866DTC) et l'appelant se ferme derrière.
 
Mais effectivement, je passe en paramètres un PChar plus un composant à ma sauce et pê que ta solution pourrait merservir : si t'as d'autres idées, n'hésite pas !!!!!
 
Et merci bien sur !!

C'est quoi le 'composant à ta sauces' ? parce qu'il faut faire gaffe dans ce que tu passes

Ben c compliqué à dire euh ....
Disons que c'est un objet qui sert de trame de communication entre plusieurs système : le truc est rôdé depuis 5 ans donc ça vient pas de ça ....
Je viens d'essayé le FastSharemem, je l'ai mis en premier dazns les Uses de mon unité mais ça fait rien de plus .....
 
En plsu ce qu'il y a de marrant c qu'il y a déjà le débugage intégré dans delphi mais je ne vois pas les erreurs que windows me balance : sous delphi, il ne sors aucune erreur : il ferme juste le système appelant ...

Vous avez pas d'autres idées ?  
Antp ?

bah je sais pas
tu passes quoi ? des objets ? on ne peut pas faire ça il me semble

Ben je suis en train de me demander si ce n'est pas au niveau de ma DLL que ça pose problème et non au nivo de l'appelant.
Parce que j'ai testé avec 2 appelant différent, et le résultat est le même : mais en même temps, le code pour appeler la DLL est le même aussi : donc qd y'a pas de solution, on recommence :  
Nouvelles DLL "Printcoucou" et on vois si ça marche, ensuite ben on remplit au fur et à mesure pour voir où ça bloque !!!! (youpi ...)

Bon pouyr ceux que ça intéresse, j'ai compris d'où ça venait .
 
En fait qd on lance une DLL en Dynamique, on ne peut pas passer des paramètres de types "var" ex :  
Procedure Machin(var Str : String);
Il faut faire :  
Function Machin(Const Str : String) : String;
Pour faire la même chose.
 
Seul pb : mon code présentait sous cette forme :  
 
Function toto (Var Comp : TMonComposantperso) : Integer;
Et dans cette fonction, je modifiais le 'comp' et en fonction de l'état de sortir de la function, je mettait l'integer à 0 ou 1 ou -1 ...
Là ça devient chiant parce que j'ai donc fait :  
TMycomposantamoi = record
    Comp : TMonComposantperso;
    Nb : Integer;
  End;
Function Tata(Comp : TMonComposant) : TMyCOmposantamoi;
 
Mais dans le composant TMyCOmposant j'ai déjà un object qu'il faut crée et j'ai un peu de mal : il me sort des exceptions à tout va !!!!!!!

 
heu si ça marche très bien avec var
const = var niveau type de données, sauf qu'avec const tu t'engages à ne pas le modifier
Mais comme je l'avais dit; si tu passes des string il faut que dans la DLL et dans l'exe la première unit inclue soit ShareMem ou FastShareMem.
Si l'un plante et pas l'autre c'est le hasard, mais ça risque de planter plus tard
 

 
Comme je l'ai dit, il me semble qu'on ne peut pas passer d'objets à une DLL
Rien à voir avec le var ou pas var.
La classe TMyComposant de ton exe n'est pas la même que celle de ton DLL : ils ont chacun leurs classes.

Bon j'ai réouvert mes bouquins et dépoussiérés ma mémoire et j'ai réussi à avancer un peu :  
Je passe en paramètre un pointeur.
Donc je le passe en Const et l'affecte à un pointeur local dans ma DLL : ces 2 pointeurs vont pointer la même adresse et donc le pointeur local de la DLL va aller modifer les données à l'adresse qu'il pointe (et donc que le pointeur passé en paramètre pointe aussi)  
Donc ça marche.
 
Problème :  
Initialement ce que je voulais faire ct lancer et libéré ma DLL dans une procédure tout en local parce que sinon le lancement dynamique n'a, pour ma part, aucun intérêt.
Donc tout ce passe bien, je retrouve bien ce que j'ai modifié dans la DLL mais à la fermeture du système appelant, une erreur apparait dans le "LoadResString" de Delphi de type "violation d'accèsq blabla : ecriture à l'adresse blibli' ....
 
En fonctionnement normal, même chose : une erreur tourne en boucle et je suis obligé d'aller ds le task manager pour la stopper !!!!!
Ou alors tjs en mode normal, il me sort un truc du genre : 'la mémoire ne peut pas être read' .....
 
Si vous avez des idées ...
Je précise que j'ai mis dans le projet le fameux FastShareMem, au début des Uses o nivo de l'appelant et de l'appelé et ça ne fait strictement rien ....

T'as un pointeur qui se balade qui n'est plus valable
Par ex un truc qui pointe mémoire du DLL, et vu que le DLL a été viré entre temps...
FastShareMem c'est juste pour pouvoir passer des string en paramètre.

Ben c bien ce que je pensais mais a priori non ....
Mais c la merde : j'y retournerai plus tard : là ça me saoule grave !!!

 
bah pourtant si
elle fait quoi exactement la DLL ?

Oh là là si tu savais !!!
En gros : en static, je lui balancais mon objet merdeux, la DLL le modifiait et me le renvoyait : ça ça marche mais à la fermeture de l'appelant ça fait chier !!!

mwouais elle le modifie comment ? parce que si elle fait des allocations mémoire c'est normal que ça plante

Ben non c pas normal : si tu redéclare ds la DLL un pointeur de même type que celui passé en paramètre et que tu travailles dans la DLL avec ce pointeur déclaré en global en l'ayant affecté au pointeur rentré en paramètre ds la DLL, c'est pas logique qu'il merde sur une allocation :  
les 2 pointeurs vont pointés la même pile de données donc si on utilise le pointeur avec lequel on peut modifier les données dans la pile, c bon !!
Sauf si un pointeur défini plus qu'une adresse de pile : du style une quantité de mémoire allouée.
 
Mais vu que ça ne dérange pas Delphi d'appeler 15 fois la DLL et qu'il ramène bien les valeurs modifiées, ça parait difficile de penser à cette eventualité !!
 
Donc en résumé ça fait chier et ça merde !!!

heu faire pointer deux pointeurs vers un même truc c'est pas une allocation
tu fais des créations d'objets, de records, des getmem ou des trucs du genre ?

Ben je crée les 2 pointeurs dont j'ai besoin : en fait ces pointeurs, ce sont mes objets : je simplifie parce que sinon on s'en sortira pas !!!
Dans l'objet, y'a de tout des records, des lancement de DLL statiques, des allocations (sous forme de tableau dyn) des procedures/fonctions à la pelle enfin tout ce qui va bien quoi !!

ouais mais tu simplifies trop : tu ne dis pas tout
si tu fais des allocations dans la DLL, il me semble que c'est normal que ça plante après avoir libéré la DLL.
Le passage de tableaux dynamiques dans des DLL je ne suis pas sûr que ce soit bon.
Pourquoi tu veux faire une DLL au fait ?

Ben je peux pas trop t'expliquer plus parce que c un truc que j'ai à faire au boulot donc confidentialité oblige .....
 
Mais disons que cet objet sert de trame de données entre plein de systèmes de gestion de production !!
Donc c'est déjà le beau bébé !!!
Mais ce truc là fonctionne depuis 5 ans donc il est pas à mettre en doute !! Ca c pour l'objet .
Ensuite, la DLL c un programme de traitement graphique qui va remplir un petit plus la trame de donnéeset ensuite cette trame va être envoyée à un autre soft qui va à son tour la remplir et ainsi de suite.
Malheureusement je peux pas t'en dire d'une part parce que j'ai pas le droit, et d'autre part parce qu'il te faudrait 1 journée entière pour lire tout ce que j'aurais copier/coller !!!