ChooseFileFolder - Interim Version 11 Mar 21

[Melba23]

INTERIM VERSION 11 Mar 21

A bug in the x64 implementation of some the library TreeView functions meant that some replacement working functions were added to the UDF. Now the Beta TreeView library (from 15.3) has been modified, these functions are no longer required, but they will remain until the modified library is formally released. However, other changes in the Beta mean that the replacement functions will not work under it - don't you just love compatibility problems!

So here is an interim release with a modified replacement function so that it will function with Release and Beta versions under both x32 and x64 - I hope!

New UDF and examples in zip below.

Previous version descriptions:  ChangeLog.txt

 

---

I was fed up with using the native FileOpenDialog and FileSelectFolder which appeared anywhere on the screen in seemingly random sizes and often allowed users to select files from other than the path desired. So I decided to write my own version of an Explorer-type treeview and here it is: ChooseFileFolder.

What are the main advantages of this UDF over the normal dialogs?

• Common format for both file and folder selection.
• Ability to size and place the dialog where you want it rather than how Windows last left it.
• Ability to select (and delete) multiple items - even from different folders or drives. You can also select both files and folders from the same tree
• Ability to preselect items.
• And there is also a function to allow you to use an existing treeview in your own GUI to display the folder tree - no need to have a dialog at all.

Here is a zip file with the UDF and several example scripts: ChooseFileFolder.zip

As usual happy to take feedback and, preferably, plaudits.

M23

Edited March 11, 2021 by Melba23

[guinness]

Wouldn't expect any less! Purely brilliant, I am sure I will find some use for this UDF.

Edited February 10, 2011 by guinness

[UEZ]

I get an error on example 6 when I select my C drive ->

Line 419 (File "C:\Coding\AU3\GUI\ChooseFileFolder\ChooseFileFolder.au3"):

$hTreeView = GUICtrlCreateTreeView(0, 0, $iW - 20, $aTV_Pos[3])

