Runtime error 216 à la fermeture de l'application

Bonjour,

j'ai un problème de runtime 216 à la fermeture de mon application,
lorsque j'utilise une dll.
j'ai lu pas mal de chose à ce sujet sur ce forum, mais sans succès.

cela viens à partir du moment où je met un Tbitbtn sur le form de la dll (un Tbutton simple fonctionne).

je vous met le code (tout simple).

code sur l'application:

Code:

---

1 2	procedure start_contrat(name,pass,alias:AnsiString;HandleAppli : HWND); stdcall;external 'dll\Contrats.dll' name 'Start_Contrat'; procedure free_contrat; stdcall;external 'dll\Contrats.dll' name 'Free_Contrat';

---

Code:

---

1 2	start_contrat(Uppercase(DMSphere.dbHotel.Username),DMSphere.dbHotel.Password,ParamStr(1),Application.Handle); free_contrat;

---

code sur la dll

Code:

---

1 2	procedure start_Contrat(username,pass,alias:string;HandleAppli : HWND);stdcall; procedure free_contrat;stdcall;

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

procedure start_Contrat(username,pass,alias:string;HandleAppli : HWND); begin Application.Handle := HandleAppli; Application.CreateForm(TFContrat, FContrat); FContrat.Position := poScreenCenter; FContrat.Showmodal; end;   exports Start_contrat name FUNC_DLL_CONTRAT;   procedure free_contrat; begin FContrat.destroyform; end;   exports free_contrat name FUNC_DLL_FREECONTRAT;   destructor TFContrat.destroyform; begin FContrat.Free; FContrat := nil; inherited; end;

---

Voila donc si je rajoute un bitbtn (par exemple) sur mon form, message runtime eror 216 quand je quitte l’application.
merci d'avance.

je vais peut être dire une connerie, mais pourquoi des types différents pour name,pass,alias dans la procédure start_contrat ?

Code:

---

1 2 3 4 5 6

destructor TFContrat.destroyform; begin FContrat.Close; // le close libérera ta form inherited; end;

---

Grosse horreur :

Code:

---

1 2 3 4 5 6 7

destructor TFContrat.destroyform; begin FContrat.Free; FContrat := nil; inherited; end;

---

un destructeur pour une seule instance (FContrat) !! Un destructeur concerne toutes les instances, le code de la classe est mélangé avec le code concernant une instance en particulier, c'est pas clean. On peut l'imaginer pour une singleton mais on dirait que toute la mécanique n'y est pas.

Mieux vaut reporter ces instructions dans free_contrat et éliminer la méthode destroyform, c'est une hérésie et une GROSSE source de problème car qui prouve qu'elle sera invoquée de manière sûre depuis une autre instance que FContrat ?

@+

OK OK
c’était pour tester une solution.
dans ce cas la on met (testé avant mais marche pas)

Code:

---

1 2 3 4 5

procedure free_contrat; begin FContrat.Free; FContrat := nil; end;

---

Au lieu de FContrat.Free, as-tu essayé FContrat.Release ?

Dès lors où Application est son propriétaire et est en cours de libération, FContact a de fortes chances d'être déjà détruite à l'appel de Free.
Ces deux procédures ne sont pas bonnes. Il n'y a aucun intérêt à garder FContact après ShowModal puisqu'une nouvelle instance est systématiquement recréée.

Bien vu, perso, j'aime pas utiliser Application.CreateForm.
Pour découpler la libération de la form dee celle de l'application, utilise le constructeur Create de la form et passe Nil en paramètre pour le propriétaire, ce sera alors à toi de garantir la libération de la fiche.

Petit complément selon la doc Embarcadero :
216 = Access violation EAccessViolation

cf http://docs.embarcadero.com/products...rrors_xml.html

merci pour votre aide.

j'ai essayé plusieurs méthode, j'ai toujours le même résultat.
j'ai même enlevé le ".free".

