Hallo,

ich wollte mal fragen wie man festellen kann wann eine datei verschoben werden soll und von wo nach wo sie das tut? Gibt es dafür ein message? Ich wollte nämlich überprüfen ob eventeull gerade eine datei verschoben soll, die mein programm gerade verwendet, wenn das der fall ist, soll mein programm die datei freigeben, damit sie auch wirklich verschoben werden kann. also müsste die abfrage kommen bevor von windows eine fehlermeldung kommt dass die datei gerade verwendet wird.

danke im vorraus!
mfg tartare

Guck dir mal FINDFIRSTCHANGENOTIFICATION/ und READDIRECTORYCHANGESW an.

Nebenbei gesagt, ich würde mich darum nicht kümmern. Das Programm welches die Datei verschieben will, sollte sich darum kümmern. Und zwar das Verschieben abrrechen, wenn dies nicht möglich ist. Denn warum hat dein Proramm die datei geöffnet? Doch wohl, weil es die Datei braucht. Und warum braucht dein Programm die Datei plötzlich nicht mehr, wenn sie von einm anderen Programm verschoben werden soll?

Es geht darum, wenn der benutzer sich überlegt die datei im explorer einfach umzubenennen oder zu verschieben dies tun kann indem das programm die datei kurz freigibt und sie nach dem vorgang wieder lädt und an die richtige stelle setzt. dazu muss ich aber auch wissen wohin er sie verschiebt oder in was er sie umbenennt. Oder hat vielleicht jemand ein gutes tutorial oder weiß wo ich herausfinde wie man die TShellChangNotifier Komponente in Delphi 7 verwendet?

tartare hat folgendes geschrieben:

Es geht darum, wenn der benutzer sich überlegt die datei im explorer einfach umzubenennen oder zu verschieben dies tun kann indem das programm die datei kurz freigibt und sie nach dem vorgang wieder lädt und an die richtige stelle setzt.

Glaubst du, der User findet es besser, wenn die Datei einfach *plopp* wieder zurückverschoben wird, anstatt dass er eine anständige Fehlermeldung von wegen, dass die Datei gerade verwendet wird, bekommt?

Hi,

Wenn ich das richtig verstand habe, soll die Datei freigegeben werden. Dann soll der Vorgang ausgeführt werden und anschließend die Datei aus der neuen Url wieder geöffnet werden.

mfG,

@yogu, nein, ich will doch gar nicht, dass die datei wieder zurück verschoben wird, ich will, dass sie einfach nur freigegeben wird, dann überwacht wird, wohin sie verschoben wird oder in was sie umbenannt wird und danach soll die datei an neuem ort oder mit neuem namen wieder geladen werden. Ich möchte den benutzer nicht beschränken sondern ihm die möglichkeit geben, eine eigentlich benutzte datei zu verschieben oder umzubennen. in kurz, eigentlich so wie hidden geschrieben hat. Ich wollte es gern mit der ShellChangeNotifier komponente machen, aber ich weiß nicht wie ich dort im changeereignis dateinamen und pfade oder handels auf dateien erhalten soll und ich finde nichts dazu in google.

tartare hat folgendes geschrieben:

@yogu, nein, ich will doch gar nicht, dass die datei wieder zurück verschoben wird, ich will, dass sie einfach nur freigegeben wird, dann überwacht wird, wohin sie verschoben wird oder in was sie umbenannt wird und danach soll die datei an neuem ort oder mit neuem namen wieder geladen werden.

Oh, da habe ich wohl was dazugedichtet.

TShellChangeNotifier habe ich zwar noch nie verwendet, aber dem Source nach zu schließen, bekommt man dadurch den Dateinamen nicht raus. Aber du könntest den Pfad auf den Dateipfad setzen, Unterverzeichnisse ausschließen (Option drunter), und beim Ereignis prüfen, ob die Datei noch da ist. Das Problem ist, dass dann die Fehlermeldung schon angezeigt wurde.

Du müsstest irgendwie den Explorer beeinflussen, IMHO geht das nicht mit Shell.

Ist btw auch wieder so 'ne Sache, die MS imho hätte grundsätzlich einbauen können: Wenn eine Datei verschoben werden soll Anwendungen einfrieren und dann neuen Namen übertragen..

Und wie soll Microsoft diesen Mechanismus in meine Programme einbauen? Und wie soll das mit der Performance aussehen, wenn Windows für alle Programme sämtliche Verzeichnisse von geöffneten Dateien überwachen soll?

Luckie hat folgendes geschrieben:

Und wie soll Microsoft diesen Mechanismus in meine Programme einbauen?

Das wäre ja lediglich eine Erweiterung des Explorers. Die FileHandles können durch eine beliebige Anwendung ausgelesen und entfernt werden, wie FileUnlocker von SAiBOT beweist. Die FileHandles müssten vor dem Umbenennen einfach nach dem Dateinamen durchsucht, die Treffer zwischengespeichert und entfernt, die Datei verschoben, die zwischengespeicherten Handles aktualisiert und schließlich wieder hinzugefügt werden. Während dieses Prozesses braucht der Explorer die Priorität "Echtzeit", um alle anderen Anwendungen einzufrieren. Soviel dazu.

Luckie hat folgendes geschrieben:

Und wie soll das mit der Performance aussehen, wenn Windows für alle Programme sämtliche Verzeichnisse von geöffneten Dateien überwachen soll?

Der ganze Code würde ja nur ausgeführt, wenn eine Datei verschoben wird. Ist ja alles im Explorer integriert.

Aber da es nicht so ist, ist das alles Theorie und bringt diesen Thread nicht wirklich weiter...

(Sorry für's OffTopic-Posten, aber das wollte ich einfach loswerden. )

Damit wäre zwar das Dateihandle in meiner Anwendung noch gültig, aber der Pfad nicht mehr. Bisher würde ich das Öffnen und Speichern so lösen: In einer globalen Variable speichere ich den Pfad und den Dateinamen, wenn eine Datei mit dem Öffnen-Dialog geöffnet wird. Klick der Benutzer jetzt auf "Speichern", würde ich prüfen, ob diese Varaibale leer ist. Ist sie leer wird der "Speichern"-Dialog geöffnet, ist sie nicht leer, wird der Pfad zum Speichern genutzt. Dies geht aber nicht mehr, wenn die Datei verschoben wurde, da dann mein vorher gemerkter Pfad nicht mehr gültig ist. Jetzt müsste Windows entweder noch etwas implemntieren, was die Zugriffe über den Pfad umbiegt oder jegliche Zugriffe müssten über das Handle erfolgen. Dies wiederum würde bedeuten, dass es möglich sein muss vom Handle auf den Pfad zu schliessen, was aber wie der von dir erwähnte FileUnlocker gezeigt hat, bisher im Usermode nicht möglich ist.

Letztendlich ist es doch nicht so einfach, wie du dir das vorstellst. Schön wäre es bestimmt, aber doch mit einem erheblichen Umbau der bisherigen internen Dateiverwaltung von Windows verbunden.