AutoHotkey Community

[Rapte_Of_Suzaku]

Provides access to Windows' built-in file operation system (move / copy / rename / delete files or folders with the standard Windows dialog and error UI). Based on SKAN's ShellFileOperation.

Important differences:

• works with any build
  
• flags and such can be passed as strings. "FOF_SILENT|FOF_ALLOWUNDO" easier to understand/use than 0x44
  
• for users with objects (AutoHotkey_L and related), you get a more detailed return object containing rename mappings if requested
  

Requirements:

• Regular AHK users (without object support) will need Lexikos' StrGet Function

Content

ShellFileOperation.ahk (release #3)
Online Documentation and Examples (2010-09-29, 16:51)

[Lexikos]

It has one error: the loops replace bytes rather than characters. As you may know, each Unicode character is typically two bytes. It works okay when the string contains only ASCII characters (i.e. because the upper byte is always 0, not 124), but some Unicode characters might cause problems.

*(Unary deref) can only retrieve one byte at a time. Since that script was written, NumGet was introduced - it is more flexible, usually easier to understand, and (iirc) actually faster. Likewise for RtlFillMemory vs NumPut. The following should work in place of the current loops (untested):

[Rapte_Of_Suzaku]

I knew it was looping through bytes, but neglected to consider the possibility of catching a Unicode character by mistake...

Thank you for the reminder and then catching the DllCall inflexibility!!

Updated version:

[Rapte_Of_Suzaku]

I recently updated this function again. The new features this time are the ability to pass strings rather than numbers (pass "FO_MOVE" rather than 0x1) and a return code interpreter function.

example:

[Rapte_Of_Suzaku]

Just updated the function again, latest version is now in the first post.

Oh, and I've finally discovered a solid way to track file operations by tricking ShFileOperation into putting all the results into its returned mappings! Here's the story/explanation, if anyone is interested:

While working on my FileContainer Library, I've been trying to find a way to track file operations through ShFileOperation. By using the FOF_WANTMAPPINGHANDLE flag, it is possible to get a list of any renames that occur. And you can sorta check for completed move/delete operations by checking if those files still exist. But what happens if the user cancels a file copy in the middle due to a conflicting destination file? ShFileOperation doesn't provide that information naturally. I tried using WatchDirectory() by HotKeyIt, but ReadDirectoryChangesW is susceptible to overflow and takes way too many resources to reliably cover all areas of any given operation. I thought about giving up on ShFileOperation and rolling my own file moving program... but that didn't seem like fun to me! I even tried using the USN journal, but that won't work in all situations.

But recently, I discovered a way to trick ShFileOperation into telling me everything I need to know. I found that if you give it folder names that end in a slash, it feels compelled to rename them for you. And so those folders will end up in the returned mappings! For files, you can achieve the same thing by adding a trailing space to the path. The only problem is that any actual renames (due to conflicts) will get butchered. The ShFileOperation UI will offer to rename the file to, say "file (2).txt", but will actually end up renaming it to "file.txt (2)". However, this is a very easy problem to fix. In my FileContainer library, I now have a postprocessing routine that picks out the butchered renames and manually fixes them (will be posting the new version today or tomorrow). And then finally, you'll have a list of exactly what files/folders resulted from the requested ShFileOperation.