GePluginMessage

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/11/2004 at 02:51, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   8.207 
Platform:   Windows  ;   
Language(s) :     C++  ;

---------
Some messages are function calls, for example if I sent a message directly to an object, some are scheduled, like core messages.
What about GePluginMessage? Is it a direct call, or a scheduled message? So, if I do a GePluginMessage from one plugin, can I be sure that the according code in the destination plugin will be called after that line of code?

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/11/2004 at 07:10, xxxxxxxx wrote:

Yes, of course. It´s not possible to catch a message if it wasn´t send (logical) so it´s impossible to let the code be evaluated before, if it requires the data container of the pluginmessage. Of course, you need to check for this, otherwise another plugin may have send any data and your plugin thinks it´s his own.

But that´s what the plugin ID is good for.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 24/11/2004 at 07:27, xxxxxxxx wrote:

The question is, if the message is synchronous or asynchronous! The reaction on the message will of course be done after I sent the message, the only question is when! In my case, the other plugin I notify with GePluginMessage will do some important things to my plugin. If the message is synchronous, then the modification will be finished after I leave the GePluginMessage function. If its asynchronous, then the modification will "soon" be done...in that case the other plugin will have to notify after the modification has done.

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 01/12/2004 at 02:38, xxxxxxxx wrote:

Afaik none of the messaging functions are guaranteed to be synchronous, even if they would happen to be now. So I would go the more robust route of designing for asynchronity.