DeleteFile und die Datei ist immer noch da

[nahpets]

Der TEmbeddedWB kapselt doch den IE und der guckt erstmal in den Cache. Könnte es sein, dass Du deshalb nicht die veränderte Seite zu sehen bekommst?

Nach 'nem Programmneustart weiß der dann nicht mehr, dass er die Datei schonmal angezeigt hat, zeigt sie daher neu an, wozu er die aktuelle Datei nutzt.

Wäre zumindest mal 'ne Prüfung wert, ob da so ein Effekt vorhanden sein könnte.

[t.roller]

Delphi-Quellcode:

procedure TForm.ButtonClick(Sender: TObject);
var Flags: OLEVariant;

begin
  Flags:=4; //NavNoReadFromCache
  WebBrowser1.Navigate('http://www.xxxxx.com/', Flags);
end;

[fs999]

Zitat von Luckie:

Fehlerbehandlung irgendwie?

Keine Fehler.

Zitat von nahpets:

Der TEmbeddedWB kapselt doch den IE und der guckt erstmal in den Cache. Könnte es sein, dass Du deshalb nicht die veränderte Seite zu sehen bekommst?

Es ist nicht auf der Internetseite wo ich das sehe, aber im Windows Explorer. Und die Internetseite uploaded die Datei ja, sie kann nicht im Cache sein.

Ich habe vergessen zu sagen dass das nur auf Windows 10 vorkommt, nicht auf Windows 7.
Ist es möglich dass das Programm in eine Virtual Machine läuft ohne das man es weiß ?

[Luckie]

Ich wollte wissen, ob du eine Fehlerbehandlung in deinem Code hast. Zum Beispiel ob der Rückgabewert von 8i]delteFile[/i] geprüft wird und wenn es fehlschlägt, was als Fehlermeldung ausgegeben wird.

[Pixel]

Also um das was Luckie gefragt hat nochmals zu verdeutlichen:

Delphi-Quellcode:

procedure checkErrorDeleteFile(const path : string);
begin
  SetLastError(0);
  DeleteFile(path);
  ShowMessage(IntToStr(GetLastError));
end;

Anschließend kannst du hier nach dem Errorcode der in der Messagebox angezeigt wurde suchen, dann weißt du was das Problem ist in der Regel.

[himitsu]

Ähhhhh, FALSCH und FALSCH.

siehe DeleteFile

Delphi-Quellcode:

procedure checkErrorDeleteFile(const path : string);
begin
  //SetLastError(0);  // das heißt LAST-Error und nicht THIS-Error
  is not DeleteFile(PChar(path)) then  // rate mal, warum der Wert von GetLASTError nur "definitert" ist, wenn es einen Fehler gab :roll:
    //ShowMessage(IntToStr(GetLastError));  //ShorMessage als Fehlerbehandlung?
    RaiseLastOSError;  // aka raise Exception.Create(SysErrorMessage(GetLastError));
end;

Sorry, es gibt zwar viele Wege, um nach Rom zu kommen, aber man sollte niemals nach links gehn, wenn dort ein Schild "rechts" steht.

[Erdbär]

Wie wäre es, wenn Du vor dem Hochladen der (neuen) Datei die (alte) Datei auf dem Server löschen lassen würdest und dann ein paar Sekunden warten würdest, damit der Server den Löschbefehl auch ausführen kann?

[Pixel]

Zitat von himitsu:

Ähhhhh, FALSCH und FALSCH.

siehe DeleteFile

Delphi-Quellcode:

procedure checkErrorDeleteFile(const path : string);
begin
  //SetLastError(0);  // das heißt LAST-Error und nicht THIS-Error
  is not DeleteFile(PChar(path)) then  // rate mal, warum der Wert von GetLASTError nur "definitert" ist, wenn es einen Fehler gab :roll:
    //ShowMessage(IntToStr(GetLastError));  //ShorMessage als Fehlerbehandlung?
    RaiseLastOSError;  // aka raise Exception.Create(SysErrorMessage(GetLastError));
end;

Sorry, es gibt zwar viele Wege, um nach Rom zu kommen, aber man sollte niemals nach links gehn, wenn dort ein Schild "rechts" steht.

FALSCH FALSCH FALSCH FALSCH FALSCH FALSCH FALSCH FALSCH FALSCH FALSCH FALSCH

Ich glaube du hast GetLasterror/SetLastError nicht so ganz verstanden.

SetLastError(0) setzt nur den Fehler auf 0 (ERROR_SUCCESS). Das ist beim Debugging einer Fehlerbehandlung empfehlenswert und manchmal sogar notwendig, denn sonst kann man nicht zu 100% sagen ob der Fehler dem nächsten Befehl zugeordet ist.

GetLastError "nur definiert wenn es einen Fehler gab": Wenn es keinen Fehler gab, dann ist GetLastError 0 (ERROR_SUCCESS). Einen Wert bekommst du immer zurück und wenn alles gut ging, dann eben 0.

