🎉 Celebrating 25 Years of GameDev.net! 🎉
Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!
unregistering global properties
Author
Hello again ;-)
Is there any way to unregister an arbitrary global property?
It would be a very nice featrue...
You can use the dynamic configuration groups for that.
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
// Register the property in a defined groupengine->BeginConfigGroup("my dynamic group");engine->RegisterGlobalProperty("int 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
Author
A little question...
May I call ExecuteString (or Prepare/Execute) after BeginConfigGroup but before EndConfigGroup?
May I call ExecuteString (or Prepare/Execute) after BeginConfigGroup but before EndConfigGroup?
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.
Author
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
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]
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]
Perhaps try calling asIScriptEngine::GarbageCollect(true) to free up any remaining references to that config group.
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
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
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
