How is the Plugin ID parameter used by GeDialogs?

ferdinand

Dear community,

this question has been forked from Cinema 4D locks up, when opening dialog from MessageData.CoreMessage. The author of the question has been @a_block.

This may already be considered off topic, let me know, if I should open a separate thread. Could you provide a bit more info on how the Plugin ID parameter is used by GeDialogs? I mean, the golden rule seems to be, when you open a GeDialog from a CommandData, the CommandData's plugin ID gets passed here. Fine. But what if not? If a GeDialog gets opened from another GeDialog? Or like in my case from a MessageData? Is passing zero ok? Is passing a unique plugin ID, registered only for this purpose ok, even if it is not related to a registered CommandData? One thing C4D seems to use the ID for is to store size information. Which can already be a bit annoying, if like in my case, this dialog is used as a requester with varying content, because once it was opened with some more content, it will remain large, even when displaying less content later on. But ok, that's just cosmetic (though I was thinking to register a bunch of plugin IDs to mitigate this issue). But I could imagine the plugin ID to be used for more serious stuff as well. Like managing contexts or event loops. So long text, short question, can I do harm with this plugin ID?

Cheers,
Ferdinand

ferdinand

Hello @a_block,

thank you for your question. To clear a few things up for me (and possible future readers). When you talk about Plugin ID, I would assume that you mean the argument pluginid passed to GeDialog.Open and GeDialog.Restore, right?

So, you are probably aware of this, but other readers might be not, GeDialog is only the public facing front end of Cinema 4D's dialog GUI. There are other types involved in the back end, but what is happening when you call GeDialog.Open(), is:

Cinema 4D chains the call down through to its core and there will be a gadget created - the dialog we wanted to open.
The argument pluginid we did pass will be a field attached to the gadget.
That id field is used in many ways, and you passing in zero, i.e., sort of undefined, is handled by Cinema 4D. The id is most importantly used to find a sub-dialog in the dialog hierarchy of a dialog (dialogs can act as trees of dialogs in Cinema).

Noteworthy seems:

The argument pluginid is only required from a user perspective to restore dialogs. All other cases where Cinema uses the id attached to the internal type, handling dialog focus, dialog data and more, seem to be handled in a way that does not require the user setting a specific id.
What you pass into GeDialog.Open and GeDialog.Restore as pluginid does not seem to matter if you can guarantee that it will be collision free (in the sense that no other gadget uses the id to identify itself). Which requires the user to use a plugin id provided by Plugin Café, since this is the only curated id namespace in the classic API. The namespace is big, and we have only used up a small fraction of it, so registering a separate id would not be a big issue. But if you have a CommandData plugin, and it only has one dialog associated with it, the ComandData plugin id could be used to identify/restore the dialog. I have not found any code where a CommandData instance would assume that there exists a dialog gadget with the id of the CommandData.

Since this is related to the other topic: You could try to make the id for the second dialog specific, but I doubt that this will change much (I have not tried though), since Cinema handles the case of pluginid == 0. I hope this clarifies things.

PS: That I wrote seems in some case was intentional, since the underbelly in Cinema 4D has gotten quite complex and making absolute states can be hard sometimes.

Cheers,
Ferdinand

a_block

Hello Ferdinand,

yes, I was talking about the plugin ID argument of GeDialog.Open() and Restore().

Thanks for your explanation.

I'm completely fine with your answer, despite some seeming here and there. I do understand the problems a codebase grown over decades can cause for answering such questions definitely. Nevertheless your explanations largely sync with my expectations from quite a few experiments.

Regarding the mentioned issue of the other thread, I can acknowledge, the plugin ID parameter did not seem to have influence on the issue in my experiments. This question here was really more targeted the sizing issues I have with requesters of varying content. And your answer provides me with some confidence, I can make use of different plugin IDs (I should probably rather say unique IDs from Plugin Café) even if they are not related to any registered plugins at all. While I had already thought so and did not find any issues with this practice, it's always a bit hard to know for sure from the outside. And there's always this feeling one could be doing something harmful, which will only bite at the worst possible point in future.

Thanks for the clarification.

Cheers,
Andreas