Zitat aus MSDN: https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx

Zitat:

That is because some functions call SetLastError with a zero when they succeed, wiping out the error code set by the most recently failed function.

Beispiel:

WriteFile(x,x,x,x,x); SetLastError(5) -> ERROR_ACCESS_DENIED
deletefile(x); SetLastError(0) -> ERROR_SUCCESS
GetLastError(); Ausgabe: 0

Wenn GetastError() jetzt 0 (ERROR_SUCCESS) zurückliefert, dann würde der Anfänger meinen beide Funktionen seien erfolgreich durchlaufen, wobei hier in dem Fall deletefile einfach den Fehlercode "5" von writefile mit "0" überschrieben hat-


Meine Funktion diente nur zum debugging und funktioniert wunderbar. Klar, das SetLastError() kann man auch weglassen und dann mit "is not deletefile()" arbeiten ich finde es eben anders besser, es könnte ja rein theoretisch sein, dass LastError schon einen Fehlerwert hat bevor deletefile aufgerufen wird und dann obwohl deletefile fehlschlägt lasterror nicht updated/überschrieben wird. Ist zwar praktisch so gut wie unmöglich aber allein dass es theoretisch so sein könnte hält mich davon ab bei sowas SetLastError(0) wegzulassen.

"Sorry, es gibt zwar viele Wege, um nach Rom zu kommen, aber man sollte niemals nach links gehn, wenn dort ein Schild "rechts" steht." Vor allem sollte man erst mal das richtige Schild suchen https://msdn.microsoft.com/de-de/lib...(v=vs.85).aspx und dann das Schild lesen bevor man los geht.

[himitsu]

GetLastError gibt per Definition den letzten Fehler zurück,
aber da ständig irgenwelche Trottel mit SetLastError rumpfuschen und solche arbeiten auch bei Microsoft selber, stimmt das eben nicht immer.

Und mit SetLastError setzt man einen "neuen" Fehlercode, womit er dann der Letzte ist.

PS: 0 ist auch ein "Fehler Code", weswegen es auch einen beliebten Fehler in der Fehlerbehandlung gibt.
operation_completed_succesfully_error_funny_error_messages-s355x201-95216-580.jpg



Auch kann eine Unterfunktion, einen Fehler auslösen, selbst wenn die Hauptfunktion letztendlich korrekt durchlief.

Beispiel Anhand einer imaginären Dateikopierfunktion ala CopyFile:
Zuerst mal mit GetMem großen Speicher anfragen,
wenn nicht genug RAM frei, dann nochmal nach kleinerem Speicher fragen (das ging jetzt)
dann über dem Speicher kopieren und fertig.

GetMem sagte nun einmal Fehler, womit der Fehlercode gesetzt wurde
aber CopyFile sagt dennoch TRUE, da ja doch noch kopiert werden konnte.
Vorher SetLastError(0) würde also garnichts bringen.


Somit ist, laut MSDN für DeleteFile folgender Code falsch

Delphi-Quellcode:

SetLastError(0);
DeleteFile(...);
DeleteFile(...);
DeleteFile(...);
DeleteFile(...);
if GetLastError <> 0 then
  ZeigeFehler(GetLastError);

Denn GetLastError kann auch ungleich 0 sein, selbst wenn alles erfogreich war
und wenn DeleteFile oder eine Unterfunktion intern auch mit SetLastError(0) rumpfuscht, dann würde ein nachfolgendes DeleteFile den Fehler des Vorherrigen verdecken.

Delphi-Quellcode:

B := DeleteFile(...);
B := B and DeleteFile(...);
B := B and DeleteFile(...);
B := B and DeleteFile(...);
if not B then
  ZeigeFehler(GetLastError);

GetLastError wird nur ausgewertet, wenn mindestens ein Result FALSE sagte
und nachfolgende DeleteFile werden nicht aufgerufen, wenn vorher was schief lief, denn DeleteFile sagt in der Doku nicht, dass vorherriger ErrorCode erhalten bleibt, im Erfolgsfall.

[fs999]

Zitat von Luckie:

Ich wollte wissen, ob du eine Fehlerbehandlung in deinem Code hast. Zum Beispiel ob der Rückgabewert von 8i]delteFile[/i] geprüft wird und wenn es fehlschlägt, was als Fehlermeldung ausgegeben wird.

Ja.

Delphi-Quellcode:

if not DeleteFile(s) then
begin
  ShowMessage('Datei konnte nicht gelöscht werden !');
  Abort;
end;

Zitat von Erdbär:

Wie wäre es, wenn Du vor dem Hochladen der (neuen) Datei die (alte) Datei auf dem Server löschen lassen würdest und dann ein paar Sekunden warten würdest, damit der Server den Löschbefehl auch ausführen kann?

Welchen Server ? Die Datei wird in C:\ProgramData\xxx unterlegt.