Using object->Message()

Helper

On 31/03/2017 at 07:42, xxxxxxxx wrote:

Ok, that is clear.
But what if I want to send information about an object to the other plugin?
SpecialEventAdd() is limited to 2 integers.

For the SendCoreMessage I tried following code, but I receive nothing in CoreMessage of GeDialog.

In plugin 1 - send the SendCoreMessage()

BaseContainer data;
data.SetLink(100101, oActive);			//set object information in container
SendCoreMessage(105645834, data);		//send message
...

In plugin 2

Bool MainDialog::CoreMessage(Int32 id,const BaseContainer &msg)
{
	if (id == 105645834) {                              //message from PlaceOnObject
		GePrint("ok corecommand");
	}
	...

Helper

On 31/03/2017 at 07:50, xxxxxxxx wrote:

Actually I wouldn't say SpecialEventAdd() is limited to two integers. Actually it's two UInt parameters, enough space to pass two pointers (simply cast them to UInt and cast back on reception). But be careful though, you have to make sure the memory pointed to still exists, when the message is received. So please don't send a pointer to some local variable, that's bound to fail. Rather have a global variable or even some queue accessible from both ends (depending on your needs).

Helper

On 31/03/2017 at 08:18, xxxxxxxx wrote:

Could you give a quick example of a global variable?

I am doing this, but it does not work:

In a header file
extern Int32 externalX;

But then the linker complains Not defined?

Using in the header file:
static Int32 externalX;

But then the value is always 0.

Helper

On 31/03/2017 at 08:21, xxxxxxxx wrote:

With an "extern" declaration, you tell the compiler not to create the variable, but to wait for the variable to be provided by another object file (so the linker will resolve the symbol). Just declare it without extern. If you want to access this variable from another file, then have it declared "extern" there.

Helper

On 31/03/2017 at 08:52, xxxxxxxx wrote:

It keeps telling me unresolved or already defined.
This is my set-up

header file with Int32 externalX;

cpp file with the code for plugin1 and plugin 2.
plugin 1: externalX = 121

plugin 2: extern Int32 externalX;
GePrint("ok corecommand" + String::IntToString(externalX));

It keeps telling already defined?
Error 14 error LNK1169: one or more multiply defined symbols found

Helper

On 31/03/2017 at 09:28, xxxxxxxx wrote:

I tried SpecialEventAdd(), but I cannot get the p2 value correctly.

//send the message
// oActive is a BaseObject*
SpecialEventAdd(PLUGIN_ID_MAIN, PLUGIN_ID_MAIN, (UInt)oActive);  
...

//receive the message in CoreMessage cast from UInt back to BaseObject*
Bool MainDialog::CoreMessage(Int32 id,const BaseContainer &msg)
{
  
	if (id == PLUGIN_ID_MAIN) {                              //message from PlaceOnObject
	   GePrint("ok corecommand");		
	   UInt p2 = msg.GetUInt32(BFM_CORE_PAR2);	//Cinema crashes here!
	   BaseObject* nw = (BaseObject* )p2;
	   ....

How to get the pointer to the object?

Helper

On 31/03/2017 at 09:37, xxxxxxxx wrote:

  
      Data* data;  
      UInt par1 = (UInt)msg.GetVoid(BFM_CORE_PAR1);  
      UInt par2 = (UInt)msg.GetVoid(BFM_CORE_PAR2);  
      // I use par1 to identify what is passed,  
      // par2 contains the data  
      if (par1 == something)  
              data = (Data* )par2;  
      else if (par1 == somethingelse)  
              data = nullptr;

Keep in mind that the message is asynchronous. There can be quite some time between the message being sent by one plugin and actually received by the other.
It is thus possible that when deleting the memory allocation in the sending plugin, the receiving plugin has not yet been triggered. When it does, and it tries to process the obtained pointer, due to the memory already being unallocated this will result in your plugin crashing .

Helper

On 01/04/2017 at 04:44, xxxxxxxx wrote:

Great, thank you!

Helper

On 03/04/2017 at 02:43, xxxxxxxx wrote:

And what if I want to pass on a structure like this?

struct MyStruct
{
   Int32	index;
   BaseObject* objectLink;
};

Helper

On 03/04/2017 at 05:28, xxxxxxxx wrote:

Instantiate the struct (just as you would a class or a POD), and pass the pointer ?

Helper

On 03/04/2017 at 11:03, xxxxxxxx wrote:

@Pim: Regarding the declaration of a global variable. Even if you don't need it anymore, we should quickly get this right. The correct place to declare a global variable is in one of your .cpp files (and there without extern). When this file gets compiled, the global variable "gets created/allocated (well not really, but for now)" in the resulting object file. In your header you will declare the global variable "extern", so every other cpp file including the header, will not "create" the global variable again, but will know, it has to wait for the global variable coming from another object file. By directly (without extern) declaring the global variable in the header (and I know, I'm responsible for this, because I didn't take time to explain in detail), the global variable will be "created" in every object file, where the source cpp file includes the header. And then the linker will say "uh... oh... already defined" as it won't know, which of the global variables is actually to be used.
So, short summary to define a global Int32 variable you'd like to access in two different .cpp files:

// In sourceA.h:
extern Int32 walter; // Here we just tell the compiler not to try to resolve symbol walter in the currently compiling source/object, but to wait for the linker to resolve it later
  
// In sourceA.cpp:
#include "sourceA.h"
  
Int32 walter;  // Here the global variable is actually created and it will take up some space in sourceA.o
  
void funcA()
{
	if (walter == 0)
		return;
	return;
}
  
// In sourceB.cpp
#include "sourceA.h"
  
void funcB()
{
	if (walter == 0)
		return;
	return;
}

For the struct question, well either you have that structure globally or you allocate the struct and store a pointer to it globally (by globally I mean not necessarily global in the sense of the word, but accessible from both classes). When allocating the struct, don't forget to free it on the receiver side and make sure you do not overwrite the pointer before it got received, otherwise you'll end up with a memory leak.

Helper

On 03/04/2017 at 11:40, xxxxxxxx wrote:

Thanks for all the input and clarifications.
Everything is working now and I understand what I did wrong and why it is now working (global variables and struct).

To be sure.
Is this the best way to initialize a struct?

		MyStruct* myStruct;
		myStruct = NewMemClear(MyStruct, 1);
		myStruct->index = 16;
		myStruct->objectLink = surface_obj;

Helper

On 04/04/2017 at 03:04, xxxxxxxx wrote:

Yes, though a nullptr check would be appropriate and you should make sure the object is deleted on the receiving end.

I haven't used SpecialEventAdd() this way myself. @Andreas
is it garuanteed that every message sent will actually be dispatched
at some point? Because if it is, say, a queue that swallows events
of the same ID, it's not garuanteed.

Helper

On 04/04/2017 at 05:02, xxxxxxxx wrote:

Valid point, Niklas. I checked the code.
With SpecialEventAdd() identical events (same messageid and identical parameters p1 and p2) do not get queued, but this shouldn't be a problem in this case. More problematic could be, that events get thrown away, if the event system is overloaded. But I have never seen this under real life conditions.

Helper

On 04/04/2017 at 07:18, xxxxxxxx wrote:

Hi,

What is the benefit of using: myStruct = NewMemClear(MyStruct, 1);
Opposed to using something more standard looking like this: myStruct = NewObj(MyStruct);

-ScottA

Helper

On 05/04/2017 at 06:00, xxxxxxxx wrote:

@ScottA: I used NewMemClear(), because NewObj() sounded to me more appropriate for objects and not for structures,but - after reading your question - I am not sure anymore.
Let's see what the experts say.

@NiklasR: "and you should make sure the object is deleted on the receiving end."
Is DeleteMem(myStruct) sufficient?

Helper

On 05/04/2017 at 10:12, xxxxxxxx wrote:

@Scott: Well, I wouldn't say there's an advantage. I agree, in general NewObj() is probably preferable, as it can call the constructor for the allocated type. NewMem() on the other hand is mostly used to allocate raw memory (as the docs state) without calling any constructor.

@Pim: Yes, DeleteMem() would be sufficient. Saying this will all due caution, assuming you do it correctly (just don't blame me, if you call DeleteMem() in the same thread where you allocated the memory right after sending the message. Which I'd regard a wrong usage, as you'd delete the memory before receiving it in the other thread).