Files Au3 - AutoIt File Manager

[WildByDesign]

I just wanted to give a quick update. I have some great news. I've been experimenting with the SHDoDragDrop function along with some fantastic drag and drop code from @MattyD and it has been quite successful.

• There is no need for a separate process for file management since it all runs in a thread within Explorer
• Explorer handles all of the I/O and takes the resource usage away from our process
• We get a beautiful built-in drag image with built-in tooltip about where the drag is hovering over
• Explorer already has logic for whether to Move, Copy, etc.
• Explorer provides the dialogs for whether to Skip, overwrite, etc.

Therefore we get the best performance and proper OS dialogs using proper OS functions

I was intending to do all of that the hard way. But that could potentially cause problems if our own logic is not quite perfect.

So why do any of that if we don't have to?

What is working so far?

• Drag and drop from TreeView to external program (eg. File Explorer)
• Drag and drop from ListView to external program (eg. File Explorer)
• Proper drag image is working for both of the above

What is not working yet? (this is where I am stuck at the moment)

• Drag and drop within Files Au3 (eg. ListView to TreeView) - DONE
• Drag and drop from an external program (eg. File Explorer) to Files Au3 - DONE
• Dragging multiple files from ListView - DONE
  • Requires IDataObject interface (DROPFILES, FORMATETC, STGMEDIUM structures)

In order to get the proper OS drag and drop (plus drag images) working in Files Au3, I need to figure out how to use the RegisterDragDrop function to register the main window and likely the TreeView and ListView windows as valid drop targets. This is different from the typical WS_EX_ACCEPTFILES, WM_DROPFILES and GUI_DROPACCEPTED that we are used to.

In order to get drag images working over (and within) Files Au3, we need to create an IDropTargetHelper interface and I have no idea how to do that part yet.

Once those are implemented, it will be quite easy. But I am stuck there since I don't understand those very well.

If anyone wants to help in those areas, I can create a branch in the Files Au3 repo specifically for these changes. Please let me know.

These are all almost complete now.

Edited January 31 by WildByDesign

[WildByDesign]

On 1/29/2026 at 8:30 AM, WildByDesign said:

• There is no need for a separate process for file management since it all runs in a thread within Explorer
• Explorer handles all of the I/O and takes the resource usage away from our process

So I was wrong about this. Explorer does handle all of the logic which is great, but our GUI will still take a hit from the progress dialog. The OperationStatusWindow window class runs within our process.

This might be fine when moving/copying small files here and there. But for larger things it could tie up the GUI and we would just wait for the progress to be complete. I may go ahead and continue with this for now and we can look into the separate process after.

In the long run, we should run this in a separate process. I know how to do most of that. But I am still not great when it comes to IPC.

Our GUI process would need to send a data object (from the IDataObject interface) that we already have along with the variable string for destination. I have done minimal IPC stuff but never involved sending a data object.

[Kanashius]

19 minutes ago, WildByDesign said:

Our GUI process would need to send a data object (from the IDataObject interface) that we already have along with the variable string for destination. I have done minimal IPC stuff but never involved sending a data object.

It depends on the object, if that is even possible. If it is just a "handle"/"pointer" for something run in a system process, then you could possibly copy that object and transfer it.
If it is an object that is "running in the AutoIt process" and not just a handle to a "system resource", then that would be difficult. It could not be simply transferred to another process.

 

You inspired me (again) to write an IPC-UDF. I've put an alpha version on github (https://github.com/kanashius/AutoIt-IPC) and gave you access, maybe you would like to have a look at it. Theoretically it is working, but I still have some bugs (one is currently an application freeze, where I do not know the source), so be careful with the GUI-Example

If I fixed those issues, I will make it public with v1

[WildByDesign]

27 minutes ago, Kanashius said:

It depends on the object, if that is even possible. If it is just a "handle"/"pointer" for something run in a system process, then you could possibly copy that object and transfer it.
If it is an object that is "running in the AutoIt process" and not just a handle to a "system resource", then that would be difficult. It could not be simply transferred to another process.

I believe that it is a pointer and handled by the Shell. But I don't for certain whether it is an object run in a system process or if it is just contained in the AutoIt process. The fact that it gets passed back and forth makes me think it would be more likely system.

@MattyD Would you please be able to confirm for us whether the $pDataObj from the IDataObject interface is managed in a system process or if it only resides in the AutoIt process?

 

27 minutes ago, Kanashius said:

You inspired me (again) to write an IPC-UDF. I've put an alpha version on github (https://github.com/kanashius/AutoIt-IPC) and gave you access, maybe you would like to have a look at it. Theoretically it is working, but I still have some bugs (one is currently an application freeze, where I do not know the source), so be careful with the GUI-Example

If I fixed those issues, I will make it public with v1

