Jump to content
  • Advertisement
Sign in to follow this  
mono2k

unregistering global properties

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

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

Share this post


Link to post
Share on other sites
Advertisement
You can use the dynamic configuration groups for that.


// Register the property in a defined group
engine->BeginConfigGroup("my dynamic group");
engine->RegisterGlobalProperty("int prop", &prop);
engine->EndConfigGroup();

// Later on the group can be removed
engine->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 this post


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

Share this post


Link to post
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 this post


Link to post
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...

Any comments/suggestions?

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 this post


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

Share this post


Link to post
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!