| Autor |
Beitrag |
AXMD
 
Beiträge: 4006
Erhaltene Danke: 7
Windows 10 64 bit
C# (Visual Studio 2019 Express)
|
Verfasst: Mi 28.07.04 12:26
Hi,
ich bin im Moment auf der Suche nach einem Befehl, mit dem ich einen Ordner mit all seinen Unterordnern und Dateien löschen kann (ohne shlobj, shellapi, ...etc. zu verwenden - das Prog muss klein bleiben).
RmDir von Delphi löscht nur leere Verzeichnisse; alle Dateien und Ordner suchen (SearchRec etc.) ist mir zu aufwendig - ich suche nach einem Befehl wie es ihn schon unter DOS gab (und in der Eingabeaufforderung noch immer gibt):
rd /s "C:\Dokumente und Einstellungen" (nur ein Beispiel  )
bzw. lautlos:
  Quelltext
1:
| rd /s /q "C:\Dokumente und Einstellungen" |
AXMD
|
|
MSCH
Beiträge: 1448
Erhaltene Danke: 3
W7 64
XE2, SQL, DevExpress, DevArt, Oracle, SQLServer
|
Verfasst: Mi 28.07.04 12:39
ohe ShellApi oder FindFirst()/FindNext() wirst du wohl nix finden und weiterhin das DOS Programm nutzen müssen.
grez
msch
_________________ ist das politisch, wenn ich linksdrehenden Joghurt haben möchte?
|
|
AXMD 
Beiträge: 4006
Erhaltene Danke: 7
Windows 10 64 bit
C# (Visual Studio 2019 Express)
|
Verfasst: Mi 28.07.04 12:49
Auch kein Problem. Nur wie ruf ich das Kommando richtig auf - mit WinExec hauts nämlich nicht hin 
AXMD
|
|
MSCH
Beiträge: 1448
Erhaltene Danke: 3
W7 64
XE2, SQL, DevExpress, DevArt, Oracle, SQLServer
|
Verfasst: Mi 28.07.04 13:04
shellexecute('command.com /c rd [Verzeichnis]'...)
grez
msch
_________________ ist das politisch, wenn ich linksdrehenden Joghurt haben möchte?
|
|
MathiasSimmack
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Mi 28.07.04 13:10
 "SHFILEOPERATION" löscht Verzeichnisse mit der Methode des Explorers. Ob leer oder voll, spielt keine Rolle. Und je nach Systemeinstellung werden die Dateien dann wirklich gelöscht oder einfach nur in den Papierkorb geschoben. Abfragen und Animationen sind inkl.
