cFileSelectFolder 1.6.1

I have problem with downloading pdf file with documentation. 

 

Sorry about that. It now works.

Perhaps there are instructions somewhere on how to refer to an uploaded pdf.

I'm looking at the possibility of using cFileSelectFolder as a better way to select folders. But I immediately ran into a case where Select doesn't return a folder if that folder has a subfolder. It displays "Invalid Selection" at the bottom when I try to select the \Videos folder in the attached example. I am testing with the Desktop Hierarchy Example.

Is this by design?  Or am I using the script the wrong way?

I've tracked down the statements that cause Invalid Selection for \Videos ... which leaves the question of "Why does it work this way?"

ElseIf $a10[2]='Videos' Then
                If $sTreePath='Desktop\Libraries\Videos' Then
                    $sRet = ''

My conclusions are 1) \Videos isn't a real directory and 2) "My Videos" returns \Videos on my user path (and not \My Videos ... because that's not a real directory, either).

You might conclude that I don't use these "virtual paths" much, at all. That is correct.

The bottom line: given the MSFT-imposed confusion factors, your calls are working correctly.

Sorry to be unresponsive! Being so is not normally my way, but I am up to my ears in a problem with interactive PDFs. I am pleased to see that you have found the solution.

I know that my script does not detect whether a folder is a library properly, hence the hard coding of Desktop\Libraries\Videos (and other Windows libraries).

Does anyone know how I can detect a user-created library? attrib C:\Users\Chris\Videos tells me that the attribute is read-only but any folder can be set to read-only (as can a file), so a folder being read-only does not seem to tell me that it is a library.

For example: if I create a library MyLib how can I detect that this is a library?

 

 

Edited February 11, 2019 by c.haslam

I am continuing my work with your great UDF, but I've come upon one problem that I can't figure out:

Upon first use of a directory tree, clicking a [+] to expand a directory to show its subdirectories sometimes results in a blank entry. If I then cycle the display by clicking [-] to collapse, and then [+] to re-expand, then everything always displays properly. I would estimate that the blank entry only occurs about one out of every 20 times I use [+] ... so not very often.

Do you have any idea what might be causing this effect?

Thanks for your help.

Sorry, but I don't know why. Today I found another bug: if you double-click on a folder that has no children, nothing should happen. But I have a case where the path is on a USB stick. I double-clicked on this childless folder and the treeview disappeared. Even so, cFileFolder returned the correct path.

I am willing to guide you though the code if you wish to try to fix these bugs.

...chris

Thanks for you reply. Regarding the double click selection, I have isolated a case that is opposite of the one you mention: in expanding the tree, very occasionally a directory that has children is reported as not having children. Repeating the selection causes it to work properly. And often it works properly on the first try. (In the example, below, the 1.6.4.1 entry really does have subdirectories.)

Both problems seem to revolve around the inventory of children before expanding the tree. As I become more familiar with your methods and functions, I'll try to isolate the cause. I just find it odd that it works most times, but fails randomly in only a few instances.

I'll also mention that—since my own script already has COMMAND and NOTIFY functions—I have determined that I only need to invoke calls to your message handlers when there is a folder request active. That prevents any unnecessary overhead during normal action in my script.

 

In trying to isolate the differences I'm observing (the same tree displaying differently on different runs of my test program), I have this question:

Do you know which call places the plus sign in front of an expandable folder?  (Sometimes it's there. Sometimes it's not.)

I'm looking at _FSF_FillFolder(), but I can't spot a problem or determine what else to test. 

I'd like to add one observation: the following comment indicates that the check of file attributes indicates that the ListView entry is a directory:

; Create dummy child to force [+] display and as marker for filling subdir

However, it depends on the 'find next file' to return the attributes in @extended.  Could it be that the function is somehow flawed?  Or should I be looking elsewhere?

 

FOUND ... sort of.  The main 'problem' is now this:  the [+] is there, but invisible ... until you mouse over the node and then it appears.

I haven't noticed this behavior on other trees ... and it isn't corrected with a full refresh/update of the GUI. However, scrolling the tree way up and way down causes the [+] to appear.

Any ideas?

I will try to answer all of your questions, but I miss some. If I do, please ask them one at a time.

Regarding the exdpansion button:

• I think I have seen FileSelectFolder() not show the expansion button. I know that it shows none (or almost none) unless the mouse is over the left-hand pane.
• My project started with Melba23's ChooseFileFolder. You might look his code. Some of it is in cFileFelectFolder.
• I applaud your efforts to reduce overhead. I suspect that treeview itself incurs a chunk of CPU activity.
• Expansion happens below Case $g_cFSF_Expand_Dummy (line 478)
• In _FSF_FillFolder, you might look at replacing the calls to FileFindFistFile() and FileFindNextFile() with DLLCalls, but this will add to the overhead. Also, you might try replacing how attributes are determined, i.e. call FileGetAttributes rather than using @extended.
• And here I blow my own horn! I use my _GuiDebug() and _ConsDebug() a lot in debugging. They do incur overhead! You can find this UDF at https://www.autoitscript.com/forum/files/file/454-cdebugau3/
• I am no expert in message handlers. In cFileSelectFolder, they were picked up from ChooseFileFolder.

Do keep me posted, and ask any questions you like. It is a while since I wrote cFileSelectFolder.

(BTW your latest Comment arrived when I was mostly through writing this Comment.)

Thanks for your response. All that is good information. And I, too, will admit that I've used a lot of code from forum examples without necessarily knowing how it does what it does. But I've had good success getting to the bottom of problems that affect their use. This is just one more instance.

But I want to emphasize that using cFileSelectFolder has been a great enhancement to my scripts. I'll continue to look for areas to enhance and will let you know of them.

Thanks for the help you've given.

qwert,

In _FSF_FillFolder, I get the attributes from @extended. You might like to try getting them from FileGetAttrib. Perhaps this would avoid a possible bug in AutoIt.

qwert,

I think I have fixed the problem(s): in version 1.6.0 the script no longer starts a second file/folder search when a search is already in progress. I suspect that the cause was with Windows, not AutoIt native code.

qwert,

After significant effort, I have a case where expanding a folder which has another folder within it shows the name of the child folder as blank. (You had this problem.) This happens every time, not just once in a while. The drive is a USB memory stick. The first level of folders show AOK but expanding any of the folders that has a child fails to show the folder name.

This is when _cFileSelectFolder is called from a relatively long production script (hundreds of lines of code); however _cFileSelectFolder behaves properly when it is called with the same parameters from a short test script.

The old version of the production script calls FileSelectFolder. That expands folders AOK.

I have created a version of the production script that allows the user to choose a child folder by calling Mebla23's _CFF_Choose (in his ChooseFileFolder.au3). That version shows the child folder without a name when its parent is expanded (like my _cFileSelectFolder). This is when the above-mentioned folder, i.e. on the USB memory stick,  is expanded.

You have suggested that there may be a bug in AutoIt. Based on the above, I am inclined to agree.

An attempt to summarize my findings:

• sub folder's name shows: short test script, and production script that calls FileSelectFolder
• sub folder's name does not show: production script that calls _cFileSlectFolder, and production script that calls _CFF_Choose

I am well aware that the way of telling the developers about a possible bug is to provide a short script that demonstrates the problem; however, in this case my short script always works AOK, so I do not know how to proceed. Suggestions are most welcome!

Edited May 26, 2019 by c.haslam

Version 1.6.1 is now available for download. It fixes the + (expand) sign not showing at times when it should.