The awesome thing about inspiration is that it goes around. "What goes around, comes around." It was your work that inspired my ideas and creativity. And then my ideas and creativity seems to inspire you again in return. That is truly incredible.

And by the way, anytime you release something new it's like Christmas came early (again and again).  So I am excited to dig into your new IPC UDF.

[SOLVE-SMART]

40 minutes ago, Kanashius said:

I've put an alpha version on github (https://github.com/kanashius/AutoIt-IPC) and gave you access, maybe you would like to have a look at it.

Hi @Kanashius, could you invite me too, to the repository? I want to have a look 😁 .
There exists quite a lot ICP UDFs/approaches already, but I am always interested in reviewing code and understanding thoughts how things can be done 🤝 .

Best regards and thanks
Sven

[WildByDesign]

58 minutes ago, Kanashius said:

If I fixed those issues, I will make it public with v1

I have had a quick look over the code. This is seriously impressive. If you can narrow down those initial bugs, this could be of significant benefit for any AutoIt users needing a modern IPC. As always, your code and commenting is exceptional.

By the way, it is missing ToString.au3 as one of the includes.

EDIT: Found it. For anyone needing it, here is @Kanashius' ToString UDF.

Edited February 5 by WildByDesign

[WildByDesign]

@Kanashius I have an important question regarding copying/moving files and how I should handle that properly with your TreeListExplorer UDF.

My own thoughts for a while now was that anytime files are copied/moved, I would simply call your __TreeListExplorer_Reload() function to refresh the TreeView and ListView in a way that would properly update the data contained by your UDF and also update the views. This would be the easiest way to do it also which is nice.

The other option would be adding/removing files/directories individually with their respective _GUICtrlListView_* and _GUICtrlTreeView_* functions. This would certainly add some more complexity but also might conflict with the records held by your UDF.

From my initial testing, __TreeListExplorer_Reload() seems to do the job perfectly.

What is your opinion on this?

[Kanashius]

3 hours ago, WildByDesign said:

By the way, it is missing ToString.au3 as one of the includes.

Yes, it is not ready yet, and I am using that UDF for debugging. It is really useful to get a quick look at a datastructure like maps/dllstructs/arrays/... in the console.
Its currently not even used in the Code, just temporarily, when I encounter an issue. You can remove it without issues, if you like.
That's why its not public yet
I already made some larger changes and will probably push that later.

3 hours ago, WildByDesign said:

The other option would be adding/removing files/directories individually with their respective _GUICtrlListView_* and _GUICtrlTreeView_* functions. This would certainly add some more complexity but also might conflict with the records held by your UDF.

From my initial testing, __TreeListExplorer_Reload() seems to do the job perfectly.

Whatever you prefer. The TreeListExplorer UDF does not hold the tree/list/combo items anywhere additionally, so if you change the tree/list/combo control, it would not create any problems. You can even use the internal "__TreeListExplorer__FileGetIconIndex($hView, $sPath)", if you like, just make sure to call it with the correct control handle (not a control id,...) and the absolute path and make sure the control is added to the TLE system before calling the method. There are no parameter checks for internal methods, so it may crash if you do it wrong

Otherwise, if the performance is good enough for you, you can also call __TreeListExplorer_Reload.
If you only need to update one specific control, you can also call __TreeListExplorer_ReloadView($hView).

Edited February 5 by Kanashius

[MattyD]

23 hours ago, WildByDesign said:

@MattyD Would you please be able to confirm for us whether the $pDataObj from the IDataObject interface is managed in a system process or if it only resides in the AutoIt process?

My understanding is that the data object would normally be created in the same apartment as the drop source.  Lets say we drag in a file from explorer to our program... in this case our drop target will actually be interacting with a dataobject proxy. This looks and acts like the real deal - but we're really just forwarding information back home to the original object.  That's essentially what marshaling is.

I wouldn't get too bogged down it.  On the receiving side, if you create a reference to the DataObject then release it again. As long as there's an equilibrium you'll be OK.  If you're on the source side you'll need to create the thing, but again - just release() after DoDragDrop and let the garbage collector gobble the object up! 

[SOLVE-SMART]

 

On 2/5/2026 at 2:25 PM, SOLVE-SMART said:

Hi @Kanashius, could you invite me too, to the repository? I want to have a look 😁 .

Thanks for the collaboration invitation. I created a pull requests with few things to be discussed.

Best regards
Sven

FYI: @Kanashius

Edited February 6 by SOLVE-SMART

[WildByDesign]

On 2/5/2026 at 7:41 AM, Kanashius said:

If I fixed those issues, I will make it public with v1

I have spent some time testing your examples with your latest changes in v1.0.0 and everything is working great from my testing. In my opinion, it is ready for you to share so that you can get more people here testing it.

Will the IPC work across different integrity levels? (eg. one process running Medium, another running elevated at High)

