Hey @mikeudin,

Thank you for reaching out to us. In short, there is no good answer to your question.

There is no guarantee that anything will ever run on the main thread. You must always check yourself with c4d.threading.GeIsMainThread. Scene computations, e.g., ObjectData.GetContour is run in parallel off-main-thread and is therefore subject to access restriction to avoid access violations, i.e., crashes. There is no "hack" for this. The essence is that you cannot have both the benefits of sequentialism (can use shared resources) and parallelism (is fast). There are of course data structures which allow you to handle a singular resource from multiple threads, but doing this always entails lining up multiple users in a line, each waiting for users ahead in the line to be done, i.e., hidden sequentialism. In Python this might be hard to grasp because Python itself mostly ignores the concept of parallelism and we only experience here the side effects of the parallelism of the underlying C++ Cinema 4D API.

There is also the problem that your request does not make too much sense for me on a practical level. Imagine having a plugin MySpline which opens an error dialog once its GetContour method strays from the right path.

A user now edits one hundred instances of MySpline at once and triggers the error. Cinema 4D sometimes executes passes two or three times in a row to resolve dependency problems. This would then mean that you would open three hundred error dialogs for one user interaction (if that would be technically possible in the first place).

In general, no node should open any form of dialogs on its own. Opening a dialog after a button press in the description of a node via NodeData.Message is okay.

When you are hell-bent on doing this, you could do this:

Add a field to your plugin, e.g., self._error: str = "". When you are in your GetContour and an error happens, instead of raising it, simply write it to _error. Implement any NodeData method which often runs on the main thread. NodeData.Message is a good candidate. On each execution of it, check if _error has content and if you are on the main thread. If so, display the message and then null _error. You will still need some kind of throttling so that the user is not spammed with the same error over and over again. I.e., you need an "only-new-errors" mechanism. It is up to you to implement that.

An alternative approach could go via core messages. But that is also non-ideal because setting off a c4d.SpecialEventAdd will work from a non main thread but will cause the global core message lock to engage, which is of course a bad thing to happen and exactly the "no-hack" problem I described under (4).

You could also try using c4d.StatusSetText and the other status functions. While not officially supported, they will work from non-main-thread environments. But there is no guarantee and we do not officially support this.
Cheers,
Ferdinand

Add tooltip to subcommand