Autor |
Beitrag |
wband
Hält's aus hier
Beiträge: 13
|
Verfasst: Do 12.05.11 08:08
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:
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 delphi.about.com/cs/...99/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
|
|
jasocul
      
Beiträge: 6393
Erhaltene Danke: 147
Windows 7 + Windows 10
Sydney Prof + CE
|
Verfasst: Do 12.05.11 09:42
Dann solltest du mal den genauen Result-Wert ansehen.
Hier ist eine Liste zu finden: msdn.microsoft.com/e...64%28v=vs.85%29.aspx
|
|
wband 
Hält's aus hier
Beiträge: 13
|
Verfasst: 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?
Einloggen, um Attachments anzusehen!
|
|
wband 
Hält's aus hier
Beiträge: 13
|
Verfasst: 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
      
Beiträge: 632
Erhaltene Danke: 121
Win 7 32-bit
Delphi 2006/XE
|
Verfasst: 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 
Hält's aus hier
Beiträge: 13
|
Verfasst: 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
      
Beiträge: 632
Erhaltene Danke: 121
Win 7 32-bit
Delphi 2006/XE
|
Verfasst: 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 
Hält's aus hier
Beiträge: 13
|
Verfasst: 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
      
Beiträge: 632
Erhaltene Danke: 121
Win 7 32-bit
Delphi 2006/XE
|
Verfasst: 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 
Hält's aus hier
Beiträge: 13
|
Verfasst: Fr 13.05.11 03:35
Ok Danke - wieder was dazu gelernt!
|
|