PluginMessage and pycobject [SOLVED]

On 15/10/2014 at 00:59, xxxxxxxx wrote:

Ok, I'm glad to do something in return.

On 15/10/2014 at 07:52, xxxxxxxx wrote:

The code only handle integer > 0.
When the value received was 0, it gave an error (perhaps because 0 = Null pointer?).
Here some code to handle positive and negative integers and 0 itself.
I still do not know how to send strings, because SpecialEventAdd requires two intergers P1 and P2

            # c_int: Handle integer value negative and positive
            P2MSG_UN = msg.GetVoid(c4d.BFM_CORE_PAR2)
            pythonapi.PyCObject_AsVoidPtr.restype = c_int             #was c_void_p
            pythonapi.PyCObject_AsVoidPtr.argtypes = [py_object]
            try:    #handle value of 0
                P2MSG_EN = pythonapi.PyCObject_AsVoidPtr(P2MSG_UN)
            except TypeError:
                P2MSG_EN = 0

Note: Who put [solved] in the Post header?

On 15/10/2014 at 08:02, xxxxxxxx wrote:

Sorry, I thought this was solved. I will remove the "Solved".

Best wishes,

On 16/10/2014 at 07:31, xxxxxxxx wrote:


there may be a way to avoid any handling of a "PyCObject" object. You can set a value in Cinema's WorldContainer and then send your message. When your target objects catch that message they find the proper values again in the WorldContainer:

Sending the message:

      worldContainer = c4d.GetWorldContainerInstance()  
      worldContainer.SetString(1000100,"This is just some string!")  
      c4d.GePluginMessage(1000101, 0)  

Receiving the message:

def PluginMessage(id, data) :  
  if id==1000101:  
      worldContainer = c4d.GetWorldContainerInstance()  
      print("message received: "+worldContainer.GetString(1000100))  
      return True  
  return False  

best wishes,

On 16/10/2014 at 08:08, xxxxxxxx wrote:

Great, I'll give it a test.
I also see that in R16 you have now the Cast function.
Perhaps we can use it to cast PyCObject - CType.

On 16/10/2014 at 09:18, xxxxxxxx wrote:

*Please don't tell people to put things in the World Container!!!!!!!!
That will store data in there permanently!!
I do not want plugin makers adding things to my WC without my permission!!

This is a bad, bad, bad, practice.
The WC should only be used to add preference options that will get deleted when the plugin is removed.

Is that forceful enough? Should I use bigger letters?
Please guys. Don't do it...just don't.
Think about what would happen if everyone dumps stuff into your WC.
Your WC will become so full of crap that you don't even know is in there.

Does anyone know if there's a way I can lock my WC. To prevent people from adding stuff to it that I don't want?


On 16/10/2014 at 12:10, xxxxxxxx wrote:

It's just preferences that are stored in the WC. You do want preferencs of your installed plugins to be saved, don't you? It's true that the stored data won't be deleted if the plugin is and there could be a better system, but it's not like you store tremendous amount of data in it.

On 16/10/2014 at 13:49, xxxxxxxx wrote:

It's fine to store preferences data in there. As long as it shows up in the preferences pallet.
That way we can at least visually see that someone added something to it. But it should stop there and go no further.
Anyone that puts preference data in there MUST have a remove mechanism in place to remove that data when the plugin is removed.
And you just know that people will either forget this...or do it wrong. And the data will sit there forever.

If people start using this as a quick and dirty way to store data by creating custom containers with data in there. Then this quickly turns into a garbage dump on my computer.
Eventually people will use the same container ID's as another person. And then there will be bugs and crashing. And people won't know why.

This is just a really, really, bad idea all around. And it should not be used or promoted.
Dumping hidden permanent data on someone's computer is never ever acceptable! EVER!!!


On 17/10/2014 at 07:12, xxxxxxxx wrote:


Indeed, the above idea has potential risks and should only be applied when absolutely necessary. An unique ID must be used to avoid a collision.

The suggested solution is a workaround because we haven't thought of anything better. While it is a workaround, it is a solution for a feature that is currently missing. There is no such rule, that you are not allowed to store into the world container. Anybody with a viable reason, may do so, as long as a valid registered ID is used to store the data.

To make sure that the WorldContainer is "clean" after your operation you may use RemoveData().

best wishes,

On 17/10/2014 at 07:58, xxxxxxxx wrote:

Thank you for backing me up on this Sebastian.