Files Au3 - AutoIt File Manager

[WildByDesign]

FilesAu3-2025-12-29:

I added Mica to the GUI in dark mode for Windows 11 build 22621 and higher. Mica is quite tame and decent. Now that the framework is in place, it will be very easy for me to add the ability to switch between Mica, Acrylic, Tabbed, etc. from a submenu or something.

The switch between dark mode and light mode clears the Mica material and all is well.

I also fixed the tooltips in light mode because the tooltip colors were not switching initially when switching between light/dark.

At some point, I should add the ability to detect when the Windows theme changes outside of the app and change accordingly.

Now that I am quite happy with the overall GUI functionality, I think that I am going to move on to some ListView features. Such as adding the ability to hover over a directory/file and show some details in a tooltip. There's a lot of fun ListView stuff that I want to explore.

EDIT: As always, the updated source archive is in the first post.

EDIT2: I forgot to mention that I implemented the OWNERDRAW statusbar in this release.

I believe that the majority of the code for the OWNERDRAW statusbar came from @pixelsearch from this post in the Resizable status bar without SBARS_SIZEGRIP thread.

However, I had to make some changes to it. There was a conflict between the ScrollbarProc drawing (for the gripper dots, etc.) and the non-client area painting over the white line below the menubar in dark mode. This conflict was unavoidable and would cause the entire GUI to lose entire theming go back to Windows Classic type of theming.

The only workaround was to remove $WS_SIZEBOX from the GUI. That meant that we could only resize the GUI from the gripper in the bottom right corner and we could not resize the GUI using any of the sides. This was just not the way to go, unfortunately. 

Also, I noticed that Notepad++ did their dark mode theming on the modern theme statusbar without removing the theme (eg. _WinAPI_SetWindowTheme($g_hStatus, "", "")), so I thought, why not try...

So I kept the modern theming of the statusbar and everything still worked well. The OWNERDRAW painting and everything worked as expected. The one and only negative was that the gripper area does not show the actual gripper (dark mode only). That is just a limitation in Windows dark mode theming at the moment and not a showstopper. The gripper area still functions to resize and so does the sides of the GUI.

Explorer++ dark mode also shows the same thing with the missing gripper. No big deal. But yet somehow Notepad++ keeps the modern statusbar theming and still has the gripper showing beautifully. Notepad++ is a great example for all dark mode related things. If anyone is curious (and knows c++), here is the statusbar related code that Notepad++ uses: https://github.com/notepad-plus-plus/notepad-plus-plus/blob/18811c6f0605ec2166e57d4a9a4ca53db90bd29f/PowerEditor/src/WinControls/StatusBar/StatusBar.cpp#L139

Edited December 29, 2025 by WildByDesign

[WildByDesign]

FilesAu3-2026-01-01:

I added some beautiful (dark mode / light mode) tracking tooltips for the ListView items. It ended up being way more work than I had expected but absolutely worth it.

Hovering over files gives some file information. Hovering over folders gives the total size of the folder contents. Hovering over drives in This PC gives a bit of drive information.

The structure is in place now and working well. I would like to add more information to each of those tooltips at some point. For example, dimensions for image files.

[WildByDesign]

FilesAu3-2026-01-06:

• Updated DPI functionality (removed _WinAPI_DPI.au3 UDF)
• Updated CreateDots function with full DPI support
  • Dot size, spacing and alignment are identical to gripper dots from light mode Explorer theme
  • Gripper dots tested up to 400% DPI scaling

Not a lot of changes. However, those DPI changes particularly with the gripper dots made a beautiful difference. The gripper dots are sharp now on all DPI factors and they match the gripper dots from the aero.msstyles resource files.

[WildByDesign]

FilesAu3-2026-01-11:

• Updated TreeListExplorer UDF to version 2.12
• Significantly improved column sorting (thanks to @Kanashius)
  • Sorting now persists when you change directories