I should probably look into implementing it soon before I get too deep into the IFileOperation stuff. As long as we can send that data object then it shouldn't be too difficult.

EDIT: Or if we can't send the data object, we could possibly send an array of file names and recreate the data object on the other side.

Edited February 8 by WildByDesign

[Kanashius]

On 2/8/2026 at 12:19 PM, WildByDesign said:

Will the IPC work across different integrity levels? (eg. one process running Medium, another running elevated at High)

Yes, it used TCP => network protocols. So the processes can be completly independent of each other.

 

On 2/8/2026 at 12:19 PM, WildByDesign said:

we could possibly send an array of file names

Yes, that is possible.

[WildByDesign]

Files Au3 has just transformed from being a simple file viewer to being a powerful file management program. All of the recent file management code is in the shell-dodragdrop branch while a pull request has been submitted and is pending review before it comes over to the main branch.

If you want to test that new code out, simply go to that branch and download the whole branch as a Zip archive. Click on the green "<> Code" within the branch and choose Download ZIP from the menu.

Recent developments:

• Drag and drop code (with beautiful drag images) has been added with the help of @MattyD and @jugador
  • Drag and drop from/to TreeView/ListView or from/to external programs (eg. File Explorer) is all possible
• IFileOperation code was shared by @Danyfirex that has allowed the implementation of:
  • Delete, Rename, Copy, Paste, Undo, etc.
  • Related menu entries have been added for those functions
  • Related hotkeys (eg. Ctrl+C, etc) have been added as well
  • TODO: I still need to add related TreeView/ListView context menu entries for these
• File/folder Properties can be viewed as well (single or multiple selection)
  • Shift+P hotkey has been added to view Properties (although that hotkey may change)
• Likely much more improvements have been made than I can remember right now

I have also updated the first post of this thread to strikeout items from the original TO DO list and have started a new Current TO DO List so that if anyone wants to help, it gives some ideas of goals and things that need to be done.

Thank you to EVERYONE, by the way. Without the help of this community, Files Au3 would be nothing. It belongs to all of us. And I am truly shocked and surprised at how far Files Au3 has come. Some things that I thought were impossible or would never happen, are now possible and already implemented. Thanks to all of you.

By the way, I am still curious about changing the name of Files Au3. It doesn't roll off the tongue very smoothly. So if anyone has any name ideas, please feel free to share.

Edited February 12 by WildByDesign

[pixelsearch]

14 minutes ago, WildByDesign said:

By the way, I am still curious about changing the name of Files Au3.

WildExplorer

[WildByDesign]

@Kanashius I was looking into some of performance related details recently. I have an idea but I likely need your help for conversion.

In the Callback_ListViewItemCreated function, that is where we convert the Size from bytes to the more readable format with MB, GB, etc. However, I noticed that it adds approx. 2-3x load time. Particularly noticeable on larger folders such as System32.

What if we did a custom sort instead (likely in Callback_ListViewPaths )?

For example, a custom sort that can take into account the MB, GB, etc. and work with that. I understand that the sort might be slightly less accurate since we had already done some minor rounding initially, assuming we do the fancier size conversion from the start. I feel like this might be a faster sort instead of relying on the *ItemCreated callback to modify the array and all.

What do you think about that?

Similar to the Filter Callback for showing/hiding System and/or Hidden files and folders. It seems like from a performance perspective that it would be more efficient to have some of this stuff in the original array.

[Kanashius]

I tried it out and I am not sure it makes that much of a difference. It just takes its time to go through so many files, get their size,...

With the IPC we are using, you could think about moving the loading/filling to a different process 🤔

You create the listview in the main process, send the gui handle and control handle to the sub process and the sub process registers the listview for the TLE UDF.
Then you would just have to replace all calls to udf functions with __IPC_MainSendCmd and a fitting command (+parameters) and call those in the sub process instead. Everything will be done in a different process, not blocking the original process

I think that should work, but would also be a larger undertaking^^
I'm just not completely sure, the sub process can register for a gui from a different proces with _WinAPI_SetWindowLong

main.au3

[WildByDesign]

7 hours ago, Kanashius said:

I tried it out and I am not sure it makes that much of a difference. It just takes its time to go through so many files, get their size,...

That is a great point. The more columns that we add and the more details we request, that can certainly add up especially with many files.

You are right, it doesn't seem to be much of a difference for performance. However, the changes that you made look very nice and efficient. It looks like you got rid of Callback_ListViewItemCreated and combined that functionality directly in the function for Callback_ListViewPaths. The sorting works great. I really like the changes that you've made.

Would you recommend that I use your updated _handleListViewData function and related changes?

7 hours ago, Kanashius said:

With the IPC we are using, you could think about moving the loading/filling to a different process 🤔

I have actually been thinking about this recently. It could be quite amazing.

7 hours ago, Kanashius said:

I think that should work, but would also be a larger undertaking^^

