TDirMonitor / ReadDirectoryChanges

[Furtbichler]

Nimmt man dann die API-Funktionen, die auf xxxxxA enden?

[Sir Rufo]

Zitat von Furtbichler:

Nimmt man dann die API-Funktionen, die auf xxxxxA enden?

öh, ja ... A=Ansi, W=Wide

[Schwedenbitter]

Ich wollte kein neues Thema aufmachen und deshalb frage ich trotz des Alters von 5 Jahren mal hier nach:

TDirMonitor von JUAN CARLOS MOLINOS MESA funktioniert bei mir (XE5) so lange, bis ich versuche es zu deaktivieren. Dann stürzt das Programm vom BS her (Win10 Pro) ab und ich sehe auch im Debugger nicht, woran es liegt. Außerdem benötige ich die Funktionalität für ein Konsolen-Programm und habe daher u.a. Probleme mit der Ableitung von TComponent.
Langer Rede kurzer Sinn: ich möchte es gern verstehen und nachbauen.

Wenn ich das richtig deute, findet die eigentliche Arbeit in dem Thread (ProcessMonitor.pas ) statt?
In RDCWDirMonitor.pas wird "nur" vorab geprüft, ob man das 1. Handle für das Verzeichnis, 2. einen I/O-Port für dieses Verzeichnishandle erzeugen und man 3. ReadDirectoryChanges(); überhaupt ausführen kann - erst dann wird der Thread erzeugt.
Im Thread wiederum lauert man mit GetQueuedCompletionStatus(); darauf, dass sich etwas geändert hat und liest es dann ebenfalls mit ReadDirectoryChanges(); aus und feuert das Ereignis.

Habe ich das so richtig verstanden?

GetQueuedCompletionStatus(); habe ich auch als Verursacher für den Absturz im Verdacht. Das scheint selbst blockierend zu sein und damit kommtif self.Terminated then quit:=true nicht mehr zum Zuge - er wartet sich tot.
Ich würde mich freuen, wenn sich trotz der langen Zeit mal jemand dazu äußern könnte, damit ich umbauen kann. Hilfreich wäre es wohl allemal wegen, um meine Probleme mit dem Absturz zu klären.