$hTreeView = GUICtrlCreateTreeView(0, 0, $iW - 20, $aTV_Pos^ ERROR

Error: Subscript used with non-Array variable.

Btw, nice coding!

Br,

UEZ

[Melba23]

UEZ,

That has nothing to do with the C: drive - it is a result of an existing treeview not being found.

I cannot reproduce it at the moment - which makes it a bit tricky to debug. When you first run Example 6 do you get a visible list control under a vertically moveable separator bar? Had you selected any other drive before your C: drive or was this the first one?

Aside from that, it must have taken an eternity to index the whole C: drive - I just did it once and nearly died of boredom.

M23

[guinness]

I selected another Drive and then the C:\ Drive and I didn't get the same error! I also repeated Example 6 with just selecting the C:\ Drive and still no problem. Very weird indeed why UEZ got this error.

Edited February 10, 2011 by guinness

[UEZ]

I'm starting ChooseFileFolder_Ex.au3.

Ex 1: seems to be ok -> I can see the tree

Ex 2: seems to be ok -> I can see the tree

Ex 3: seems to be ok -> I can see the tree

Ex 4: seems not to be ok -> nothing is displayed -> $hTreeView = 0

Ex 5: no tree. I can select a drive and it starting to indexing it

Ex 6: no tree. I can select a drive. When I select my C drive the error appears. I've only one local drive - C. -> $hTreeView = 0

Ex 7: files are listed

Looks like there is no handle to the treeview.

If I find the the bug I will tell you!

Br,

UEZ

Edited February 10, 2011 by UEZ

[UEZ]

If you start Ex 6 with $sRet = _CFF_Choose("Ex 6: Select multiple files", 300, 500, -1, -1, "", Default, 0, True) it is working properly.

If $fSingle_Sel = False it will fail.

Test system: Win7 x64 with latest AutoIt version.

Ex 6 debug lines when $fSingle_Sel = False

@@ Debug(249) : $sRoot = 
>Error code: 0
@@ Debug(250) : $fSingle_Sel = False
>Error code: 0
@@ Debug(325) : $hTreeView = 0
>Error code: 0
@@ Debug(326) : $hTreeView_Handle = 0
>Error code: 0

Ex 6 debug lines when $fSingle_Sel = True

@@ Debug(249) : $sRoot = 
>Error code: 0
@@ Debug(250) : $fSingle_Sel = True
>Error code: 0
@@ Debug(325) : $hTreeView = 7
>Error code: 0
@@ Debug(326) : $hTreeView_Handle = 0x004A08CE
>Error code: 0

Br,

UEZ

[Melba23]

UEZ,

It looks like the problem is in the GUIFrame UDF not this one, as you only have a problem when $fSingleSel = False. In that case, the UDF creates a treeview within a frame created by GUIFrame and this is obviously not happening.

Have you tried to run the GUIFrame UDF and its examples - if not could you please do do? I wonder if there is a problem with it on x64 systems - it uses many DllCalls so I would not be at all surprised.

M23

[UEZ]

I tested GUIFrame on following virtual machines:

WinXP x86 -> working properly

Win2003 x64 -> not working

Windows2008 x86 -> working

And on my notebook:

Win7 x64 -> not working

Seems to be a problem with x64 operating systems!

Em is:

C:\Coding\AU3\GUI\GUIFrame\GUIFrame_Example_1.au3 (17) : ==> Subscript used with non-Array variable.:
GUICtrlCreateLabel("", 5, 5, $aWinSize[0] - 10, $aWinSize[1] - 10)
GUICtrlCreateLabel("", 5, 5, $aWinSize^ ERROR

#AutoIt3Wrapper_UseX64=n will not help!

Br,

UEZ

[Melba23]

UEZ,

Interesting. With some help from Yashied I thought the GUIFrame UDF was x64 compatible. - see here and the next few posts.

M23

[guinness]

I tested on x64 and it worked, but then I have a single drive with multiple partitions.

[Melba23]

guinness,

Thanks for that. I have no other reports of the GUIFrames UDF not being x64 compatible after Yashied helped me fix it.

The size of drive has nothing to do with it - it is a simple case of the treeview not being created as a result of GUIFrames failing to create the frame! So as the error is most certainly coming from that UDF (and the fact that UEZ cannot run that UDF on x64) I am wondering what is different with UEZ's machine.

M23

Edit: Typnig.

Edited February 10, 2011 by Melba23

[Ascend4nt]

Another nice UDF Melba. I looked into the x64 stuff.. the only issue I see is the same one as GUIListViewEx had with the NMHDR, and a simple 'Program Files' location change.

Here's the 'x64 compatible' change for double-click notifications to work properly in x64 mode:

Func _CFF_WM_NOTIFY_Handler($hWnd, $iMsg, $wParam, $lParam)

    #forceref $hWnd, $iMsg, $wParam

    Local $tStruct = DllStructCreate("hwnd hWndFrom;uint_ptr IDFrom;int_ptr Code;int Spec", $lParam)
    If @error Then Return
    Switch BitAnd(DllStructGetData($tStruct, "Code"),0xFFFFFFFF)
        Case 0xFFFFFFFD ; $NM_DBLCLK
            $fCFF_DblClk = DllStructGetData($tStruct, "hWndFrom")
    EndSwitch

EndFunc   ;==>_CFF_WM_NOTIFY_Handler

And at the top of 'ChooseFileFolder_Ex.au3', you might put this:

Local $sProgFiles=@ProgramFilesDir
If @AutoItX64 Then $sProgFiles&=' (x86)'

..and then change any occurrences of @ProgramFilesDir to $sProgFiles. This change is due to the fact that AutoIt installs in the x86 Program Files folder ('C:\Program Files (x86)") on 64-bit O/S's. In x86 mode, that's where it looks by default, but not in x64 mode. This will give your example the ability to run the same in both bit modes.

*edit: oops, meant 'double' click

Edited February 10, 2011 by Ascend4nt

[Yashied]

You can't. The "Code" member in NMHDR structure requires four bytes (UINT). At least it did not correctly. Just replace UINT to INT. BTW, exactly in this form, NMHDR structure is defined in StructureConstants.au3.

Func _CFF_WM_NOTIFY_Handler($hWnd, $iMsg, $wParam, $lParam)

    #forceref $hWnd, $iMsg, $wParam

    Local $tStruct = DllStructCreate("hwnd hWndFrom;uint_ptr IDFrom;int Code", $lParam)
    Switch DllStructGetData($tStruct, "Code")
        Case -3 ; $NM_DBLCLK
            $fCFF_DblClk = DllStructGetData($tStruct, "hWndFrom")
    EndSwitch

EndFunc   ;==>_CFF_WM_NOTIFY_Handler

And the following condition is unnecessary.

If @error Then Return

If the pointer is invalid (not zero), you get a garbage in the structure or crash with "Access is denied", but not @error.

Edited February 11, 2011 by Yashied

[Ascend4nt]

'INT' is 4 bytes. NMHDR changed in x64 so that the last item is 8 bytes (int_ptr), and apparently without notifying anyone. The MSDN info is wrong.

The 'Spec' item was Melba's addition, I just kept it in there in case that was what he was going to use someday if it points to a larger struct.

Ahh, and the @error thing is Melba's idea, not mine - I only left it as it was coded.

*edit: for reference, you can look at

Edited February 11, 2011 by Ascend4nt

[Yashied]

'INT' is 4 bytes.

Yes of course, I wanted to say a double word.

[Ascend4nt]

BTW, exactly in this form, NMHDR structure is defined in StructureConstants.au3.

Yeah, that's an issue that has supposedly been fixed in 3.3.7.0, check out ticket # 1479 regarding WM_NOTIFY. For now I've manually edited my AutoIt Includes to fix that problem, since it seems unlikely we'll see a new version of AutoIt released any time soon.

[Yashied]

Yes, you are right, this is an alignments problem under x64 (). But the Melba23's problem in this case in the following.

"int IDFrom" instead of "uint_ptr IDFrom".

Thanks for the links.

[Yashied]

I think MSDN is correct, NMHDR structure looks like this.

$tagNMHDR = "hwnd hWndFrom;uint_ptr IDFrom;int Code"

But the following structures that includes NMHDR must be aligned to sizeof(ptr). For example

; x64
$tagNMHEADER = $tagNMHDR & ";byte Alignment[4];int Item;int Button;ptr pItem"

; x86
$tagNMHEADER = $tagNMHDR & ";int Item;int Button;ptr pItem"

[Melba23]

Ascend4nt and Yashied,

Thank you both for your efforts.

I mentioned a tutorial on this x64 compatability problem to enlighten hobbyist coders like me the last time it came up - I suppose both of you are still not interested in writing one?

New UDF and example in the first post.

M23