But yes, this exactly. It would be worth it, but it would be a lot of work. We can think of it as more of a long term goal. It depends if Files Au3 can become good enough to be worthy of putting in that much extra time for the performance stuff.

[Kanashius]

53 minutes ago, WildByDesign said:

Would you recommend that I use your updated _handleListViewData function and related changes?

Thats up to you

[WildByDesign]

9 hours ago, Kanashius said:

Thats up to you

It's too good to let that code go.

I'm trying to some more efficiency work on the loading of the ListView data and wondering if you can share your opinion.

Func _handleListViewData($hSystem, $hView, $sPath, ByRef $arPaths)
    ConsoleWrite("_handleListViewData called" & @CRLF)
    ReDim $arPaths[UBound($arPaths)][_GUICtrlListView_GetColumnCount($idListview)] ; resize the array (and return it at the end)
    Local $iFolderCount = 0
    For $i = 0 To UBound($arPaths) - 1
        Local $sFilePath = $sPath & $arPaths[$i][0]
        If __TreeListExplorer__PathIsFolder($sFilePath) Then
            $arPaths[$i][2] = __TreeListExplorer__GetTimeString(FileGetTime($sFilePath, 0))             ; add time modified
            $arPaths[$i][3] = "File folder"
            $iFolderCount += 1
        Else
            $arPaths[$i][1] = FileGetSize($sFilePath)             ; Put size as integer numbers here to enable the default sorting
            $arPaths[$i][2] = __TreeListExplorer__GetTimeString(FileGetTime($sFilePath, 0))             ; add time modified
            $arPaths[$i][3] = _getFileType($sFilePath)
        EndIf
    Next
    _ArraySort($arPaths, $__TreeListExplorer__Data["mViews"][$hView].mSorting.iDir, $iFolderCount, 0, $__TreeListExplorer__Data["mViews"][$hView].mSorting.iCol)
    For $i = $iFolderCount To UBound($arPaths) - 1
        $arPaths[$i][1] = __TreeListExplorer__GetSizeString($arPaths[$i][1])
    Next

    Return $arPaths
EndFunc   ;==>_handleListViewData

Func _getFileType($sPath)
    Switch StringRight($sPath, 4)
        Case ".exe"
            Return "Application"
        Case ".dll"
            Return "Application extension"
    EndSwitch
    Local $tSHFILEINFO = DllStructCreate($tagSHFILEINFO)
    _WinAPI_ShellGetFileInfo_mod($sPath, BitOR($SHGFI_TYPENAME, $SHGFI_USEFILEATTRIBUTES), $FILE_ATTRIBUTE_NORMAL, $tSHFILEINFO)
    Return DllStructGetData($tSHFILEINFO, 5)
EndFunc   ;==>_getFileType

So you'll notice in the code above, if the path is a folder I just state the obvious with $arPaths[$i][3] = "File folder". I figured that there is not point in hitting up the _getFileType over and over for folders. Especially for directories such as System32 and WinSxS.

Then in _getFileType, I have a quick switch with early returns for .exe and .dll for similar reasons. System32 has over 3,000 DLLs. Anything that is not .dll or .exe can go on to get checked with _WinAPI_ShellGetFileInfo. Now obviously, we can add every single extension to the Switch. Especially because many extensions will show a different file type depending on what program a user has associated with the file type so it could differ.

Anyway, does this seem reasonable enough? Or should I make some changes?

[WildByDesign]

@Kanashius If you have some spare time, could you please try to see how to implement your IPC UDF for some parts of Files Au3?

This is really only for messing around and seeing if it can be implemented, how and where it should be implemented.

I created the ipc-testing for this purpose of messing around and see what is possible.

Particularly, the DropTargetObject.au3 contains most of the IFileOperation stuff for MoveItems and CopyItems. If this is successful, it will be easy to do the same for Copy/Paste and other things. I did my best to comment in detail what needs to be done in that file. All of those related comments start with TODO: IPC:.

Since we cannot send data objects with the IPC at the moment, we would have to take the files names from the data object ($pDataObject) and create an array which can be sent through your IPC. In the sub process, we can then recreate the data object.

The following will create the array that we need to send through your IPC to the sub process:

Local $tFormatEtc = DllStructCreate($tagFORMATETC)
$tFormatEtc.cfFormat = $CF_HDROP
$tFormatEtc.iIndex = -1
$tFormatEtc.tymed = $TYMED_HGLOBAL

Local $oDataObject = ObjCreateInterface($pDataObject, $sIID_IDataObject, $tagIDataObject)
Local $tStgMedium = DllStructCreate($tagSTGMEDIUM)
$oDataObject.AddRef()
$oDataObject.GetData($tFormatEtc, $tStgMedium)

Local $asFilenames = _WinAPI_DragQueryFileEx($tStgMedium.handle)