TDirMonitor / ReadDirectoryChanges

[doctor-x]

Hallo,

nach dem ich mich durch etliche Beiträge gewühlt habe und viele Varianten ausprobiert habe und keine fehlerfrei funktionierte habe ich jetzt endlich mal eine die seit Monaten fehlerfrei arbeitet.

Ich nutze TDirMonitor von JUAN CARLOS MOLINOS MESA. Diese arbeitete aber nicht fehlerfrei, ich hatte bei etlichen versuchen sporadische thred Fehler, Sonderzeichen und abgeschnittene Pfad angaben oder auch einen totalen Hänger des Programms.

Mit folgenden Änderungen hat es dann letztendlich doch noch zum Erfolg geführt:

Original:

Code:

Offset: Longint;

Ersetzt durch:

Code:

Offset: DWORD;

Original:

Code:

name:=WideCharToString(@(FileOpNotification^.FileName));

Ersetzt durch:

Code:

name:=WideCharLenToString(@(FileOpNotification^.FileName), FileOpNotification^.FileNameLength div 2);

Original:

Code:

PChar(FileOpNotification) := PChar(FileOpNotification) + Offset;

Ersetzt durch:

Code:

PByte(FileOpNotification) := PByte(FileOpNotification) + Offset;

Einbinden in den Units "RDCWDirMonitor" und "ProcessMonitor" der Units "ShlObj", "ActiveX" und "FileCtrl"

Dies hat nun zum Erfolg geführt.
Das einbinden der Units und die Type änderung des Offsets und eventuell auch andere Änderungen sind vermutlich nicht nötig, aber ich war das weitere rumprobieren satt. So funktioniert es in jedem Fall bei mir auf zwei Rechnern mit Englischem Win2000 und auf zwei Rechnern mit Englischem WinXP seit Monaten fehlerfrei. (Compiliert in Delphi XE unter Win7 Pro X64)

Ich hoffe ich kann damit den anderen die diese Probleme habe / kennen, den weg zum Erfolg etwas verkürzen.
Anbei noch die so geänderte Komponente. (Die Demo entspricht nicht 100% der original Version)

MfG

[Furtbichler]

Das liegt an der unterschiedlichen Definition von 'Char' in den Delphi-Versionen. Früher war das ein Byte, heute sind das zwei.
Du müsstest entweder komplett auf WideChar umschwenken und die entsprechenden Windows-API Funktionen nutzen, oder komplett auf AnsiChar.

[ConnorMcLeod]

<NaiveFrage>
Ginge das auch mit

Delphi-Quellcode:

sizeof(Char)

und allem, das dazugehört?
</NaiveFrage>

[doctor-x]

Das es an der Umstellung des Types PChar liegt habe ich mir fast gedacht.

Ich meine aber es mit PAnsiChar probiert zu haben (ohne Erfolg), kann mich aber auch irren.

Ich wollte diesen Erfolg hier nur veröffentlichen, da ich kein funktionierendes Beispiel hier finden konnte und anderen die mühevolle Sucherei und Probiererei sparen wollte, die sich mit diesem Thema in naher Zukunft konfrontiert sehen^^

Es gibt bestimmt noch ein Dutzend andere Lösungen, aber solange es funktioniert, braucht man ja nicht das Rad neu zu erfinden.

MfG

[Sir Rufo]

Die Komponente ruft eine Windows-API-Funktion auf.
Und bei einem Unicode-Delphi wird auch automatisch die Unicode-Version der API aufgerufen.
Darum funktioniert das auch mit AnsiChar nicht ;)

[Furtbichler]

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

[Sir Rufo]

Zitat:

Zitat von Furtbichler (Beitrag 1144726)

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 (

Delphi-Quellcode:

ProcessMonitor.pas

) statt?
In

Delphi-Quellcode:

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.

Delphi-Quellcode:

ReadDirectoryChanges();

überhaupt ausführen kann - erst dann wird der Thread erzeugt.
Im Thread wiederum lauert man mit

Delphi-Quellcode:

GetQueuedCompletionStatus();

darauf, dass sich etwas geändert hat und liest es dann ebenfalls mit

Delphi-Quellcode:

ReadDirectoryChanges();

aus und feuert das Ereignis.

Habe ich das so richtig verstanden?

Delphi-Quellcode:

GetQueuedCompletionStatus();

habe ich auch als Verursacher für den Absturz im Verdacht. Das scheint selbst blockierend zu sein und damit kommt

Delphi-Quellcode:

if 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.