CreateProcess > WaitFor..."komplett geladen" > Kill

[SISven]

Tschuldigung für den "tollen" Titel - mir fiehl nix Besseres ein.

Mein Ziel:
Ich möchte ca. 15.000 Dateien sequentiell mit der zugehörigen 'exe' öffnen. Ist die Anwendung
komplett gestartet soll sie auch gleich schon wieder geschlossen werden. Ist ein Fehler beim
Öffnen dieser Datei aufgetreten, soll dieser mitgeloggt werden.
Das Ganze soll eine Art "FileChecker" für Datensicherungen auf CD sein. Es soll also auf korrupte
Dateien überprüft werden.

Wat soll ma sonst machen, wenn man kein anderes BackUp mehr hat. Dumm
gelaufen!!!

WENN IHR EINEN ANDEREN LÖSUNGSWEG KENNT ALS ALLE DATEIEN ABKLAPPERN - DANN HER DAMIT!!!

Meine Probleme:

1. Wie kriege ich mit ob die gestartete Anwendung fertig geladen ist und "keine" CPU-Auslastung
mehr hervorruft?

2. Wie komme ich an event. Fehlermeldungen von z.B. Word, Excel, Acrobat,...u.s.w. ran?
z.B.: "Die Datei ist beschädigt...bla,bla,bla."

Mein bisheriger Ansatz:

CreateProcess(...AppName und FileName...);

Delphi-Quellcode:

        repeat

          iReturn := MsgWaitForMultipleObjects(1,
                                               ProcessInfo.hProcess,
                                               FALSE,
                                               1000,
                                               QS_ALLEVENTS);

          if iReturn <> (WAIT_OBJECT_0) then
            Application.ProcessMessages;

        until iReturn = (WAIT_OBJECT_0);

Auf Events warten und selbst PostMessage(WM_CLOSE) oder sowas senden, wenn die Anwendung "oben" ist.

Tja - und für das Fehlerabfangen hab ich noch gar keinen blassen Schimmer. Schön wärs natürlich wenn die eigentliche Fehlermeldung der Anwendung erst gar nicht angezeigt wird.


Meine teuflischste Vorstellung ist überhaupt gar nichts sichtbar zu machen. Also die Anwendung auch nicht anzeigen. Wenn sowas ginge - dat wär schon der Hammer!


OS: Win 2000/XP Pro (sollte auf beiden laufen - muss aber net)
Dev: Delphi 7.0 Pro

[Christian Seehase]

Moin SISven,

erst einmal herzlich willkommen hier in der Delphi-PRAXiS.

Für die Prüfung, ob die Anwendung vollständig gestartet ist, solltest Du Dir mal die Funktion WaitForInputIdle anschauen.
Voraussetzung: Die zu prüfende Anwendung ist keine Konsolenanwendung.

[SISven]

Danke für's "Herzliche Willkommen"!

WaitForInputIdle habe ich auch schon ausprobiert. Laut "msdn" wäre das ja genau das was ich brauche. Allerdings klappt das nicht. Ich vermute mal das der aktuelle ProzessHandle, in meinem Beispiel..

ProcessInfo.hProcess ... hier nicht ausreicht. Man wird wohl das Handle von dem gerade aktiven Fenster der Anwendung brauchen. Aber wie kommt man da ran?

Wenn jede Anwendung eine Message schicken würde, sobald sie im Idle Zustand ist wär ja alles in Butter. Dann könnte ich ja in meiner RepeatUntil-Schleife auf eine ganz bestimmte Message warten.

Aber ich versuchs doch noch mal mit "WaitForInputIdle" - vielleicht hab ich ja irgendwas falsch gemacht.

[SirThornberry]

Wenn du die orginal-Dateien noch hast würde ich dir empfehlen die Originaldatei komplett mit der Zieldatei (backup) zu vergleichen. Also Quelldatei laden, dann zieldatei laden und prüfen ob beide gleich groß sind, ist dies der fall dann als nächstes alle bytes durchgehen und prüfen ob diese auch identich sind. Einfach ein programm öffnen halte ich nicht für sinnvoll denn bei beschädigten jpegs kommt es nicht zwangsläufig zum fehler beim öffnen, jedoch wird das bild fehlerhaft dargestellt

[Ratte]

Hi,

das Handle kriegst du mit findwindow, aber SirThornberry hat recht. Evt. solltest du sogar die Dateien byteweise vergleichen. Du könntest auch das Microsofttool Windiff aufrufen.

Ratte

[nailor]

ja, würde auch bit für bit vergeleichen vorschlagen. dann erkennt man zwar keine von vornherein (also schon auf der festplatte kaputten daten), aber du kannst ziemlich sicher (eigentlich so sicher wie es irgend geht) sein, dass deine daten auf der cd nicht anders sind als die auf der festplatte

[SISven]

Ich hab keine original Dateien mehr. Ich will nur aus einer Menge gegebener Dateien ermitteln welche davon im Eimer sind.

Also mit bit bzw. byteweisem Vergleich is hier nix.

Bin trotzdem für alle Alternativen offen!

[nailor]

falls du wirklich viel schrott hast, wäre natürlich der test, ob sich die datei öffnen lässt, eine möglichkeit die kaputten auszusortieren. was nicht öffnet, ist futsch. aber es is noch nicht gesagt, ob sich nicht auch manchmal zerstörte dateien öffnen lassen, wo dann hinterher nur irgendwelche werte zerstört sind.

[SISven]

Das ist schon klar, dass ich damit keine 100%ige Sicherheit habe. Ich habe aber wenigstens einen groben Anhaltspunkt über den Zustand der meisten Dateien.

[Christian Seehase]

Moin SISven,

Du könntest ja mal versuchen gezielt zu ermitteln, welcher ExitCode von dem Prozess zurückgegeben wird, wenn die Daten nicht gelesen werden können, und dann mit GetExitCodeProcess prüfen, ob die Datei Ok ist oder nicht.
Vorab aussieben könntest Du die richtig beschädigten aber schon, indem Du alle Dateien mittels XCOPY schon einmal kopierst.
Mit dem Parameter /C würde dann auch im Fehlerfalle das Kopieren fortgesetzt werden. Dann müsstest Du Dir nur noch die Fehlermeldungen in eine Datei umleiten, um gezielt auslesen zu können, welche nicht kopiert werden konnten.
Der Aufruf könnte also z.B. so aussehen:

Code:

xcopy <QUELLE> <ZIEL> /C 2>c:\temp\errorlog.txt

Weitere eventuell nützliche Parameter dafür kannst Du Dir ja noch heraussuchen.

Die 2 vor dem > sollte alle Fehlermeldungen in die Datei umleiten (mit einer 1 wären es die Standardmeldungen)