Jump to content

cFileSelectFolder 1.6.1

   (0 reviews)

8 Screenshots

About This File


_cFileSelectFolder() is intended as a replacement for native FileSelectFolder() for selecting folders: It implements the left pane of FileSelectFolder(), and goes beyond FileSelectFolder() in several ways.

•    It is user friendly and designed to be easy to use;
•    New folder, Delete folder and Rename folder controls are optional;
•    Its GUI can be placed anywhere, including centred on another window;
•    Neither needs nor uses CLSIDs;
•    Checks calling parameters rigorously, with the user choosing either to show error messages in a dialog or to set @error and return them to the caller;
•    For local and mapped drives, accepts file specifications with drives that can be drive letters, drive labels, or both,
•    For local and mapped drives, always returns drive letter:\ ...\ so its output is compatible with native AutoIt functions.
•    For UNC paths, returns \\computer\share\...\
•    For unmapped drives on computers on the network,  offers a shortcut to shares.
•    Selecting a treeview item to be highlighted initially is specified in a user-friendly way, including a diagnostic for when the user gets it wrong
•    Because it can be called with many arguments, a user can show a list of the arguments / parameters and their values

The root of the treeview can be:
•    The Desktop hierarchy with Desktop at the top
•     Partial Desktop hierarchy with any other Desktop item at the top, with or without local/mapped drives and file folders, or remote shares and file folders (as appropriate),
•     Local/mapped drives and file folders, or
•    Remote shares and folders.

The script and example scripts are in the zip file. Documentation beyond what is in the UDF header is  in the PDF file,   cFileSelectFolder 1_6_1.pdf

Comments and suggestions are most welcome.




cFileSelectFolder 1_6_1.pdf

What's New in Version 1.6.1



Edit history

1.4.0    Added $iFolder parameter to make New folder, Delete folder and Rename folder buttons optional. A SCRIPT BREAKING CHANGE
Added detection of errors in the types of parameter values
1.4.1    On entry, disables parent dialog and re-enables/activates it when function returns
1.4.2    When $sInitialTree is specified, collapses all other leaves at this level
1.5.0    Handles non-standard items under Desktop > @UserName
1.5.1    If $sRoot='' or 'Desktop', now, if connected to router shows Desktop once else not at all
1.6.0    _FSF_FillFolder(): To avoid erratic runtime errors, rewritten to avoid more than one file search at a time; now sorts folder names

1.6.1 _FSF_FillFolder(): To correct display of expand + signs, rewrote file attribute logic


User Feedback

Recommended Comments

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?


Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by c.haslam
Link to comment
Share on other sites

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.


Link to comment
Share on other sites

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.


Link to comment
Share on other sites

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



Link to comment
Share on other sites

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. 


Link to comment
Share on other sites

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?


Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.)

Link to comment
Share on other sites

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.

Link to comment
Share on other sites


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.

Link to comment
Share on other sites


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.

Link to comment
Share on other sites


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 by c.haslam
Link to comment
Share on other sites

  • Create New...