FileExplorer Treeview and Listview (TreeListExplorer)

[WildByDesign]

5 hours ago, Kanashius said:

I noticed, that they are at the bottom, so I added something to remove anything below the last added item, when filling the treeview... maybe that fixes your problem.
I will put it here, until you confirm if it works, before adding it to the main post.

 I have only tested with the Example so far, but this seems to have fixed the issue with the HasChilds randomly showing up in the treeviews.

I noticed another issue in both 2.9.0 and 2.9.1 after some more testing. Specifically in the Example. The bottom-right listview fails to load approx. 20% of the time which is interesting because I noticed that it was happening when the HasChilds shows up. In 2.9.1, HasChilds is gone, but the listview in the bottom-right still fails to load 20% of the time. Clicking on anything in the top-right treeview still wont make the listview show up.

EDIT1: Caught the following in the console:

__TreeListExplorer_AddView $hListView failed: 2:50

 

EDIT2: I went back to 2.9.0 for some testing because I wanted to find out the correlation between the listview failure on the right side bottom and the HasChilds issue on both treeviews and the correlation is 100%. So there is some sort of relation between both issues. They only happen together at the same time. In 2.9.1, the HasChilds is hidden but the listview issue still occurs.

Edited 14 hours ago by WildByDesign

[Kanashius]

That is very confusing to me... The Error __TreeListExplorer_AddView $hListView failed: 2:50 indicates, that the $hListView is not a ListView and is thus not added to the system $hTLESystemRight. This is tested by (shortened code): StringInStr($_WinAPI_GetClassName(GuiCtrlGetHandle($idListVIew)), "ListView") . This should only fail, if the ListView is somehow not created... I have no idea why that would happen just sometimes... Either it fails or it works... Otherwise my first thought would be: Is there some Multithreading stuff going wrong (That AutoIt does not support at least in the coding part) and even then...

What Version of AutoIt are you using? Maybe there is something in a beta, where they try multithreading so the listview is loaded later or something...

[WildByDesign]

37 minutes ago, Kanashius said:

What Version of AutoIt are you using? Maybe there is something in a beta, where they try multithreading so the listview is loaded later or something...

My AutoIt version is 3.3.16.1 and I'm running Windows 11 24H2 with latest updates.

I figured it out. It's a 64-bit issue. I always run your stuff with 64-bit AutoIt and never had issue. I just switched AutoIt to run the scripts with x86 and the issue is gone.

EDIT: You can test this by simply renaming C:\Program Files (x86)\AutoIt3\AutoIt3.exe to C:\Program Files (x86)\AutoIt3\AutoIt3_x86.exe and  C:\Program Files (x86)\AutoIt3\AutoIt3_x64.exe to C:\Program Files (x86)\AutoIt3\AutoIt3.exe to temporarily test the scripts as x64 without having to reinstall AutoIt.

All of your previous UDF versions worked perfectly on x64. But it is definitely and x64 AutoIt issue.

Edited 13 hours ago by WildByDesign

[Kanashius]

Ok, I found the issue.

It is a Bug, that was already found in the TreeView UDF. But it was only fixed, if the provided ListView was a ControlID and not a ControlHandle (like I use).
So for now, I wrote a custom _GuiCtrlTreeView_Delete method, that fixes that and I will report the bug.

Details:
 

Spoiler

 GuiTreeView.au3 (Line 435+)

If Not IsHWnd($hItem) Then $hItem = _GUICtrlTreeView_GetItemHandle($hWnd, $hItem)
If GUICtrlDelete($hItem) Then Return True
Return _SendMessage($hWnd, $TVM_DELETEITEM, 0, $hItem, 0, "wparam", "handle", "hwnd") <> 0

needs to be changed to

If Not IsPtr($hItem) Then 
    $hItem = _GUICtrlTreeView_GetItemHandle($hWnd, $hItem)
EndIf
Return _SendMessage($hWnd, $TVM_DELETEITEM, 0, $hItem, 0, "wparam", "handle", "hwnd") <> 0

The same Problem already occurred in Line 445+, but was only fixed, if the $hWnd was not a ControlHandle.

; Danyfirex founding
; If We Use IsHWnd It will always return false. So You will always call _GUICtrlTreeView_GetItemHandle and You will get the GUICtrlGetHandle issue that happens randomly
; So let's use IsPtr and remove GUICtrlDelete So we can always delete using the Control Handle.

This also explains the "hasChild" elements you had in your TreeViews before. They did not get deleted, but instead AutoIt tried to delete "random stuff" and sometimes that "random stuff" was the ListView.

By the way: You do not need to exchange the AutoIt.exe files to run as x64. A simple #AutoIt3Wrapper_UseX64=Y at the beginning of the Script is enough.

I hope that was the last issue for now. Thanks for the help, patience and testing @WildByDesign 

Edited 10 hours ago by Kanashius