• Added new column for Type (again, thanks to @Kanashius)
• Lots of important tooltip fixes
  • Tooltips now only show when hovering over column 0 (Name column)
  • Tooltips will no longer show while vertically scrolling in the ListView

This turned out to be a really nice release.

[WildByDesign]

FilesAu3-2026-01-12:

• Updated callbacks to the newer Callback_ListViewPaths and Callback_ListViewItemCreated method
• Statusbar improvements
  • ListView selections (including during marquee selections) update statusbar calculations in real-time now
• ListView tooltips improvements
  • Tooltips are cleared now when hovering from one item to the next

I think the tooltip functionality is complete now. The tooltips can use more information, for sure. That can easily be added. But as far as how/when the tooltips activate and how/when the tooltips are cleared behaves beautifully now.

Changing selections in the ListView seems to cause some flicker on the TreeView which is interesting. I haven't tried to fix that yet but I'll figure out a solution (hopefully) soon.

EDIT: I was able to fix the flicker on the TreeView successfully by making the TreeView composited. No flicker anymore. I will add that in the next release.

Edited January 12 by WildByDesign

[WildByDesign]

On 12/8/2025 at 7:32 PM, WildByDesign said:

to get around the AutoIt bug #1492 which causes problems between WS_EX_COMPOSITED and ListView headers due to AutoIt using CS_OWNDC for GUI's despite Microsoft's guidance against using CS_OWNDC.

Slightly off-topic:

It looks like AutoHotKey copied AutoIt with regard to how their interpreter initiates GUI creation using CS_OWNDC.

Curiosity got the better of me (as it always does). So I was curious to see how AutoHotKey would handle a simple GUI with a simple ListView. All good, as expected. I then added the WS_EX_COMPOSITED extended style to the GUI and sure enough the ListView in AutoHotKey flickers just the same. I don't know much at all about the history between AutoIt and AutoHotKey other then a few things that I've read on Wikipedia.

[Jos]

17 minutes ago, WildByDesign said:

I don't know much at all about the history between AutoIt and AutoHotKey other then a few things that I've read on Wikipedia.

Just keep it like that and you'll be fine. 😉

[WildByDesign]

Far beyond the abilities of my own skill set, I have miraculously achieved the drag and drop between TreeView/ListView (and vice versa), TreeView/TreeView and ListView/ListView. And somehow it is done in a way that is beautiful looking.

So I just wanted to give a heads up that that is what I am currently working on. I never expected to be able to do that part myself.

There are quite a lot of intricacies that still need to be done. But I’m hoping to share it soon.

[SOLVE-SMART]

Very briefly, because I'm in hurry:  the README of the repository does contain a Acknowledgements (Credits) section now, to appreciate peoples supported work here or on GitHub.

Best regards
Sven

[WildByDesign]

@Kanashius If you have a moment, could you please help me with something?

I have added an initial drag and drop structure to Files Au3 that allows drag and drop between TreeView/ListView, ListView/ListView and TreeView/TreeView in the initial-drag-drop branch. You can test it without any worry because there is no file copying/moving at all yet. You can drag/drops and it will simply do ConsoleWrites of what would be copied and to where.

It will obviously needs a lot more, such as checking whether it's a directory or not. Many things. But that is not a concern right now.

If you have a look at:

Case $g_hTreeView
            Switch $iCode
                Case $TVN_BEGINDRAGA, $TVN_BEGINDRAGW
                    Local $tTree = DllStructCreate($tagNMTREEVIEW, $lParam)
                    Local $hDragItem = DllStructGetData($tTree, "NewhItem")
                    $sTreeDragItem = _GUICtrlTreeView_GetText($g_hTreeView, $hDragItem)
                    $bDragTreeList = True
                    $sDragSrc = "Tree"
                    ; TO DO: need to get full path of treeview drag item $sTreeDragItem

How can I get the full path of one of the treeview items that is being dragged?

I have tried some things similar to the following:

