GameMonkey Script

I have a few userobjects bound to C++ objects. In a few instances, I need to be able to remove them completely from GameMonkey and C++ at the same time. I had planned on just throwing something in the destructor to accomplish this, but I'm unsure what I can use in GM to remove the actual userobject and thus nullify any references?

Anybody know what I have to do?

If you've implemented your userobjects in the common way, all your script variables (for a single object instance) will reference the same gmUserObject. Although you don't and shouldn't have control over the gmUserObject's life time, you certainly do have control over what is inside it. You can delete the native payload and nullify the user objects reference (m_user).

If script variables could possibly try to access this dead or dying object, you may need to add some verification code in script to check for this, and/or use a extra dereference or similar whereby the script object appears valid while the payload is logically null.

I thought m_user pointed to the C++-side object bound to the userobject in memory? I'm trying to create a .close() function for my GUI objects, which are bound to script.

You can see the video here, actually, and maybe my problem will be more apparent:
http://www.youtube.com/watch?v=owFtSazlmjU

Anyway, when I hit the "close" button in the bottom left corner of the screen, it calls the onClick function, which calls a "close" method on the container that holds all the GuiControls.

The close method is defined in C++ and should completely nullify all references to the userObject so it can never be accessed through script again, destroy the GuiControl in memory, and then let it be collected whenever the GC chooses to kick in. I can't figure out how to nullify all the references to the userObject, though, which is causing issues with the whole concept.

Is this possible in GM? Alternatively, I figure I could leave the GuiControl's data in memory, and then when the GC collects the userObject, destroy the data at that point, but what it all boils down to is that the GuiControl must not be accessible in script at any point following the close function being called in script; must be treated as a null value.

I think we're almost on the same page...

Yes, the m_user is often a pointer to the native object. (It could be a numeric handle instead.) When you nullify this, all gmVariables that reference this gmUserObject will no longer be valid. If script is processing these variable, the script should check for null before accessing (call functions, access members etc.). It is probably best that your user type implement operator O_BOOL. This way you can write code like if ( uiElement ) { uiElement.Flash(); }.

I am assuming that when you expose native objects to script you 1) create a single gmUserObject and reference it for the lifetime of that object (as opposed to creating a unique gmUserObject which happens to reference the same native object repeatedly). And 2) register a unique type, preferably wrapping gmUserObject and combining it with a table for greater control.

Reading the last part of your message again, you may be able to let GM destroy your native objects via its GC, but in that case you would have to flag the object so it can't be used again. You need to decide whether native code or script code owns the object. If you are creating and operating on objects mostly from script, perhaps script should own them. If you are creating and operating natively but merely exposing them to script, perhaps native code should own them.

Ah, I see what you meant now.

Thanks! I finally got everything rigged up correctly