Communication between DescriptionTool and GeUserArea

Hi,
Not sure if this topic fits this particular part of the forum. It might be better suited in the "Cinema 4D Development" subforum, but as it handles a more general question, I assumed it would be OK to post it here instead. Open for anyone to discuss.

I'd like to refer to this topic, which was used for reporting a bug in R21. It contains code example of a plugin using a DescriptionToolData and a GeUserArea.
The idea was to use a DescriptionToolData to hover over polygons in the 3D Viewport, and to display an alternative view into a GeUserArea.
For purpose of reporting the bug I simply provided code to display a flat projection of the object and the hovered over polygon into the GeUserArea. (didn't come up with simpler code to demonstrate the issue).

Now, in this example I am using global variables to pass on information between DescriptionToolData and GeUserArea. This works, but isn't quite elegant.
As such, I was wondering if there was any other way of communicating between 2 plugins (being part of the same binary). I know about sending messages by means of SpecialEventAdd, Message, SendMessage, SendCoreMessage, ... But I am more looking into a "synchronous" solution (if that makes sense).

Additionally, when handling multiple plugins (be it ToolDatas, GeDialogs, CommandDatas, GeUserAreas, etc ...) I haven't found a better way than to use one singleton class which is available as a global variable to all plugins (in that same binary), in order to synchronize and share data between them.

It would be nice to discuss this topic with others (MAXON SDK support people and/or other 3rd party developers in the community).
For now, I am interested in the classic API only, since I am trying to be backwards compatible as far as R16.
But don't let this prevent discussing the new maxon API solutions.

Thanks,
Daniel

Hi Daniel, thanks for reaching out us.

In my personal development experience I made use of your same approach in some cases and have never ended, maybe by chance, in troubles. That said, it should be noted that's indeed a critical topic cause global variables (especially when used to point to instances of complex class) can be hard to manage in a multi-threaded environment where thread safety should be carefully considered.

Looking forward to other opinions from our Community, the above consideration should be meant as derived from personal experience since as reported in Maxon's Programming Advices it's highly discouraged to use global static classes of complex types.

Best, Riccardo

My thoughts on this: as always, this is a question on software design and the correct level of abstraction. The question is not how do different plugins communicate with each other, but how do different parts of a software communicate with each other. And how is software structured to make that communication efficient and clear.

The typical modern approaches are patterns like Model-View-Controller or Model-View-Presenter.

In such models, you don't "send data around". Your UI updates the model. And an update of the model triggers an update or (other parts of the) UI.

So in your example, the interaction with the DescriptionToolData would write data into the model. And the GeUserArea would read that data from the model. The only question is how you trigger that update process; and that depends on what exactly you are doing in what cases Cinema allows to update the UI.

best wishes,
Sebastian

@s_bach said in Communication between DescriptionTool and GeUserArea:

The typical modern approaches are patterns like Model-View-Controller or Model-View-Presenter.

In such models, you don't "send data around".

Thanks for mentioning this.
As stated in my opening post, this is what I have been using, where the "model" is a singleton class, available as a global variable to all plugins to synchronize and share data. Maybe not quite the exact wording.
I was just wondering if there is another means of providing this "model" instead of using an instanced (singleton) class via a global variable?

So in your example, the interaction with the DescriptionToolData would write data into the model. And the GeUserArea would read that data from the model.

The example I provided isn't making use of a "model" as it already represented too much code just to point out the bug that slipped into R21. There I indeed used a very simplified solution by "sending data around".

But an overall "thank you" for bringing up the model-view discussion, as this made me realize I could use an observer pattern in another project of mine which would fix its current poorly chosen design.

Daniel