[delphi] dll uit geheugen?

[Verwijderd]

Ik heb deze code gebruikt om een dll bestand dynamisch te laden.

code:

var
  handle : thandle;
  procedure load(t : pchar);
  procedure unload;

Procedure load(t : pchar);
begin
  handle := loadlibrary('sounds.dll');
  if (handle = 0) then begin
    beep;
    exit;
  end;
  play := getprocaddress(handle, t);    
  play;
end;

procedure unload;
begin
  freelibrary(handle);      
end;

Dit werkt prima maar nadat het programma de unload heeft uitgevoerd en ik wil de dll via de verkenner verwijderen geeft windows een foutmelding in de order van bestand in gebruik.

Is dit normaal van windows(XP) of werkt dan toch de unload procedure niet goed?

[LordLarry]

Je unload is niet goed, of je virusscanner zit in de weg.

[Flard]

volgens mij moet je ook nog na freelibrary het volgende doen:

code:

handle := nil;

('k heb boven op m'n kamer de precieze code ergens liggen)

[.oisyn]

Flard: da's onzin, de win32 API functie FreeLibrary unload de dll als er geen referenties meer naar zijn. Dat jouw programma vervolgende de handle op null zet heeft verder weinig te maken met hoe win32 werkt

[Verwijderd]

Ik heb geen virusscanner geladen op dit ogenblik dus dat kan het niet zijn.

Misschien nog een belangrijk aanvullend gegeven:

In deze dll staan een aantal forms. Ik heb een zelfde soort dll met geluidjes erin die ik wel kan verwijderen.

Misschien dat windows de geladen forms niet vrijgeeft?

Voor de rest kan ik eigenlijk geen andere code op het web vinden voor het dynamisch laden van dll's.

De code die ik gebruik voor het laden van de forms:

code:

procedure openform;
begin
  Form1 := TForm1.Create(nil);
  Form1.ShowModal;
end;

Voor het sluiten (dit doe ik in de OnDestroy van de form zelf) :

code:

procedure closeform;
begin
  Form1.Release;
end;

[LordLarry]

Action := caFree; in je OnClose neerzetten is een meer gebruikt manier hiervoor.

Ik zie niet de relatie met de beide malen dat je een stuk code gaf. Misschien moet je dat even duidelijker maken. Zet eens een breakpoint bij je loadlibrary en freelibrary en kijk of dat dat in balans is. Kijk ook naar de waarde van de handles, overschrijf je niet dezelfde handle meerdere malen?

[curry684]

Die Forms in de DLL registreren zich binnen het Application object van het proces. De DllUnload zal dus failen in VCL internals omdat er nog code uit de DLL potentieel in gebruik is.

Als je de returnvalue van FreeLibrary bekijkt gok ik dat die ook zal failen.

[_Thanatos_]

Heb je ook gekeken of de handle die je bij FreeLibrary gebruikt, hetzelfde is als de handle die je van LoadLibrary krijgt? Misschien zit er iets raars in je code wat die handle aanpast ofzo...

[curry684]

Even een genadeloze schop vanwege iets dat ik zojuist in de docs van TApplication::Handle zag staan:

Note: When writing a DLL that uses VCL forms, assign the window handle of the host EXE’s main window to the DLL’s Application->Handle property. This makes the DLL’s form part of the host application. Never assign to the Handle property in an EXE.

Dit bewijst mijn punt een stukje hierboven.

[Elissen]

Daar ben ik het niet mee eens. Ik denk dat je dat met die handle niet moet doen, omdat er anders messages in de verkeerde message-loop terecht gaan komen ofzo. Jouw quote bewijst dat de DLL en de EXE hun eigen Application-object hebben en dus eigenlijk van elkaar onafhankelijk zijn. Ik denk eerder dat de load meerdere keeren aangeroepen wordt en dus ook meerdere keren loadlibrary aanroept. Probeer het volgende eens:

Delphi:

var
  DllHanlde : THandle;
  play : procedure;

Procedure load(t : pchar);
begin
  if dllhandle <> 0 then
    exit;
  dllhandle := loadlibrary('sounds.dll');
  @play := getprocaddress(dllhandle, t);    
end;

procedure unload;
begin
  if DllHandle = 0 then
    exit;
  @play := nil; // hoeft niet, is wel netter
  freelibrary(dllhandle);
  dllhandle := 0;
end;

procedure test;
begin
  load('iets');
  play;
  unload;
end;

Vergeef evt typefouten, heb hier geen delphi bij de hand.

[Verwijderd]

Het is al opgelost.

Ik heb zoals lordlarry zei action := caFree; in de onclose van alle forms gezet i.p.v release in de destroy. De unload heb ik in een timertje gezet omdat die (kennelijk) sneller is dan de caFree (waardoor een access vialation optrad).

(met caFree (zonder unload) kon ik de dll ook al verwijderen.)

[Verwijderd]

Je kunt natuurlijk ook Forms-unit niet includen, en je vensters met je Small VCL versie bouwen. Want TCustomControl bevind zich niet in de Forms-unit

[ Voor 2% gewijzigd door Verwijderd op 27-02-2003 15:45 . Reden: best wel crap dit ;) ]

[killermar]

curry684 schreef op 25 februari 2003 @ 19:40:
Die Forms in de DLL registreren zich binnen het Application object van het proces. De DllUnload zal dus failen in VCL internals omdat er nog code uit de DLL potentieel in gebruik is.

Als je de returnvalue van FreeLibrary bekijkt gok ik dat die ook zal failen.

Beetje offtopic inmiddels ben ik bang, maar volgens mij heeft elk Delphi DLL een eigen TApplication instance...