ce problème viens probablement du tbitbtn car s'il y est pas, j'ai pas de message d'erreur.

pour précision le message viens à la fermeture de l'application complète.
fermer le form de la dll ne donne pas de message d'erreur.

et pour finir "petit oubli" cela n'arrive que sur windows XP.
windows 7 ou 8 pas de problème.

Retire le Application.CreateForm et utilise le TFContrat.CreateEnsuite, tu utilises la DLL directement en external !
Lorsque j'ai manipulé des TForm entre EXE et DLL, j'ai toujours utilisé un LoadLibrary et FreeLibrary, ainsi tu gères mieux la fin de vie de ta DLL

Tu n'utilises qu'une seule fois start_Contrat, comme tu ne gère qu'une seule référence, plusieurs appels serait source d'erreur

ton BitBtn a-t-il une image, peut-être un problème à ce sujet
ou alors ferme tu l'appli sur un clic sur ce bouton ?

concernant le create j'ai testé sans resultat.

et le loadlibrary aussi mais il passe jamais le if assigned

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

var handle: THandle; Start_contrat : procedure(name,pass,alias:Ansistring); begin Handle := LoadLibrary(pChar('dll/Contrats.dll')); if handle <> 0 then begin start_contrat := GetProcAddress(handle,pAnsichar('Start_contrat')); if Assigned(start_contrat) then begin start_contrat(Uppercase(Username),Password,ParamStr(1),Application.Handle); end; FreeLibrary(Handle); end;

---

Salut

D'abord, inverser le slash :

Code:

---

Handle := LoadLibrary(pChar('dll/Contrats.dll'));

---

d'où :

Code:

---

Handle := LoadLibrary(pChar('dll\Contrats.dll'));

---

Puis utiliser l'@ :

Code:

---

start_contrat := GetProcAddress(handle,pAnsichar('Start_contrat'));

---

Essayer à la place :

Code:

---

@start_contrat := GetProcAddress(handle,pAnsichar('Start_contrat'));

---

Rem : J'ai pas fait de test.

@+

Code:

---

1 2 3

@start_contrat := GetProcAddress(handle,pAnsichar('start_contrat')); if Assigned(@start_contrat) then start_contrat(Uppercase(Username),Password,ParamStr(1));

---

Code:

---

1 2 3

@start_contrat := GetProcAddress(handle,pAnsichar('start_contrat')); if @start_contrat <> nil then start_contrat(Uppercase(Username),Password,ParamStr(1));

---

j'ai essayé plusieurs code mais marche pas.

j'ai pris exemple sur :
http://delphi.developpez.com/faq/?page=systemedll

visiblement le getprocAddress marche pas

Code:

---

exports Start_contrat name FUNC_DLL_CONTRAT;

---

Code:

---

@start_contrat := GetProcAddress(handle,pAnsichar('start_contrat'));

---

Un des rares cas (si ce n'est le seul) où le texte est sensible à la casse :mrgreen:
Les transtypages PChar/PAnsiChar sont inutiles dans ce cas puisque 1) tu passes des constantes, 2) LoadLibrary/GetProcAddress acceptent de l'ANSI ou de l'Unicode ;)

Code:

---

exports Start_contrat;

---

Code:

---

@start_contrat := GetProcAddress(handle, 'Start_contrat');

---

Attention aussi au chemin en relatif, relatif au répertoire de travail et non à celui de l'application. Préfère-lui un chemin absolu !

OK C'est bon.
Donc il faut utiliser la méthode dynamique pour pas avoir de problème.

Le GetProcAddress est effectivement sensible à la casse.

merci à vous tous pour votre aide.

Le référencement statique fonctionne très bien aussi, mais :

Code:

---

procedure start_contrat(name,pass,alias:AnsiString;HandleAppli : HWND); stdcall;external 'dll\Contrats.dll' name 'Start_Contrat';

---

ne correspond pas à

Code:

---

exports Start_contrat name FUNC_DLL_CONTRAT;

---

;)