• Announcements

ChooseFileFolder - BugFix Version 18 Apr 15

183 posts in this topic

Posted (edited) · Report post

BUGFIX VERSION 18 Apr 15

Fixed: A variable first declared inside an If statement - sorry about that. :>

Previous version descriptions: [attachment=46807:ChangeLog.txt]
[hr]
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: [attachment=46806:ChooseFileFolder.zip]

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

M23 Edited by Melba23
yahaosoft likes this

Share this post


Link to post
Share on other sites



Posted (edited) · Report post

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 · Report post

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 · Report post

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) · Report post

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) · Report post

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 · Report post

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 · Report post

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 · Report post

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 · Report post

UEZ,

Interesting. With some help from Yashied I thought the GUIFrame UDF was x64 compatible. - see [post='857326']here[/post] and the next few posts. :)

M23

Share this post


Link to post
Share on other sites

Posted · Report post

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) · Report post

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) · Report post

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) · Report post

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) · Report post

'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 my post on Melba's GuiListViewEx thread. Edited by Ascend4nt

Share this post


Link to post
Share on other sites

Posted · Report post

'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 · Report post

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 · Report post

Yes, you are right, this is an alignments problem under x64 (similar problem). 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 · Report post

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 · Report post

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
nvt likes this

Share this post


Link to post
Share on other sites

Posted (edited) · Report post

No Melba, do the following, or as advised by Ascend4nt (BitAND...).

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

Share this post


Link to post
Share on other sites

Posted · Report post

Yashied,

Changed. ;)

I thought -3 was 0xFFFFFD? :)

M23

Share this post


Link to post
Share on other sites

Posted (edited) · Report post

I thought -3 was 0xFFFFFD? :)

Yes, only 0xFFFFFFFD

But

"INT" => DllStructGetData($tStruct, "Code") = 0xFFFFFFFD (-3)
"INT_PTR" => BitAND(DllStructGetData($tStruct, "Code"), 0xFFFFFFFF) = 0xFFFFFFFD (-3) under x64

"INT_PTR" is just a trick. Edited by Yashied

Share this post


Link to post
Share on other sites

Posted · Report post

Yashied,

Got it - which is why I had to use $iCode = BitAND(DllStructGetData($tStruct, 3), 0xFFFFFFFF) in GUIListViewEx to match the other possible codes. :)

Thanks for the explanation - I am glad a couple of people round here understand this stuff because it makes my brain hurt almost as much as SREs. ;)

M23

Share this post


Link to post
Share on other sites

Posted · Report post

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"

That does make sense since NMHDR is part of so many different larger structures. I'm sure there must be one where a 'ptr'-sized variable comes directly after NMHDR. That is actually how I had fixed the Constants in my AutoIt Includes - just added a 4-byte Alignment offset in x64 mode, like I had originally done in Melba's other code. Its one of the few cases where structure item names (as opposed to numbers) are a good idea to use.

And it does get rid of that annoying practice of shrinking int_ptr down to 32-bits.

Sorry Melba for hijacking your thread. But hey, at least the information on NMHDR problems is out there (and hopefully searchable).

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.