Sure, you can enforce a destruction order, but actually this defeats the purpose of using unique_ptr in the first place. Todays best practice is not to use unique_ptr at all but make the Slider a plain member of the parent class (unless the Slider is optional, in which case you need to use unique_ptr or std::optional).
So it seems the crash is a different one from the destruction order, fair enough.
unique_ptr is not reference counted. It is owned in one place, but that’s just a side note. It is destroyed once the unique_ptr goes out of scope, or if it is explicitly set to a different pointee or nullptr. But the default use case is to let it go out of scope.
No particular reason! This must have been left over from when I actually use projucer gui editor. I’ll give that a try.
The only issue though I’m certain only resgresses is when using a combo box. The component then becomes the sole interacter if keyboard. May be there is a way for me to disable that. Even when not interacting with the combo box itself but anything else in the component I still get the same input issue.
Now onto figuring out why combo boxes require full component input consumption. I verified that it has nothing to do with valuetree attachments but the combobo component itself.
A jassert is not a crash. It is a conditional breakpoint to give the developer a heads up of a condition that was not expected. Most likely a crash could follow if the code would continue. But the jassert in the debugger shows you what to fix.
The jassert tells you the index is outside the valid bounds of the array.