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 Thursday at 01:40 PM 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 Thursday at 05:13 PM 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 Friday at 04:10 PM 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 yesterday at 11:21 AM 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.