FileExistsWait

[Uwe Raabe]

Sowohl CopyFile als auch CopyFileEx sind blockierende Funktionen, die erst dann zurückkommen, wenn der Kopiervorgang abgeschlossen ist. Insofern sollte ein Programm, das erst eine Datei mittels CopyFile (oder TFile.Copy) kopiert und dann weiterverarbeitet, keine Problem mit (noch) nicht existierenden Dateien haben und eine FileExistWait-Routine wäre wohl obsolet.

Ich habe also vermutet, daß der Kopiervorgang von einem anderen Prozess (z.B. Explorer) angestoßen wurde. In dem Fall kann es schon vorkommen, daß man auf die Existenz der Datei warten muss. Es könnte auch sein, daß die Datei nach dem Kopieren noch von einem Virenscanner festgehalten wird, womit aber auch die oben beschriebenen Copy-Ansätze ins Leere laufen würden.

Grundsätzlich habe ich ja auch nicht den Wait-Ansatz an sich in Frage gestellt, sondern lediglich die Nebenwirkungen eines Aufrufs von Application.ProcessMessages zur Diskussion gebracht. Dabei spielt es überhaupt keine Rolle, warum und worauf eigentlich gewartet wird.

Man kann das natürlich machen, muss sich aber darüber in Klaren sein, was das für Auswirkungen hat. Beispiel: der Kopiervorgang wird durch einen Button-Click ausgelöst. Innerhalb des Delay wird ein erneuter Klick ausgeführt. Darf dieser den Kopiervorgang nochmal starten?

Ich weiß nicht, ob jedem besusst ist, was während eines Application.ProcessMessages alles passieren kann. So könnte der Benutzer z.B. das Programm beenden. Das würde im obigen Beispiel zwar vielleicht noch die Delay-Funktion verlassen, aber nicht das FileExistsWait.