Local $iX =_WinAPI_GetMousePosX(True, $hView)
Local $iY =_WinAPI_GetMousePosY(True, $hView)
Local $hItem =_GUICtrlTreeView_HitTestItem($g_hTreeView, $iX, $iY)
Local $sPath = __TreeListExplorer__TreeViewGetRelPath($hTLESystem, $g_hTreeView, $hItem)

But all of my attempts (within Case $TVN_BEGINDRAGA, $TVN_BEGINDRAGW) fail and cause the script to crash.

EDIT: To be specific, it is __TreeListExplorer__TreeViewGetRelPath that causes the script crash. My method in that GitHub tree works but only gives me the item name and not full path.

Edited Monday at 03:42 AM by WildByDesign

[pixelsearch]

3 hours ago, WildByDesign said:

How can I get the full path of one of the treeview items that is being dragged?

Tested on your script, it seems to be a good start :

; $sTreeDragItem = _GUICtrlTreeView_GetText($g_hTreeView, $hDragItem)

$sTreeDragItem = _GUICtrlTreeView_GetTree($g_hTreeView, $hDragItem)
ConsoleWrite($sTreeDragItem & @crlf)

Edit: also, according to the help file (topic GUICtrlTreeView_GetTree) :

If $hItem is 0 then an attempt to use current selected is used.

So this seems to work too (tested) :

$sTreeDragItem = _GUICtrlTreeView_GetTree($g_hTreeView)

 

Edited Monday at 07:35 AM by pixelsearch

[WildByDesign]

4 hours ago, pixelsearch said:

Tested on your script, it seems to be a good start :

; $sTreeDragItem = _GUICtrlTreeView_GetText($g_hTreeView, $hDragItem)

$sTreeDragItem = _GUICtrlTreeView_GetTree($g_hTreeView, $hDragItem)
ConsoleWrite($sTreeDragItem & @crlf)

This is perfect! Thank you.

I added on a little StringReplace to clean the final string:

