Jump to content

cFileSelectFolder 1.6.0

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

Features:
•    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_0.pdf

Comments and suggestions are most welcome.

 

 

 


What's New in Version 1.6.0

Released

 

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




User Feedback

Recommended Comments

Sorry about that. It now works.

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

Share this comment


Link to comment
Share on other sites

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?

5c5d2fcf3bde2_InvalidSelection.png.ba22b50f209fd0b7feda13b52e0cbb70.png

Share this comment


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.

Share this comment


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.

Share this comment


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

Share this comment


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.

1397154515_Everynowandthen.png.0d7070460212fa8f7666634d542be654.png

Share this comment


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.

...chris

Share this comment


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

125869090_NoIndication.PNG.cb6f99a66e1204b3579ec8e0f1b6be9d.PNGIndicated.PNG.a785920e9418600755ea85f8046d7bb1.PNG

 

Share this comment


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. 

1843406251_PlusIndicator.png.00e0a1a93ef0f3de7e2efea7164e2d6c.png

Share this comment


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?

 

Share this comment


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?

Share this comment


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

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

Share this comment


Link to comment
Share on other sites

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.

Share this comment


Link to comment
Share on other sites

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.

Share this comment


Link to comment
Share on other sites

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 by c.haslam

Share this comment


Link to comment
Share on other sites
  • Similar Content

    • By YawStar
      Hi there. I want to add my FileSelectFolder function with "include subdirectories Checkbox". The example image is shown in below.

    • By Gringo
      Hi,
      I'm trying to:
      -Select a file in a folder (to store it to an ini file)
      -Write the file on an ini
      -Copy files to the folder selected by the user
      instead of using FileOpenDialog then FileSelectFolder, I was wondering if it was possible to do the whole thing only with FileOpenDialog spliting the value returned in 2 variables. I got something like that for the first part (select a file and store it to an ini file)
      Local $message = "Select your executable" Local $pathk = FileOpenDialog($message, "C:" & "", "Select the executable you want to terminate (*.exe)", 1 + 4) Local $path = "None" ;ici je dois copier les fichiers $split = StringSplit($pathk, "\") $tokill = $split[$split[0]] If @error Then MsgBox(4096, "", "No Executable chosen") Else MsgBox(4096, "", $pathk & " Will be terminated " & @LF & @LF & "Press OK to EXIT ") IniWrite(@ScriptDir & "\path.ini", "Torun", "path", $path) IniWrite(@ScriptDir & "\path.ini", "Tokill", "pathk", $tokill) EndIf As you can see I manage to split the value returned by FileOpenDialog to have only the exe but as a noob I can't manage to get the path to copy the files I need to the same path.
      Any idea? ^^
    • By tremolux66
      I've abandoned the FileSelectFolder() approach and rolled my own UDF to create a dialog containing the folder list in a ListView, which seems to work fine. It's also a better fit to our requirements: we don't really want the user wandering around in the folder-selection dialog, plus the UDF displays some associated info for each folder in a second column. Thanks again to the forum members who took a look at this.
      I'm writing an installer script that needs to run as Administrator so it can, e.g., write files into protected directories. The problem is that when I call FileSelectFolder(), there is a 60-second delay before the dialog appears. If I run as an ordinary user (in the Administrators group), there's no delay, but I don't think that will work: for one thing, the installer needs to create a symbolic link, which a member of the Administrators group can't do unless the program is elevated. (This is Win 7 x64.)
      (The installer will be run using an Admin account; the other user accounts are locked down and don't have access to the filesystem, the Start menu, Computer, etc. - it's a turnkey system.)
      Any idea what causes the delay? And is there a way around it?
       
    • By TheDcoder
      Hello! , I have a little doubt about the "root dir" parameter in FileSelectFolder, The helpfile states:
      Questions:
      1. GUI file tree? Isn't that something like this?:

      But the dialog for selecting a folder in FileSelectFolder is similar to the dialog of FileOpenDialog
       
      2. "It limits the choice in the root folder"... "" is considered to be @DesktopDir, then why am I able to select folders outside the Desktop folder?
       
      Thanks in Advance, TD
    • By JibsMan
      My program starts by asking the user to select or create a directory to copy files to. FileSelectFolder won't let me type in a directory name and have it created. DirCreate doesn't have the GUI interface to allow the user to select a directory. Is there a method to display the File Tree and let the user either select an existing directory OR enter a directory name to add?
      Thanks!
      JibsMan
×
×
  • Create New...