@aram depending on your needs, you may be quite restricted in what you can achieve with the Projucer layout tools. If you want to do anything of complexity you should develop your skill set in manual layout… or, use more powerful like Plugin Gui Magic
I didn’t mean to imply that manual is better than a WYSIWYG editor, only that the Projucer editor is old and crufty, without much new work having gone into for a while. At one point (not sure if this is still the case, it was considered deprecated) I would hate for you to get frustrated trying to do creative things that the editor can’t do for you. although, a quick search does how there are people who are happy with it, so my comments are likely biased by my own preference. And I am sure someone who is using it could answer your actual question. Are you also learning C++ while you learn JUCE?
Dereferencing the unique pointer should not be the reason for that. I suspect that the order of destruction is what could be problematic here, if you declare your attachment as a member before the slider itself or if you explicitly reset the slider member before destructing the attachment this can lead to an attachment calling a slider it references to that no longer exists. To make things easier, I created a helper class template for my projects that groups a widget with the matching attachment (the matching attachment type is selected automatically through std::enable_if) so that you can just write e.g.
This makes sure that the destruction order is always right. You can find it here:
However, this is not exactly matching the auto generated gui editor code. But as others said above, I’d advise you to try to avoid it as it is not supported anymore and is quite unflexible. Building GUIs from code is much more powerful at least with the current state of JUCE and what most pro users I know do. If you use JUCE_LIVE_CONSTANT polled in a timer to set sizes and positions it’s not so hard to tweak parts of the GUI at runtime
One of the GUI Editor generated limitations is that there is only a limited number of locations things can be written (ie, the bracketed code is before the auto generated code etc) and makes it harder to play around the orders. As you mentioned, some listeners are being destroyed before the attachments are done with them.
I think I’ll take another direction that still may be good enough:
Use gui and generated code
Move the generated code to bracketed area
Delete gui that removes the original code
Change the content as needed.
I might also look into a Xaml to Code I wrote a while back or something similar to help make the boilerplate parts faster.
By the way I noticed you have a Preset Manager in that github, I hope you don’t mind me looking around that as I noticed that’s another thing missing from the Juce framework.
Sure, look around as much as you want and use everything you find there according to the licenses the individual projects are released under if you want to
If you are interested in the preset manager, you might also want to check out my PluginAudioProcessorBase class that avoids a lot of boilerplate code for my products, by setting up an AudioProcessor along with the preset manager and an apvts and overrides several member functions in a senseful way… example usage of all this can be found here https://github.com/JanosGit/Schrammel_OJD/tree/develop