thanks for the advice. Still it does not clarify anything. It just puts the blame on me. Not helpful…
If I am not to use pointers, how do I get changes in a child component up to the parent?
Especially, when I have components containing components containg components and so on? What is best practice here?
What is the best practice for synchronizing the processor and the editor?
And if its for my lack of skills, how would you actually do a forward declaration for another class in a header only implementation?
I might not be the best programmer around (I am also a bit rusty in C++) but putting the blame on my C++ knowledge without clarifying anything is a bit lame…
I only came to the idea of using pointers because there was no best practice
I only came to the conclusion to not use header only implementation because I see no way of a forward declaration with a single header file per class
I accept that this is your software and if you are not ok with my answer you might throw me out of your forums but I needed to get this off my chest.
You seem to be taking my answer as a personal criticism, but it’s not! It’s great to have threads like this where people thrash out their understanding of a problem, but since you concluded it with two pieces of advice that you called “best-practice”, I just wanted to make sure other beginners reading it don’t get mislead!
Sure, could be that the answer is indeed to just use a pointer or reference and call a method.
But usually when people ask this kind of question, the correct answer is “you’re doing it all wrong!”. Generally if you find yourself wanting to send a lot of messages around between UI components to tell each other about changes, then it’s a code-smell that the architecture is all wrong… The ideal approach is to end up with a data model that’s entirely separate from the UI, and then your UI components listen to the data model, and not to each other.
I was not taking the fact personal that you mentioned my (lack of) skill, which for 100% is the reason for me not getting it to work
But thats the only part I already knew The fact that that was the only information provided triggered me. Sorry for me going off, but I am a very direct person
May I kindly ask for you to point me on a piece of documentation making the concepts clear ? I am having a hard time understanding how to get the UI and the processor to exchange data without using a timer.
I also have a nested archtecture of components, which is:
Sequence
contains Patterns
contains steps
is that wrong or at least no good? How should I do it then ?
my data model is a linked list of Patterns (the Sequnence) consisting of a linked list of steps and it is seperate from the components, but I still need to modify data in response to user interaction, how would I do that?
Sorry, but I’ve no idea what that kind of documentation would be! This kind of thing isn’t stuff that you learn from a book, it’s just general principles you pick up through experience… Maybe others know of some useful resources, but I don’t really keep any links to stuff like this.
I am not a C++ expert, but a newcomer who is facing some of the same frustrations as you. I have not followed the ins and outs of this conversation, but my experience may nevertheless be helpful, as I have been struggling with basic architecture for several weeks and finally found a solution that works.
First, if you’re not already familiar with them, I recommend reading up on some basic architecture paradigms like Model View Presenter. I am also building a sequencer, and it really helped me to think of my system in three different parts: the core system (model), the GUI (view), and a third component (presenter) which owns the other two and controls them.
Even with this understanding, I really struggled with how to get one component to communicate with another, just as you described, and with the circular dependencies that tend to crop up. The solution I came up with was the following:
The Presenter inherits from a base class (let’s call it Control).
Every sub-component in the Model and the View takes a constant pointer to the Presenter (Control* const presenter) through its constructor and sets it as a private member variable.
The Control class specifies virtual function prototypes for any methods that need to access members of the Model or the View.
The Presenter itself overrides these virtual functions and accesses the Model and the View through their own public member functions, as needed.
You can then access these functions from any Model or View component by calling ie. presenter->model.someFunction().
This method should be kept to a minimum, for the reasons that Jules specified. You can also probably refine it by making functions private and then granting access only where needed through friendship.
As I say, I am not an experienced C++ programmer, and there may be problems or objections to this method that other people will see. If so, I would be very interested to hear them.
As for the discussion about basic C++ skills, I am finding JUCE to be a great gateway into learning more about C++. It’s intensely frustrating at times, but that’s the nature of learning. I am personally learning a lot faster by trying, failing, and trying again, than I do from reading books and tutorials. The people on this forum have been extremely helpful too!
