FileBrowserComponent derived from FileFilter bug

when deriving FileBrowserComponent (into, say, DerivedFBC) one can't pass FileFilter* to the derived ctor because it conflicts with the existing FileFilter that's mixed-in the base FileBrowserComponent so it looks like a DerivedFCB can only be ctored with a null filter on which you'd call DerivedFBC::setFileFilter() post-ctor.

It's a bit of a corner case but it'd probably be better to make FilerFilter a member var and rewire the virtual isFile/DirectorySuitable() functions to it.

My 2 cents.


-- p

Yes, to be honest it would be better for us to fully hide those base classes - I'll clean that up. But on the other hand I'd also recommend not using the component object as your FileFilter even if it was possible.

I'm not using that component as the (direct) filter, I'm assigning another filter that's allocated & stored upstream but yeah hiding all those classes would help. Too many mix-in classes make using 'auto' variables dangerous.

thx for listening.

-- p

different kind of issue: because FileBrowserComponent derives from both TreeView and DirectoryContentsDisplayComponent, each of which have their own selected background color ID, the resulting background color is actually a composite of the two. It was a bitch to figure out, f.ex. setColour(TreeView::selectedItemBackgroundColour, Colours::white) will show a purple-tinted row.

Dunno what solution to recommend since TreeView can be used without File/DirBrowsers and vice-versa, it's only an issue when both are mixed.

Also how do you get a file browser with h-scrolling? Fiddling with the Viewport doesn't seem to work, even after overriding the hardcoded 450-pix width in LookNFeel_v2.


-- p