Entwickler-Ecke
Dateizugriff - Merkwürdiges Verhalten beim Löschen in den Papierkorb
wband - Do 12.05.11 08:08
Titel: Merkwürdiges Verhalten beim Löschen in den Papierkorb
Hallo,
vielleicht kann mir mal jemand folgendes merkwürdiges Verhalten von Delphi (Turbo 2006) beim Löschen von Dateien erklären:
Starte ich mein Programm nach dem compilieren aus der IDE heraus, wird die Datei zwar gelöscht, aber nicht in den Papierkorb verschoben. Starte ich die Datei nach den compilieren und einem build außerhalb der IDE, dann wird gelöscht und in den Papierkorb verschoben.
Hier mal der Quelltext eines kleinen Beispielprogramms:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23: 24: 25: 26: 27: 28: 29: 30: 31: 32: 33: 34: 35: 36: 37: 38: 39: 40: 41: 42: 43: 44: 45: 46: 47: 48: 49: 50: 51: 52: 53: 54: 55: 56: 57: 58:
| unit Unit1;
interface
uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, ShellAPI, StdCtrls;
type TForm1 = class(TForm) BDelToBin: TButton; procedure BDelToBinClick(Sender: TObject); private public end;
var Form1: TForm1;
implementation
{$R *.dfm}
procedure TForm1.BDelToBinClick(Sender: TObject); function FileDeleteRB(AFileName:string): boolean; var Struct: TSHFileOpStruct; pFromc: array[0..255] of char; Resultval: integer; begin if not FileExists(AFileName) then begin Result := False; exit; end else begin fillchar(pfromc,sizeof(pfromc),0) ; StrPcopy(pfromc,expandfilename(AFileName)+#0#0) ; Struct.wnd := 0; Struct.wFunc := FO_DELETE; Struct.pFrom := pFromC; Struct.pTo := nil; Struct.fFlags:= FOF_ALLOWUNDO or FOF_NOCONFIRMATION or FOF_SILENT; Struct.fAnyOperationsAborted := false; Struct.hNameMappings := nil; Resultval := ShFileOperation(Struct) ; Result := (Resultval = 0) ; end; end; begin if FileDeleteRB('D:\testdeltorecycle.txt') then showmessage('Erfolgreich in den Papierkorb verschoben') else showmessage('Problem beim Verschieben in den Papierkorb'); end;
end. |
Den Code der Funktion 'FileDeleteRB' habe ich übrigens den Internet entnommen
http://delphi.about.com/cs/adptips1999/a/bltip0899_3.htm
Die Textdatei, die der Funktion übergeben wird, existiert vor dem Löschen in dem Verzeichnis 'D:\' und das Verzeichnis ist auch vorhanden und gültig.
Vielen Dank
wband - Do 12.05.11 10:10
Hallo jasocul,
vielen Dank für die prompte Antwort. Also der Wert von Resultval in der Funktion ist 0 und der Wert von Result ist true - sowohl beim Starten aus der IDE als auch außerhalb. Kann man auf den jpeg sehen, das nach einem Showmessage entstanden ist(siehe Anhänge). Da gibt es nichts weiter auszuwerten - oder?
Also soll doch wohl offensichtlich alles geklappt haben. Was also läuft falsch?
wband - Do 12.05.11 10:47
Hallo an alle,
das Thema hat sich gerade erledigt - ich hatte völlig vergessen, dass ich Delphi mit Adminrechten in einem eingeschränktem Account starte und die gelöschte Datei daher nicht in dessen Papierkorb sonder in dem des Admin gelandet ist!
Danke !
Gerd Kayser - Do 12.05.11 10:51
Versuchs mal so:
Delphi-Quelltext
1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23:
| procedure TForm1.Button1Click(Sender: TObject); var ShFileOp : TShFileOpStruct; DateiName : string; begin DateiName := 'D:\testdeltorecycle.txt'; if not FileExists(DateiName) then ShowMessage('Datei existiert nicht!') else begin FillChar(SHFileOp, SizeOf(SHFileOp), #0); ShFileOp.wFunc := FO_Delete; ShFileOp.pFrom := PChar(Dateiname + #0); ShFileOp.pTo := #0#0; ShFileOp.FFlags := FOF_AllowUndo or FOF_NoConfirmation or FOF_Silent;
if ShFileOperation(ShFileOp) = 0 then ShowMessage('Erfolgreich in den Papierkorb verschoben.') else ShowMessage('Problem beim Verschieben in den Papierkorb.'); end; end; |
Und siehe da, man kann auch ohne extra Funktion oder exit in der Prozedur auskommen. ;-)
wband - Do 12.05.11 10:56
Hi Gerd,
danke - aber das ist mir schon klar und das hatte andere Gruende. Das Beispiel ist aus dem Kontext eines groeserem Projektes entstanden. Aber das konntest Du natuerlich nicht wissen!
Gerd Kayser - Do 12.05.11 11:09
wband hat folgendes geschrieben : |
Aber das konntest Du natuerlich nicht wissen! |
Setz das mal wie in meinem Beispiel um:
1. FillChar von ShFileOp mit #0
2. pFrom und pTo mit Doppel-Null am Ende (nicht nil).
Sonst gibts die abenteuerlichsten Fehler, und man sucht sich dumm und dämlich.
wband - Fr 13.05.11 01:56
Hi Gerd, vielen Dank für den Hinweis. Ich werde das noch einbauen. Hatte schon mal gelesen, das PChar diese Endkennungen braucht, da es ansonsten im Speicher sucht, bis es so was findet und der Wert,den man eigentlich übergeben will dann ganz anders aussehen könnte! Das ist es wohl, was Du meintest, oder?
Gruß Andreas!
Gerd Kayser - Fr 13.05.11 03:05
wband hat folgendes geschrieben : |
Das ist es wohl, was Du meintest, oder? |
Nein. Bei pFrom und pTo können sowohl einzelne Dateinamen als auch eine Liste mit Dateinamen übergeben werden. Die einzelnen Dateinamen werden durch ein #0 getrennt. Das Ende der Liste wird durch eine Doppelnull gekennzeichnet, sonst weiß die Funktion ja nicht, wo die Liste aufhört. Fehlt die Doppelnull, wird über den Speicherbereich der Liste hinaus gelesen, was dann zu einer Fehlermeldung führen
kann, daß die Datei (irgendwelche Hieroglyphen) nicht abgearbeitet werden konnte. Kommt halt darauf an, was am Ende der Liste steht. Es kann gut gehen, muß aber nicht.
wband - Fr 13.05.11 03:35
Ok Danke - wieder was dazu gelernt!
Entwickler-Ecke.de based on phpBB
Copyright 2002 - 2011 by Tino Teuber, Copyright 2011 - 2025 by Christian Stelzmann Alle Rechte vorbehalten.
Alle Beiträge stammen von dritten Personen und dürfen geltendes Recht nicht verletzen.
Entwickler-Ecke und die zugehörigen Webseiten distanzieren sich ausdrücklich von Fremdinhalten jeglicher Art!