Folder Chooser bugs

I just updated to Juce 1.16 from 1.13 and the “choose folder” functionality isn’t working so well now. A couple of issues with FilenameComponent :

  1. I’m using a FilenameComponent to display and choose a directory. The initial directory used to be loaded when I clicked the button but now it always goes to the desktop. I think it’s a unicode issue in the BFFM_INITIALIZED section of the browser callback – maybe using a PIDL instead of a string would be a better move here?

  2. Once I’ve selected a folder and it’s displayed in the combo box, if I use the button or combo box to choose a new folder, the combo box displays the “nothing selected” text. Tracing through it, I can see that the “set” code is being called twice – the first time it’s good but the second time it wipes out the info.

Does anyone else see this behavior or maybe I’ve set things up incorrectly somehow?

I also have a couple of suggested cosmetic changes for the FilenameComponent class, to indicate when one is using it for a directory:

[code]void FilenameComponent::lookAndFeelChanged()
deleteAndZero (browseButton);

addAndMakeVisible (browseButton = getLookAndFeel().createFilenameComponentBrowseButton (browseButtonText));
browseButton->setConnectedEdges (Button::ConnectedOnLeft);

// start my new stuff
if (isDir)
browseButton->setTooltip(T(“Click to browse for a different folder”));
// end my new stuff


browseButton->addButtonListener (this);


void FilenameComponent::buttonClicked (Button* button)
// start my new stuff
FileChooser fc (TRANS(isDir ? “Choose a new folder” : “Choose a new file”),
// end my new stuff

if (isDir ? fc.browseForDirectory()
            : (isSaving ? fc.browseForFileToSave()
                        : fc.browseForFileToOpen()))
    setCurrentFile (fc.getResult(), true);


Thanks for all your hard work, Jules.

i can confirm that the ‘start directory’ option does nothing at the moment, and it always begins at the outermost level

Sorry, I couldn’t wait… :wink:

  1. I made some changes in juce_win32_FileChooser.cpp. The static defaultDirPath is a TCHAR (which may or may not be unicode, depending on project set-up) and the BFFM_SETSELECTION message may or may not be unicode (depending on the JUCE unicode setting and availability of the library). The problem is that their “unicodeness” is decided independently of each other. I changed defaultDirPath to be a String

static String defaultDirPath;

made sure its assignments are Strings

defaultDirPath = initialDir;

defaultDirPath = initialDir;

defaultDirPath = String::empty;

and then did unicode conversions in the SendMessage call

static int CALLBACK browseCallbackProc (HWND hWnd, UINT msg, LPARAM lParam, LPARAM lpData) { if (msg == BFFM_INITIALIZED) { if (wSHBrowseForFolderW != 0) SendMessage (hWnd, BFFM_SETSELECTIONW, TRUE, (LPARAM) (const juce_wchar*) defaultDirPath); else SendMessage (hWnd, BFFM_SETSELECTIONA, TRUE, (LPARAM) (const char*) defaultDirPath); } ...

  1. I made a quick change in juce_FilenameComponent.cpp for this one.

[code]void FilenameComponent::setCurrentFile (File newFile,
const bool addToRecentlyUsedList)
if (enforcedSuffix.isNotEmpty())
newFile = newFile.withFileExtension (enforcedSuffix);

if (newFile.getFullPathName() != lastFilename)
    lastFilename = newFile.getFullPathName();

// start change – swapped these two calls
addRecentlyUsedFile (newFile);
filenameBox->setText (lastFilename, true);
// end change

    sendActionMessage (getName());


The problem was that, after setting the combobox text, the combobox was being cleared and refilled by the addRecentlyUsedFile call, which would wipe out the current index. Now it refills the combobox first and then sets the current text.

These changes seem to solve the aforementioned problems without blowing up anything else. After all the work you’ve saved me Jules, I hope you don’t mind me trying to return the favor.

Ah, thanks Randy! I’d actually already fixed the file chooser bug, but thanks for the hint on the FilenameComponent one!