btw: Diese Funktion ist die letzte, die das Programm vergrößert. Vertrau mir! Es ist nämlich eine API-Funktion, und die sind an sich recht genügsam. Was immer dein Programm vergrößert, die "ShellAPI" wird´s nicht sein. 
|
|
AXMD
Beiträge: 4006
Erhaltene Danke: 7
Windows 10 64 bit
C# (Visual Studio 2019 Express)
|
Verfasst: Mi 28.07.04 13:45
Das Dumme ist, dass beide Funktionen besagte Units (shellapi, ...) benötigen...
AXMD
|
|
tommie-lie
Beiträge: 4373
Ubuntu 7.10 "Gutsy Gibbon"
|
Verfasst: Mi 28.07.04 13:53
Ja und? Die ShellApi vergrößert dein Programm nicht signifikant.
Siehe dazu auch | MathiasSimmack hat folgendes geschrieben: | | btw: Diese Funktion ist die letzte, die das Programm vergrößert. Vertrau mir! Es ist nämlich eine API-Funktion, und die sind an sich recht genügsam. Was immer dein Programm vergrößert, die "ShellAPI" wird´s nicht sein. |
_________________ Your computer is designed to become slower and more unreliable over time, so you have to upgrade. But if you'd like some false hope, I can tell you how to defragment your disk. - Dilbert
|
|
MathiasSimmack
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Mi 28.07.04 15:13
Ich weiß nicht, was du hast, @AXMD. Folgendes Programm:
Delphi-Quelltext
1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
| program test;
uses
Windows, ShellAPI;
var
ops : TSHFileOpStruct;
begin
ZeroMemory(@ops,sizeof(ops));
ops.Wnd := 0;
ops.wFunc := FO_DELETE;
ops.pFrom := pchar('g:\lastcrap' + #0#0);
SHFileOperation(ops);
end. |
ist mit Delphi 5 kompiliert 16 kB groß. Wie du siehst, liegt es also definitiv nicht an der Unit. So, mehr habe ich dazu nicht zu sagen. 
|
|
AXMD
Beiträge: 4006
Erhaltene Danke: 7
Windows 10 64 bit
C# (Visual Studio 2019 Express)
|
Verfasst: Do 29.07.04 06:51
Danke. Sorry, dachte, dass shellapi das Prog so vergrößert - war wohl eine andere Unit, die mir mal das Prog so vergrößert hat (ich glaub shlobj).
Eine Frage hätt ich noch: PChar ist zwar eine 0-terminierte Zeichenkette, aber warum sind bei die zwei #0 nach der Zeichenkette, Mathias?
AXMD
|
|
MSCH
Beiträge: 1448
Erhaltene Danke: 3
W7 64
XE2, SQL, DevExpress, DevArt, Oracle, SQLServer
|
Verfasst: Do 29.07.04 08:27
ganz einfach, einfach in der OH schauen:
| Zitat: | typedef struct _SHFILEOPSTRUCT { // shfos
HWND hwnd;
UINT wFunc;
LPCSTR pFrom;
LPCSTR pTo;
FILEOP_FLAGS fFlags;
BOOL fAnyOperationsAborted;
LPVOID hNameMappings;
LPCSTR lpszProgressTitle;
} SHFILEOPSTRUCT, FAR *LPSHFILEOPSTRUCT;
Members
hwnd
Handle of the dialog box to use to display information about the status of the operation.
wFunc
Operation to perform. This member can be one of the following values:
FO_COPY Copies the files specified by pFrom to the location specified by pTo.
FO_DELETE Deletes the files specified by pFrom (pTo is ignored).
FO_MOVE Moves the files specified by pFrom to the location specified by pTo.
FO_RENAME Renames the files specified by pFrom.
pFrom
Pointer to a buffer that specifies one or more source file names. Multiple names must be null-separated. The list of names must be double null-terminated.
pTo
Pointer to a buffer that contains the name of the destination file or directory. The buffer can contain mutiple destination file names if the fFlags member specifies FOF_MULTIDESTFILES. Multiple names must be null-separated. The list of names must be double null-terminated.
fFlags
Flags that control the file operation. This member can be a combination of the following values:
FOF_ALLOWUNDO Preserves undo information, if possible.
FOF_CONFIRMMOUSE Not implemented.
FOF_FILESONLY Performs the operation only on files if a wildcard filename (*.*) is specified.
FOF_MULTIDESTFILES Indicates that the pTo member specifies multiple destination files (one for each source file) rather than one directory where all source files are to be deposited.
FOF_NOCONFIRMATION Responds with "yes to all" for any dialog box that is displayed.
FOF_NOCONFIRMMKDIR Does not confirm the creation of a new directory if the operation requires one to be created.
FOF_RENAMEONCOLLISION Gives the file being operated on a new name (such as "Copy #1 of...") in a move, copy, or rename operation if a file of the target name already exists.
FOF_SILENT Does not display a progress dialog box.
FOF_SIMPLEPROGRESS Displays a progress dialog box, but does not show the filenames.
FOF_WANTMAPPINGHANDLE Fills in the hNameMappings member. The handle must be freed by using the SHFreeNameMappings function. |
grez
msch _________________ ist das politisch, wenn ich linksdrehenden Joghurt haben möchte?
|
|
MathiasSimmack
Ehemaliges Mitglied
Erhaltene Danke: 1
|
Verfasst: Do 29.07.04 08:59
| AXMD hat folgendes geschrieben: | | war wohl eine andere Unit, die mir mal das Prog so vergrößert hat (ich glaub shlobj). |
Das muss noch eine andere Unit sein, @AXMD. Die ShlObj vergrößert das Programm auch nicht wesentlich.
Edit: Die Doppel-#0 am Ende war eigentlich nicht notwendig. Wie du sagtest, ist ja pchar schon null-terminiert. Damit hätte es auch ein #0 getan:
Delphi-Quelltext
1:
| pchar('g:\lastcrap' + #0); |
Der Sinn ist der, dass du auf einen Schlag mehrere Dateien und/oder Verzeichnisse löschen kannst. Jeder Name muss durch das #0-Zeichen vom anderen getrennt sein, bspw.
Delphi-Quelltext
1:
| 'c:\windows'#0'c:\programme'#0'c:\Eigene Dateien'#0#0 |
Das Ende dieses Strings wird dann mit dem zweiten #0-Zeichen erkannt. Den Teil hat MSCH ja auch in seinem Zitat fett markiert.
Das gleiche Prinzip wird bspw. beim nonVCL-Dialog zum Öffnen von mehreren Dateien benutzt. Auch dort würde dir nur ein String zurückgeliefert werden, in dem alle Namen stecken, die jeweils durch #0 voneinander getrennt wird. Und die gleiche Idee haben wir ja auch bei der TFolderBrowser-Klasse umgesetzt, bei der du via Filter entscheiden kannst, wann (sprich: bei welchen Dateien) der Button von SHBrowseForFolder aktiv sein soll.
|
|
