RenameDir : Nichts passiert

Horschdware · Verfasst: Do 29.01.04 01:36

Ich habe ein Problem beim Umbenennen von Ordnern.
Manchmal weigert der sich einfach einen Ordner umzubenennen.

Beispiel:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:

procedure TFEinstellungen.RenameDir(DirFrom, DirTo: string);
var
  shellinfo: TSHFileOpStruct;  
begin  
  with shellinfo do  
  begin  
    Wnd    := 0;
    wFunc  := FO_RENAME;  
    pFrom  := PChar(DirFrom);  
    pTo    := PChar(DirTo);  
    fFlags := FOF_FILESONLY or FOF_ALLOWUNDO or  
              FOF_SILENT or FOF_NOCONFIRMATION;  
  end;  
  SHFileOperation(shellinfo);  
end;

...
procedure TFEinstellungen.Button1Click(Sender: TObject);
begin
RenameDir('C:\Games\NewHope\gp3','C:\Games\NewHope\Grafiken');
end;

nichts passiert.
wenn ich jetzt aber den gp3 ordner einfach mal per hand in gp umbenenne und dann das so aufrufe

markieren

Delphi-Quelltext

1:
2:
3:
4:

procedure TFEinstellungen.Button1Click(Sender: TObject);
begin
RenameDir('C:\Games\NewHope\gp','C:\Games\NewHope\Grafiken');
end;

dann gehts komischerweise.
das ist mir jetzt schon ein paar mal aufgetreten und es ist einfach nicht ok für mich wenn der befehl mal tut und mal nicht. wenn er mal nicht tut kann ich auch den button sooft klicken wie ich will, es tut sich einfach null.

ist das bekannt? was kann man da machen?[/code]

_________________
Delphi: XE - OS: Windows 7 Professional x64

MaxiTB · Verfasst: Do 29.01.04 09:46

Zitat:

SHFileOperation
Copies, moves, renames, or deletes a file system object.

int SHFileOperation(
LPSHFILEOPSTRUCT lpFileOp
);

Parameters
lpFileOp
[in] Address of an SHFILEOPSTRUCT structure that contains information this function needs to carry out the specified operation. This parameter must contain a valid value that is not NULL. You are responsibile for validating the value. If you do not validate it, you will experience unexpected results.
Return Values
Returns zero if successful, or nonzero otherwise.

Remarks
You should use fully-qualified pathnames with this function. Using it with relative path-names is not thread-safe.

With two exceptions, you cannot use SHFileOperation to move special folders from a local drive to a remote computer by specifying a network path. The exceptions are the MyDocs and MyPics folders (CSIDL_PERSONAL and CSIDL_MYPICTURES, respectively).

When used to delete a file, SHFileOperation will attempt to place the deleted file in the Recycle Bin. If you wish to delete a file and guarantee that it will not be placed in the Recycle Bin, use DeleteFile.

If a copy callback handler is exposed and registered, SHFileOperation will call it unless you set a flag such as FOF_NOCONFIRMATION in the fFlags member of the structure pointed to by lpFileOp. See ICopyHook::CopyCallback for details on implementing copy callback handlers.

File deletion is recursive unless you set the FOF_NORECURSION flag in lpFileOp.

With Microsoft® Windows 2000® and later, it is possible to connect an HTML file with a folder containing related files such as GIF images or style sheets. If file connection is enabled, when you move or copy the HTML file, all of the files in the folder will be moved or copied as well. Conversely, if you move the folder with the related files, the HTML file is also moved.

The HTML file must have a .htm or .html extension. You create the connection to the related files by placing them in a subfolder of the folder containing the HTML file. The folder must have the name of the HTML file followed by " files". For example, if the HTML file is MyFile.htm, the folder should be named "MyFile files". Any files you place in the "MyFile files" subfolder will be connected to MyFile.htm.

File connection is enabled by default. It can be disabled by adding a REG_DWORD value, NoFileFolderConnection, to the HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer registry key. Setting NoFileFolderConnection to 1 disables file connection. If the value is set to zero or is missing, file connection is enabled.

To move only specified files from a group of connected files, set the FOF_ NO_CONNECTED_ELEMENTS flag in the fFlags member of the structure pointed to by lpFileOp.

Note that the use of a folder with a name like "MyFile files" to define a connection may not be valid for localized versions of Windows NT. The term "files" may need be replaced by the equivalent word in the local language.

Windows 95/98/Me: SHFileOperation is supported by the Microsoft Layer for Unicode. To use this, you must add certain files to your application, as outlined in Microsoft Layer for Unicode on Windows 95/98/Me Systems.

Requirements
Version 4.00 and later of Shell32.dll

