unregistering global properties

This topic is 4158 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

Hello again ;-) Is there any way to unregister an arbitrary global property? It would be a very nice featrue...

Share on other sites
You can use the dynamic configuration groups for that.

// Register the property in a defined groupengine->BeginConfigGroup("my dynamic group");engine->RegisterGlobalProperty("int prop", &prop);engine->EndConfigGroup();// Later on the group can be removedengine->RemoveConfigGroup("my dynamic group");

You'll have to carefully design your application though, as you will only be able to remove the group when no script is referencing it. You'll get a asCONFIG_GROUP_IS_IN_USE (-22) return code if it is still in use when you try to remove it.

Regards,
Andreas

Share on other sites
Thank you, looks like it is exactly that I need...

Share on other sites
A little question...
May I call ExecuteString (or Prepare/Execute) after BeginConfigGroup but before EndConfigGroup?

Share on other sites
just checked, seems work nice

Share on other sites
Even though it works I do not recommend it. I may change this behaviour in the future in order to provide better validation of configurations.

Share on other sites
I'm a bit confused... Is it possible to discard ExecuteString's compilation results, not the whole module?

I'm using AS in such way:

1) Load a large file containing all script functions

2) Register global classes/properties and build this file

Later in the game I'm trying to do such thing:

3) On each new menu screen BeginConfigGroup(screen_name)

4) call RegisterGlobalProperty for every GUI object defined in the XML definition for current menu screen. Imagine following XML definition

// show_player_info is defined in the standalone AS script file<player_list id='players01' x='10' y='10' width='100' height='300' on_player_selected='show_player_info(players01.get_selected())' />

My goal is to register 'players01' as a global property for current menu screen only, so it is very easy to work with an actual C++ implementation of player_list for every scripted event handler defined on the current screen only.

5) EndConfigGroup()

6) For each defined event handler I try to call ExecuteString and it works perfectly, but!

7) In the case of the current screen's destruction (i.e. player pressed a button and we need to show the next screen) I'm trying to call RemoveConfigGroup but it looks like ExecuteString binds some internal data with the main chunk of code and the call fails with -22, as you predicted...

P.S.: my game is for moble devices and it is important to prebuild as much as possible, and it is not a good idea to discard the whole module and rebuild it on an each new screen...

[Edited by - mono2k on March 29, 2007 5:41:42 AM]

Share on other sites
Perhaps try calling asIScriptEngine::GarbageCollect(true) to free up any remaining references to that config group.

Share on other sites
GC collector has not helped...

Share on other sites
Hmm, I don't think I've tested this scenario, so I'm not sure how it will work. But I have a couple of solutions in mind.

The bytecode and context that ExecuteString() uses is normally discarded on the next call to ExecuteString(). But you can also give it a pre allocated context to use for the execution. So the suggestions I have are:

1. Try creating the context yourself with CreateContext(), and then pass it to ExecuteString(). When the execution finishes, you should be able to release the context and remove the config group.

2. If that doesn't work, you may try calling ExecuteString() again, this time with an empty string, i.e. ExecuteString(0, ""). This should also free the previous execution and references to the config group.

You may also need to call the garbage collector, just in case. Because, even though most objects are released immediately as the reference counter goes to zero, some may linger around, especially if they have the potential to form circular references. Though this is likely only a problem if you register new types in the dynamic groups.

Regards,
Andreas

1. 1
2. 2
frob
15
3. 3
4. 4
5. 5

• 20
• 11
• 13
• 14
• 78
• Forum Statistics

• Total Topics
632142
• Total Posts
3004393

×