FileChooserDialogBox save button

General JUCE discussion
1

I’m using the FileChooserDialogBox as a ‘save as’ dialog, and I noticed that the save button only becomes available when a file is selected in the chooser window, but incorrectly stays unavailable if a file name is typed in (IE you are creating not overwriting a file).

On a side note, I’m noticing that the FileChooserDialogBox components are really slow on some systems. Is anyone else seeing this?

2

i’ve not noticed the button problem, but i’ll prefer niall’s PhilChooser all the time. far faster on all systems and tweakable as hell :wink:

3

Damn… I think to get it to update the button should just be a case of changing this method in juce_FileBrowserComponent.cpp:

void FileBrowserComponent::textEditorTextChanged (TextEditor&) { selectionChanged(); }

The slowness is a bit worrying - any clues as to the kind of system that’s struggling? Is it a network drive, or something?

4

…no, sorry, I didn’t think that fix through… Try this instead:

[code]void FileBrowserComponent::textEditorTextChanged (TextEditor&)
{
if (mode == saveFileMode)
{
ComponentDeletionWatcher deletionWatcher (this);

    for (int i = listeners.size(); --i >= 0;)
    {
        ((FileBrowserListener*) listeners.getUnchecked (i))->selectionChanged();

        if (deletionWatcher.hasBeenDeleted())
            return;

        i = jmin (i, listeners.size() - 1);
    }
}

}[/code]

5

I’ll try that fix tomorrow.

On the slowness:

I’ve just had a possible thought. I can’t verify this as I’m not near one of the machines that performs slowly, but it might be related to machines that have floppy drives.

It takes about 6 seconds for the file chooser dialog to show, then around 2 seconds for a directory change.

The directory change bit is throwing me though, as this shouldn’t really be affected by the presence of a floppy drive, or network drive. :?

6

Six seconds is crazy…

I don’t have anything with a floppy drive in it these days, but looking through the code, there’s a chance that it could glitch while it looks up the names of the root drives. Try this instead, at about line 438 of juce_FileBrowserComponent.cpp:

[code] for (int i = 0; i < roots.size(); ++i)
{
const File* const drive = roots.getUnchecked(i);

    String name (drive->getFullPathName());
    rootPaths.add (name);

    if (drive->isOnHardDisk())
    {
        String volume (drive->getVolumeLabel());

        if (volume.isEmpty())
            volume = T("Hard Drive");

        name << T(" [") << drive->getVolumeLabel() << T(']');
    }
    else if (drive->isOnCDRomDrive())
    {
        name << T(" [CD/DVD drive]");
    }

    rootNames.add (name);
}

[/code]

With this code it won’t try to look-up the name of any volume that’s not a hard-drive.

7

Thanks Jules. Both fixes worked great.

I modified the first fix to also deal with loading files. I imagine you’ve already something like this, but for anyone else reading this thread before the next JUCE release:

void FileBrowserComponent::textEditorTextChanged (TextEditor&)
{
	if ((mode == saveFileMode) || 
		((mode == loadFileMode) && (getCurrentFile().existsAsFile())))
	{
		ComponentDeletionWatcher deletionWatcher (this);
		for (int i = listeners.size(); --i >= 0;)
		{
			((FileBrowserListener*) listeners.getUnchecked (i))->selectionChanged();
			if (deletionWatcher.hasBeenDeleted()) return;
			i = jmin (i, listeners.size() - 1);
		}
	}
}

Ideally I’d change this code so that the choose button disables as well for loadFileMode if the text is not a valid file. Currently ocne it enables, it stays enabled. The list select handler should also clear the text box when a directory is clicked (and cause a corresponding disable button event). I’l l take a look at that after lunch.

The dialog box performance now seems to be what I’d expect on all machines I’ve tested on, so I guess it was the root building that was taking so long. Odd that the floppy drive never grunted though.

8

hmm - not sure about your change, because it won’t send a change message when you alter the text from a real file to a non-existent one. Probably better to lose the ‘if’ statement altogether and just do:

void FileBrowserComponent::textEditorTextChanged (TextEditor&) { ComponentDeletionWatcher deletionWatcher (this); for (int i = listeners.size(); --i >= 0;) { ((FileBrowserListener*) listeners.getUnchecked (i))->selectionChanged(); if (deletionWatcher.hasBeenDeleted()) return; i = jmin (i, listeners.size() - 1); } }

9

hmm - selectionChanged() seemed to be always setting the button enabled, which is why I threw in the exists()

I might have been missing something though.

10

Seems to work ok for me - the button gets enabled/disabled correctly as you type.