Subapp Communication in an Extension

Dines · February 14, 2012 at 12:49 PM

Hi all,

I'm working on an extension that's supposed to live both inside a subapp and outside it (in the parent frame). I know that subapps share the same address space as their parents, so if I can just pass a pointer from the parent extension object to the child extension object, then they can share data. My problem is how to share that data.

I don't want to have to force the user to store an address manually across a global value because that's clumsy, so what would you recommend for transferring a pointer?

It feels like overkill to use Named Shared Memory to communicate within the same process. Additionally, are subapps in their own thread, or does their code get stuck onto the end of the current event list like behaviours do?

EDIT: Was REALLY not expecting that! Turns out I can just use an extern variable. W00t! I can't find where to delete this thread, but someone can if they want.

Phi · February 14, 2012 at 4:56 PM

I hope you're not duplicating the functionality of Global Function Object, Global Store X, Instance Communicator, etc. Just warning you before you spend more time on it
What's the purpose of your extension? I wrote a list describing all the extensions' functions, so I should be able to know if you're duplicating one.

Dines · February 14, 2012 at 6:14 PM

I'm building an extension for my own purposes, but I figured I'd share it - so it's functionality will overlap a bit with other sharing objects, but the main thing is that it works in exactly the way I'd like it to

You put a copy of it in your subapp and a copy of it in your parent, make sure the two objects share the same name, and they'll have access to the same set of named strings and ints.

LB · February 18, 2012 at 1:17 AM

Quote from Dines

EDIT: Was REALLY not expecting that! Turns out I can just use an extern variable. W00t! I can't find where to delete this thread, but someone can if they want.

No! Don't do that!! Use MMF2's built-in support for global data.

Quote from MMF2 SDK Help

mvSetExtUserData
LPVOID (CALLBACK * mvSetExtUserData) (CRunApp* pApp, HINSTANCE hInst, LPVOID pData)
Store global data for this extension into the application.
Parameters
CRunApp* pApp application
HINSTANCE hInst HINSTANCE of your extension object
LPVOID pData data to store

Return value
Previous value..

Comments
The mvGetExtUserData and mvSetExtUserData functions allow you to store data global to the application. For example you can store the data with mvSetExtUserData in the DestroyRunObject function (instead of deleting it) and retrieve it with mvGetExtUserData in the CreateRunObject function. You have to free any data stored with mvSetExtUserData in the EndApp function (and also in the StartApp function to reinitialize the data when the application is restarted).

Display More

Quote from MMF2 SDK Help

mvGetExtUserData
LPVOID (CALLBACK * mvGetExtUserData) (CRunApp* pApp, HINSTANCE hInst)
Returns the extension global data attached to the application.
Parameters
CRunApp* pApp application
HINSTANCE hInst HINSTANCE of your extension object

Return value
Value that you have stored with mvSetExtUserData. NULL if mvSetExtUserData was never called by this extension for this application.

Comments
The mvGetExtUserData and mvSetExtUserData functions allow you to store data global to the application. For example you can store the data with mvSetExtUserData in the DestroyRunObject function (instead of deleting it) and retrieve it with mvGetExtUserData in the CreateRunObject function. You have to free any data stored with mvSetExtUserData in the EndApp function (and also in the StartApp function to reinitialize the data when the application is restarted).

Display More

If you don't, weird and even bad things can happen. MMF2 uses your extension in many ways you would not expect...

Dines · February 20, 2012 at 12:51 PM

Thanks for that, I had a feeling I'd seen a built-in way to share data globally, but couldn't find it anywhere. Thanks for sharing!

Dines · March 6, 2012 at 9:52 PM

Just quickly - could you elaborate on what kind of bad stuff can happen if I go down the extern route?

Currently, I have a global pointer to an object, which is null by default. On Initialize(), the object is instantiated if the pointer is null, and if not, the pointed object's int Users property is incremented to show there's now another Initialize()...Free() pair dealing with the object. Then on Free() the opposite occurs, decrementing Users until empty, at which point the instance is deleted.

I know Initialize() and Free() are called several times - so for instance, it'll initialise and free during the MMF splash screen, and also initialise when an mfa containing the object is opened (and free up when it's closed), but this is fairly controlled as the object it creates and manages is just a collection - it contains a vector of further objects that get created through Runtime's CreateObject() and DestroyObject() functions, so any Edittime Initialize()...Free() calls will just create and destroy an empty shell.

So does that sound like it should be robust enough to avoid problems?

LB · March 6, 2012 at 10:40 PM

If you only need this communication at runtime it is not worth all of the trouble you have gone through to do this. The feature is built in to MMF2 and you should use it. I see no reason for you to have done all this stuff for a runtime-only feature.

As for doing it the way you are doing it, not only is it a huge hassle, it has a potential for bugs if MMF2 changes the way it handles extensions that are in both sub apps and the main app. You should not rely on something that is not guaranteed. It will work, just not very well.

Log in or register!

Looking for Customer Support?

Subapp Communication in an Extension

Participate now!

Useful Links, Resources & Information

Fusion 2.5 Resources

Crowdfunding Focus