RÉDACTEUR D'UNITÉ DE CHARGEMENT DYNAMIQUE DE DLL
florenth
-
24 août 2006 à 11:42
cs_rt15 Messages postés 3874 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 7 novembre 2014 - 22 déc. 2008 à 15:21
cs_rt15 Messages postés 3874 Date d'inscription mardi 8 mars 2005 Statut Modérateur Dernière intervention 7 novembre 2014 - 22 déc. 2008 à 15:21
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/39248-redacteur-d-unite-de-chargement-dynamique-de-dll
https://codes-sources.commentcamarche.net/source/39248-redacteur-d-unite-de-chargement-dynamique-de-dll
22 déc. 2008 à 15:21
Je me demande ce que devient florenth...
6 sept. 2006 à 13:18
Apparement y en aurait plutôt 2 d'ailleurs.
1 Si on fait un Form.Free dans la finalization de la dll, on aboutit à une exception dans la dll
uxtheme.dll. Pour empècher ça, on peut faire un Action:= caFree; ou utiliser la méthode de Shinning.
2 Une exception dans la méthode Free de la classe TObject (Parfois après un petit temps d'execution anormal).
test eax, eax | -> Quitte si Self pointe sur nil.
jz sur le ret |
mov dl, $01
mov exc, [eax] -> C'est là que l'exception à lieu, à la récuération de l'adresse
de la classe.
call dword ptr [ecx- $04] -> Appel de la méthode Destroy de la classe.
ret
Le tout avec réserve, je suis pas pro.
L'exception a donc lieu car l'adresse de l'objet qu'on décide de libéré est invalide.
Comme il y a a priori n'importe quoi dans eax, cela explique peut être pourquoi des fois il y a erreur et des fois pas.
Apparement, on peut se débarrasser de cette erreur en mettant en commentaire l'appel à la métode UnloadThemeData.
Cet appel se trouve dans la méthode Destroy de la classe (Dont j'ai pas noté le nom, mais elle est toute seule) contenue dans l'unité Delphi7\Source\Lib\Themes.pas.
Une fois mis en commentaire, faut s'arranger pour que la compilation de la fiche de la dll prenne en considération cette modife. (Le dcu doit se trouver dans Delphi7\Lib).
Evidement, c'est pas une solution, mais ça permet peut être de mieux cerné le problème...
florenth -> Je pense à toi, mais ça risque effectivement de prendre une semaine. :,(
4 sept. 2006 à 16:35
Je pourrais peut être le faire la semaine prochaîne...
Pour info, j'utilise une Delphi 7 Peros et j'ai un XP SP2 thème classique.
J'ai un peu regardé ce qu'il y a en source fournit avec Delphi. Apparement, les unités uxtheme et themes gère une partie du thème XP.
uxtheme charge dynamiquement la dll uxtheme.dll, et themes propose avant tout une classe, mais je sais pas à qui (Du côté de la VCL à mon avis).
Mon appli qui plante avec external parvient jusqu'à un point d'arrêt situé sur le end. de la finalization de l'unité themes... L'exception à lieu après ça. J'ai aussi essayé d'empécher le déchargement de la classe et de la dll uxtheme, mais cela n'a donné aucun résultat.
26 août 2006 à 13:12
Pour que je puisse faire une analyse plus complète, RT15, tu pourrais m'envoyer la version compilee de ton projet (avec la dll et define EXTERNAL), comme ça je comparerai les executables.
mon mail : mon_pseudo (à remplacer bien sur) -AT- msn -DOT- com
Merci d'avance et pourvu qu'on trouve le pourquoi du comment !! ^^
24 août 2006 à 12:07
Le Lien que tu donnes est celui de la question de RT15 :-)
aller bonne nuit ^^
24 août 2006 à 12:03
bon alors qui c'est qui va nous faire un exemple correcte (Dll + Thèmes) et complèt ... :-)
Ne vous battez pas pour le faire ^_^ (moi j'ai déjà assez de travail)
ne désespère pas tu tiens le bon bout
@+
Cirec
24 août 2006 à 11:55
Effectivement j'ai fait une erreur grossière en ce qui concerne la fuite de mémoire de la fiche... Je vais mettre tout ça à jour.
J'ai fait cet utilitaire car j'ai eu des gros soucis avec le thème XP.
Voilà l'équation du problème que j'avais :
Appli thème XP + Dll (Appelé via external)+ Fiche dans cette dll + GroupBox sur la fiche = exception à la fermeture de l'application. Et ce avec ou sans erreur de déchargement de la fiche.
24 août 2006 à 11:42
Tout d'abord, je voudrais juste te demander quel est l'intérêt de passer par un chargement dynamique si tu le fait dès le début de l'application ?
Personellement, je pensais que le chargement dynamique ne servait que dans des cas comme celui-ci :
---------------------------------------------------------------------------------------
procedure TFtmMain.AfficherForm2;
var
Afficher: TProcedure;
hLib: Cardinal;
begin
hLib := SafeLoadLibrary('ma_dll.dll');
if hLib <> 0 then
try
Afficher := GetProcAddress(hLib, 'AfficherForm');
if Assigned(Afficher) then
Afficher
else
raise Exception.Create('Impossible de charger la méthode AfficherForm');
finally
FreeLibrary(hLib);
end
else
raise Exception.Create('Erreur de chargement de la dll');
end;
---------------------------------------------------------------------------------------
En gros, tu charges la dll uniquement quand nécéssaire et tu la libère juste après.
Sinon, si tu en a besoin souvent, tu fais une déclaration "external" du type :
procedure Afficher; external 'ma_dll.dll' name 'AfficherForm'; stdcall;
Ce qui revient au même que ta méthode mais sans les linges de code superflues.
Ou alors, j'ai raté quelque chose et je serais curieux de savoir quoi.
Bon, ensuite, su sujet de la fiche avec thèmes XP dans la dll.
Pour que ça marche proprement, il ne faut pas libérer la fiche dans la clause "finalization" mais à chaque fois que la fiche se ferme. En effet, dans ton cas, tu peux la ré-ouvrir autant de fois que tu le veux, elle sera donc recréée à chaque fois. Mais elle ne sera détruite qu'une seule fois ! (et hop, une fuite de mémoire ^^)
Il faut mettre :
---------------------------------------------------------------------------------------
procedure TForm2.FormClose(Sender: TObject; var Action: TCloseAction);
begin
Action := caFree;
end;
---------------------------------------------------------------------------------------
Et là, ça marche.
A +
Florent