ChooseFileFolder - BugFix Version 11 Jun 15

189 posts in this topic

Posted (edited)

BUGFIX VERSION 11 Jun 15

Fixed: A variable declared inside a first Case statement and not recognised in another - sorry about that

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. :D

M23

Edited by Melba23
2 people like this

Share this post


Link to post
Share on other sites



Posted (edited)

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

Edited by guinness

Share this post


Link to post
Share on other sites

Posted

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

Share this post


Link to post
Share on other sites

Posted

UEZ,

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

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

Share this post


Link to post
Share on other sites

Posted (edited)

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 by guinness

Share this post


Link to post
Share on other sites

Posted (edited)

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 by UEZ

Share this post


Link to post
Share on other sites

Posted

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

Share this post


Link to post
Share on other sites

Posted

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

Share this post


Link to post
Share on other sites

Posted

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

Share this post


Link to post
Share on other sites

Posted

UEZ,

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

M23

Share this post


Link to post
Share on other sites

Posted

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

Share this post


Link to post
Share on other sites

Posted (edited)

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 by Melba23

Share this post


Link to post
Share on other sites

Posted (edited)

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 by Ascend4nt

Share this post


Link to post
Share on other sites

Posted (edited)

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 by Yashied

Share this post


Link to post
Share on other sites

Posted (edited)

'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 by Ascend4nt

Share this post


Link to post
Share on other sites

Posted

'INT' is 4 bytes.

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

:)

Share this post


Link to post
Share on other sites

Posted

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.

Share this post


Link to post
Share on other sites

Posted

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.

:)

Share this post


Link to post
Share on other sites

Posted

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"

Share this post


Link to post
Share on other sites

Posted

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? :idiot:

New UDF and example in the first post. ;)

M23

1 person likes this

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.