Windows NT/2000: Requires Windows NT 4.0 or later.
Windows 95/98/Me: Requires Windows 95 or later.
Header: Declared in Shellapi.h.
Import Library: Shell32.lib.

Das sagt die gute, alte MSDN ... ich würde mal schnell den Return-Value testen ...

Zitat:

SHFILEOPSTRUCT
Contains information that the SHFileOperation function uses to perform file operations.

typedef struct _SHFILEOPSTRUCT{
HWND hwnd;
UINT wFunc;
LPCTSTR pFrom;
LPCTSTR pTo;
FILEOP_FLAGS fFlags;
BOOL fAnyOperationsAborted;
LPVOID hNameMappings;
LPCTSTR lpszProgressTitle;
} SHFILEOPSTRUCT, *LPSHFILEOPSTRUCT;

Members

hwnd
Window handle to the dialog box to display information about the status of the file operation.

wFunc
Value that indicates which operation to perform. This member can be one of the following values:

FO_COPY
Copy the files specified in the pFrom member to the location specified in the pTo member.

FO_DELETE
Delete the files specified in pFrom.

FO_MOVE
Move the files specified in pFrom to the location specified in pTo.

FO_RENAME
Rename the file specified in pFrom. You cannot use this flag to rename multiple files with a single function call. Use FO_MOVE instead.

pFrom
Address of a buffer to specify one or more source file names. These names must be fully qualified paths. Standard DOS wild cards, such as "*", are permitted in the file-name position. Although this member is declared as a null-terminated string, it is used as a buffer to hold multiple file names. Each file name must be terminated by a single NULL character. An additional NULL character must be appended to the end of the final name to indicate the end of pFrom.

pTo
Address of a buffer to contain the name of the destination file or directory. This parameter must be set to NULL if it is not used. Like pFrom, the pTo member is also a double-NULL terminated string and is handled in much the same way. However, pTo must meet the following specifications:
Wildcard characters are not supported.
Copy and Move operations can specify destination directories that do not exist and the system will attempt to create them. The system normally displays a dialog box to ask the user if they want to create the new directory. To suppress this dialog box and have the directories created silently, set the FOF_NOCONFIRMMKDIR flag in fFiles.
For Copy and Move operations, the buffer can contain multiple destination file names if the fFlags member specifies FOF_MULTIDESTFILES.
Pack multiple names into the string in the same way as for pFrom.
Use only fully-qualified path names. Using relative path names will have unpredictable results.

fFlags
Flags that control the file operation. This member can take a combination of the following flags: Flag Description

FOF_ALLOWUNDO Preserve Undo information, if possible. If pFrom does not contain fully qualified path and file names, this flag is ignored.

FOF_CONFIRMMOUSE Not currently used.

FOF_FILESONLY Perform the operation on files only if a wildcard file name (*.*) is specified.

FOF_MULTIDESTFILES 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 Respond with "Yes to All" for any dialog box that is displayed.

FOF_NOCONFIRMMKDIR Do not confirm the creation of a new directory if the operation requires one to be created.

FOF_NO_CONNECTED_ELEMENTS Version 5.0. Do not move connected files as a group. Only move the specified files.

FOF_NOCOPYSECURITYATTRIBS Version 4.71. Do not copy the security attributes of the file.

FOF_NOERRORUI Do not display a user interface if an error occurs.

FOF_NORECURSION Only operate in the local directory. Don't operate recursively into subdirectories.

FOF_RECURSEREPARSE Recurse into reparse points. The default is to not recurse.

FOF_NORECURSEREPARSE Treat reparse points as objects, not containers. You must set _WIN32_WINNT to 5.01 or later to use this flag. See Shell and Common Controls Versions for further discussion of versioning.

FOF_RENAMEONCOLLISION Give the file being operated on a new name in a move, copy, or rename operation if a file with the target name already exists.

FOF_SILENT Do not display a progress dialog box.

FOF_SIMPLEPROGRESS Display a progress dialog box but do not show the file names.

FOF_WANTMAPPINGHANDLE If FOF_RENAMEONCOLLISION is specified and any files were renamed, assign a name mapping object containing their old and new names to the hNameMappings member.

FOF_WANTNUKEWARNING Version 5.0. Send a warning if a file is being destroyed during a delete operation rather than recycled. This flag partially overrides FOF_NOCONFIRMATION.

fAnyOperationsAborted
Value that receives TRUE if the user aborted any file operations before they were completed, or FALSE otherwise.
hNameMappings
A handle to a name mapping object containing the old and new names of the renamed files. This member is used only if the fFlags member includes the FOF_WANTMAPPINGHANDLE flag. Treat hNameMappings as a pointer to a structure whose members are an UINT value followed by a pointer to an array of SHNAMEMAPPING structures, e.g.:
struct HANDLETOMAPPINGS {
UINT uNumberOfMappings; // number of mappings in array
LPSHNAMEMAPPING lpSHNameMapping; // pointer to array of mappings
};