$sTreeDragItem = _GUICtrlTreeView_GetTree($g_hTreeView, $hDragItem)
$sTreeDragItem = StringReplace(StringReplace($sTreeDragItem, "This PC|", ""), "|", "\")

I wasn't able to use Opt("GUIDataSeparatorChar", "\") as suggested in the help file because it conflicted with the TreeListview UDF, but that is not a problem.

[Kanashius]

Hi,

I agree with @pixelsearch. 
I wrote this function to get the TreePath (which would also work for other languages ("This PC"), if that gets ever implemented, e.g. it is called "Dieser PC" in German )

Func TreeItemToPath($hTree, $hItem)
    Local $sPath = StringReplace(_GUICtrlTreeView_GetTree($hTree, $hItem), "|", "\")
    $sPath = StringTrimLeft($sPath, StringInStr($sPath, "\")) ; remove this pc at the beginning
    If StringInStr(FileGetAttrib($sPath), "D") Then $sPath&="\" ; let folders end with \
    Return $sPath
EndFunc

Additionally, I would add, that you may want to change the _ListGetSelections function. (Or anywhere else you do this in your script):
You read the InputCtrl to get the path, but this may be changed by the user => may not be the current path.
Use __TreeListExplorer_GetPath($hTLESystem) instead. This may also be combined with __TreeListExplorer_GetRoot($hTLESystem), but root is probably always "" for your application.

Func _ListGetSelections()
    $sListDragItems = ""
    $aListDragItems = _GUICtrlListView_GetSelectedIndices($g_hListView, True)
    For $i = 1 To $aListDragItems[0]
        $aListDragItems[$i] = __TreeListExplorer_GetPath($hTLESystem) & _GUICtrlListView_GetItemText($idListview, $aListDragItems[$i], 0)
        $sListDragItems &= $aListDragItems[$i] & " + "
    Next
    $sListDragItems = StringTrimRight($sListDragItems, 3)
    AdlibUnRegister("_ListGetSelections")
EndFunc

It is also not really visible to the user, that a drag is happening. So maybe consider changing the cursor.
I looked into that (but ran out of time), but this may help:
 

Global $g_hCursorDrag = _WinAPI_LoadCursorFromFile("../assets/ArrowDrag.cur"), $g_hCursorBefore = Null

$g_hCursorBefore = _WinAPI_SetCursor($g_hCursorDrag) ; set drag cursor

_WinAPI_SetCursor($g_hCursorBefore) ; reset cursor
$g_hCursorBefore = Null

It did not work this way and I only found _WinAPI_SetSystemCursor solutions with mouse movement detection (if it is over the window), which I did not really like. Maybe you find a better solution

I added the cursor I created for that (which is similar to the one firefox shows on drag).

ArrowDrag.cur

[WildByDesign]

1 hour ago, Kanashius said:

I wrote this function to get the TreePath (which would also work for other languages ("This PC"), if that gets ever implemented, e.g. it is called "Dieser PC" in German )

This is fantastic. I had completely overlooked the fact that there could (at least at some point) be different languages used for that. Especially considering the diversity of languages of the many users' of this forum. I will update the function.

By the way, I used to work on a German project years ago. It was a kernel-mode driver security project for application allowlisting to control which binaries can execute and which binaries would be blocked from running. Although the only German that I came out of that project with was "HARIBO". 🤣

Joking, of course. That is a brand name that, if I recall correctly, had to do with the people's names (initials or first letters or something) who created the company.

1 hour ago, Kanashius said:

Additionally, I would add, that you may want to change the _ListGetSelections function. (Or anywhere else you do this in your script):
You read the InputCtrl to get the path, but this may be changed by the user => may not be the current path.
Use __TreeListExplorer_GetPath($hTLESystem) instead. This may also be combined with __TreeListExplorer_GetRoot($hTLESystem), but root is probably always "" for your application.

Great suggestion, thank you. I always try to use the functions from your UDF whenever possible for accuracy. This is one where I definitely should have used your UDF function but I am not familiar with all of them. I'm going to read through your UDF again and read the various functions because you have lots of incredible functions in there that are beneficial for lots of scenarios. I will update this function as well based on your suggestion.

1 hour ago, Kanashius said:

It did not work this way and I only found _WinAPI_SetSystemCursor solutions with mouse movement detection (if it is over the window), which I did not really like. Maybe you find a better solution

I added the cursor I created for that (which is similar to the one firefox shows on drag).

This is awesome. I wasn't sure yet how I was going to handle the drag image, whether I was going to create a little GUI during move or whatever. I didn't think that far ahead. But I really like this cursor and the simplicity of changing the cursor during the drag. I have some ideas for this. I'll see what I can come up with.

Genius stuff as always. Thank you @Kanashius and @pixelsearch for your help.

[WildByDesign]

I’m looking into _GUICtrlTreeView_CreateDragImage to see about adding the cursor as a part of the drag image. Also, similar function for the ListView drag image as well.

[pixelsearch]

5 hours ago, WildByDesign said:

I wasn't able to use Opt("GUIDataSeparatorChar", "\") as suggested in the help file because it conflicted with the TreeListview UDF, but that is not a problem.

OK, but you have to know why it didn't work by your side, maybe because the example in the help file didn't reset the previous separator (as it's a short self-contained script). Here is the correct way, 1st with ConsoleWrite's then without them.

ConsoleWrite("1  " & Opt("GUIDataSeparatorChar") & @crlf) ; |
Local $sSeparator = Opt("GUIDataSeparatorChar", "\") ; $sSeparator = value of the previous setting
ConsoleWrite("2  " & Opt("GUIDataSeparatorChar") & @crlf) ; \

$sTreeDragItem = _GUICtrlTreeView_GetTree($g_hTreeView, $hDragItem)

ConsoleWrite("3  " & Opt("GUIDataSeparatorChar") & @crlf) ; \
Opt("GUIDataSeparatorChar", $sSeparator) ; reset to previous setting
ConsoleWrite("4  " & Opt("GUIDataSeparatorChar") & @crlf) ; |

ConsoleWrite($sTreeDragItem & @crlf) ; ...\...\...\...

 

1  |
2  \
3  \
4  |
This PC\F:\Temp
Copying This PC\F:\Temp to G:

It should be clearer without ConsoleWrite's :

Local $sSeparator = Opt("GUIDataSeparatorChar", "\") ; $sSeparator = value of the previous setting

$sTreeDragItem = _GUICtrlTreeView_GetTree($g_hTreeView, $hDragItem)

Opt("GUIDataSeparatorChar", $sSeparator) ; reset to previous setting

 

[WildByDesign]

2 hours ago, pixelsearch said:

OK, but you have to know why it didn't work by your side, maybe because the example in the help file didn't reset the previous separator (as it's a short self-contained script). Here is the correct way, 1st with ConsoleWrite's then without them.

This is really helpful and seems like something that I should have known. Although I haven’t experimented much with Opt() options. I have always had the (wrong) assumption that Opt() always had to be at the top of a script and could not be changed. That was my own foolishness. Knowing now that I can change/reset these options is very helpful. Thank you.

[Kanashius]

This looks like something, that should be done in my UDF, not by every user, so I changed that (new TreeListExplorer UDF version v2.12.2).

Should be possible for you to change the seperator with that version 

[WildByDesign]

I never expected that I would be able to fix the weirdness that occurs from the GUIFrame UDF when it comes to resizing the GUI with the bug that causes the child frames and controls to end up with the sizes being incorrect. The issue was related to vertical resizing, in particular.

The GUI starts up with everything measured correctly and maintains correct measurements/alignments when resizing. I also made a few other resizing improvements.

I'll create a PR on the GitHub repo later tonight or tomorrow morning with these latest changes along with fixes/suggestions from @Kanashius and @pixelsearch.

12 hours ago, Kanashius said:

It did not work this way and I only found _WinAPI_SetSystemCursor solutions with mouse movement detection (if it is over the window), which I did not really like. Maybe you find a better solution

I tried a few things as well but had no success. I'll have to hold off on the cursor for now. But I agree that something needs to be done to visually show indication of dragging.

My attempts kept making the cursor flicker. It showed your cursor, but during mouse movement it would switch back and forth between default cursor and your cursor. I even tried setting the cursor to none for the GUI and the controls to see what would happen but it was still a problem.

[WildByDesign]

@Kanashius I have had some success with the drag cursor. Not quite confident enough about doing a commit yet because I need to test it more. _WinAPI_SetSystemCursor seems to be the only way I could get it done smoothly.

Here are the basics of what I added:

Global $bDragCursorSet = False
Global $hPrevCurDef = _WinAPI_CopyCursor(_WinAPI_LoadCursor(0, $OCR_NORMAL))
Global $hPrevCurHand = _WinAPI_CopyCursor(_WinAPI_LoadCursor(0, $OCR_HAND))
Global $sDragCur = "../assets/ArrowDrag.cur"

; ...

Case $GUI_EVENT_MOUSEMOVE
If Not $bDragCursorSet Then
    $hPrevCurDef = _WinAPI_CopyCursor(_WinAPI_LoadCursor(0, $OCR_NORMAL))
    $hPrevCurHand = _WinAPI_CopyCursor(_WinAPI_LoadCursor(0, $OCR_HAND))
    _WinAPI_SetSystemCursor(_WinAPI_LoadCursorFromFile($sDragCur), $OCR_NORMAL)
    _WinAPI_SetSystemCursor(_WinAPI_LoadCursorFromFile($sDragCur), $OCR_HAND)
    $bDragCursorSet = True
EndIf

; ...

Case $GUI_EVENT_PRIMARYUP
If $bDragCursorSet Then
    _WinAPI_SetSystemCursor($hPrevCurDef, $OCR_NORMAL)
    _WinAPI_SetSystemCursor($hPrevCurHand, $OCR_HAND)
    $bDragCursorSet = False
EndIf