I’m trying to write a patch-browser, where I came across this problem:
I figured it would be cleanest if I made each entry (“my-patch.xyz”) a component and store these in a vector. That would of course mean that I have to create and delete them on the fly.
I tried to implement this, but was hindered by the
JUCE_DECLARE_NON_COPYABLE_WITH_LEAK_DETECTOR(BrowserEntry)
which deletes the copy constructor. And sure enough: removing the macro in the class shows that juce::Component
has a deleted copy constructor as well, so no vectors…
What’s the best way to solve this situation? I could go without making the entries actual components, but I’d have to do without all the handy mouseEvents that are provided by juce::Component
You need to use a container that just holds std::unique
pointers to your components. This makes sure that the component itself is not copied/moved but only the pointer to it, which is no problem. A convenient juce class for this task is OwnedArray
, but a std::vector<std::unique_ptr<Component>>
should do as well.
2 Likes
It would probably be easiest to use a juce::ListBox
. It manages the Components lifecycle and will only create components for the ones that are currently on the screen.
Otherwise use a OwnedArray<Component>
or std::vector<std::unique_ptr<Component>>
.
1 Like
Cool, thanks to both of you. I’ll try the vector of unique_ptrs. The ListBox
looks intriguing (and its derivative juce::FileListComponent
is probably exacly what I’m trying to achieve here), but where’s the fun if JUCE does all the work