The UINT value is set to the number of SHNAMEMAPPING structures in the array. Each SHNAMEMAPPING structure contains the old and new path name for one of the renamed files (see remarks).
Note: The handle must be freed with SHFreeNameMappings.

lpszProgressTitle
Address of a string to use as the title of a progress dialog box. This member is used only if fFlags includes the FOF_SIMPLEPROGRESS flag.

Remarks
If the pFrom or pTo members are unqualified names, the current directories are taken from the global current drive and directory settings as managed by the GetCurrentDirectory and SetCurrentDirectory functions.

If pFrom is set to a file name, deleting the file with FO_DELETE will not move it to the Recycle Bin, even if the FOF_ALLOWUNDO flag is set. You must use a full path name.

There are two versions of this structure, an ANSI version (SHFILEOPSTRUCTA) and a Unicode version (SHFILEOPSTRUCTW). The Unicode version is identical to the ANSI version, except that wide character strings (LPCWSTR) are used in place of ANSI character strings (LPCSTR). On Windows 98 and earlier, only the ANSI version is supported. On Windows NT 4.0 and later, both the ANSI and Unicode versions of this structure are supported. SHFILEOPSTRUCTW and SHFILEOPTSTRUCTA should never be used directly; the appropriate structure is redefined as SHFILEOPSTRUCT by the pre-compiler depending on whether the application is compiled for ANSI or Unicode. SHNAMEMAPPING has similar ANSI and Unicode versions. For ANSI applications, hNameMappings points to an integer followed by an array of ANSI SHNAMEMAPPING structures. For Unicode applications, hNameMappings points to an integer followed by an array of Unicode SHNAMEMAPPING structures. However, on Windows NT 4.0 and later, SHFileOperation always returns a handle to a Unicode set of SHNAMEMAPPING structures. If you want applications to be functional with all versions of Windows, the application must employ conditional code to deal with name mappings. For example:

x = SHFileOperation(&shop);
...
if (fWin9x) {

HandleAnsiNameMappings(shop.hNameMappings);

}
else {

HandleUnicodeNameMappings(shop.hNameMappings);

}

See Also
For a complete application that uses the SHFILEOPSTRUCT structure and explains how to set up the SHNAMEMAPPING structure, see the Knowledge Base Article Q151799 at support.microsoft.co...ticles/Q151/7/99.asp.

Requirements
Version 4.00 and later of Shell32.dll

Windows NT/2000: Requires Windows NT 4.0 or later.
Windows 95/98/Me: Requires Windows 95 or later.
Header: Declared in Shellapi.h.

Also ich tippe mal stark, das das FOF_FILESONLY Probleme macht beim Verzeichnisumbenennen ...

_________________
Euer Mäxchen
Wer früher stirbt, ist länger tot.

Ehemaliges Mitglied Erhaltene Danke: 1

MaxiTB hat folgendes geschrieben:

Also ich tippe mal stark, das das FOF_FILESONLY Probleme macht beim Verzeichnisumbenennen ...

Bist du sicher? Ich habe den Beispielcode von Horschdware eben mal 1:1 ausprobiert, und der Ordner ließ sich auch mit diesem Flag problemlos umbenennen - in jedem Fall übrigens und nicht bloß ab und zu. Vielleicht war´s aber auch nur Zufall ...

Abgesehen davon, @MaxiTB, hätte es ein Link ins MSDN wohl auch getan. Du bist ja schon so schlimm wie DeCodeGuru ...

Horschdware · Verfasst: Do 29.01.04 19:11

Das seltsame an der Sache ist ja folgendes:

In 90% aller Fälle funktionierts. Aber bei manchen Verzeichnissen weigert der sich halt vehement. Und noch seltsamer: die Verzeichnisse die nicht wollen wechseln. D.h. heute geht mal Verzeichnis X nicht zum Umbenennen, morgen Verzeichnis Y. Ich hab schon gedacht, dass evtl extern auf den Ordner zugegriffen wird. Ist aber nicht der Fall.

_________________
Delphi: XE - OS: Windows 7 Professional x64

Sven · Beiträge: 314 D6 Ent, K3 Pro (patched)

Nur ein Verdacht: Könnte es sein das Verzeichnisse mit Zahlen wie pg3 probleme bereiten?

_________________
MDK 9.1, Kernel 2.4.21, KDE 3.1 Kylix 3 Pro (patched), nutze aber auch Windows

Horschdware · Verfasst: Fr 30.01.04 23:51

nein.
wenn das verzeichnis statt gp3 mal gp2 heisst funzt es auch.

_________________
Delphi: XE - OS: Windows 7 Professional x64

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme