FileBrowserComponent derived from FileFilter bug


#1

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.

cheers,

-- p


#2

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.


#3

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


#4

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.

thx!

-- p