Hallo,
Bei der Suche nach Speicherlecks in einem gößeren Programm, habe ich festgestellt, das diese z.T. von der TShellTreeView-Komponente stammten.
Ich habe in der ShellCtrls.pas folgende Änderungen vorgenommen:
1. eine Destroy-Methode in TCustomShellTreeView eingefügt und FRootFolder und FNotifier freigegeben.
Delphi-Quellcode:
destructor TCustomShellTreeView.Destroy;
begin
if Assigned(FRootFolder)
then FRootFolder.Free;
If Assigned(FNotifier)
then FNotifier.Free;
inherited Destroy;
end;
2. Der nachfolgende Thread fragt Terminated nicht ab, weil er in WaitForMultipleObjects auf irgendwas ewig wartet. Deshalb habe ich statt INFINITE eine Zeit festgelegt.
Delphi-Quellcode:
procedure TShellChangeThread.Execute;
var
Obj: DWORD;
Handles: array[0..1] of DWORD;
begin
EnterCriticalSection(CS);
FWaitHandle := FindFirstChangeNotification(PChar(FDirectory),
LongBool(FWatchSubTree), FNotifyOptionFlags);
LeaveCriticalSection(CS);
if FWaitHandle = ERROR_INVALID_HANDLE then Exit;
while not Terminated do
begin
Handles[0] := FWaitHandle;
Handles[1] := FMutex;
// Obj := WaitForMultipleObjects(2, @Handles, False, INFINITE);
Obj := WaitForMultipleObjects(2, @Handles, False, 500); // neue Zeile von RaSoWa
case Obj of
WAIT_OBJECT_0:
begin
Synchronize(FChangeEvent);
FindNextChangeNotification(FWaitHandle);
end;
WAIT_OBJECT_0 + 1:
ReleaseMutex(FMutex);
WAIT_FAILED:
Exit;
end;
EnterCriticalSection(CS);
if FWaitChanged then
begin
FWaitHandle := FindFirstChangeNotification(PChar(FDirectory),
LongBool(FWatchSubTree), FNotifyOptionFlags);
FWaitChanged := false;
end;
LeaveCriticalSection(CS);
end;
end;
FastMM4 findet nach diesen Änderungen keine diesbezüglichen Speicherlecks mehr. Das Programm läuft jetzt auch ohne Fehlermeldungen.
Da diese
API-Programmierung nicht gerade meine Stärte ist, habe ich folgende Fragen:
Worauf wartet der Thread in WaitForMultipleObjects?
Welche Nebenwirkungen können auftreten, wenn ich, wie oben angegeben, die Wartezeit begrenze?
Vielleicht kann jemand meine Fragen beantworten.
Vielen Dank im Vorraus.
Klaus