Sign in to follow this  
DaesDemon

error in using some global property

Recommended Posts

Hi AngelScript friends, I come into a problem that i really don't understand: I have a class with a GenericControl pointer inside
[source language=cpp]
class GenericControl // do nothing
{
    GenericControl() {};
    virtual ~GenericControl() {};
}

class BoolControl // Registered simply in AngelScript with no behaviour
{
    Grid* mGrid;
    int mIndex;
    AControl(Grid* grid, int index) { mGrid = grid; mIndex = index; }
    setValue(bool);
    bool getValue();
}

class Grid
{
    GenericControl* mControl;
    scriptDeclare(id)
    {
        mControl = new BoolControl(this, id);
        engine->DeclareGlobalProperty(BoolControl control,mControl);
    }
    OnControlChanged()
    {
        id = getControlId();
        scriptDeclare(id);
        engine->ExecuteScript(getControlScript()); // like : control.setValue(false); or doSomething(control.getValue());
        delete mControl;
    }
}


The problem is the script don't get the good Control Pointer so it try to execute functions on a bad pointer and crash, but i cannot figure why. Is it not possible to register a member property as a GlobalProperty? Have i to declare special behaviour to do that? It seems not as i have no need to create some of this object by script and these are basic object with no problems of memory allocations. Is there a problem with the virtual destructor? but i tried it as not virtual and get the same. Any idea welcomed ;)

Share this post


Link to post
Share on other sites
One thing really strange in a little more complex case where i got different Control Type is when i look at my log:

...
19:16:50: AngelScript: void LightPopulate(PanelObjectList OL ,SceneManager SM)
...
19:16:51: AngelScript: global Panel panel = 0xa7cd7c8
19:16:51: AngelScript: global SceneManager sceneMgr = 0xdc29288
19:16:51: AngelScript: global ControlBool control = 0xa6be5b8 (1)
19:16:51: AngelScript: Exec->control.setValue(sceneMgr.getShowDebugShadows())
19:16:51: AngelScript: Execution Success
19:16:51: AngelScript: global Panel panel = 0xa7cd7c8
19:16:51: AngelScript: global SceneManager sceneMgr = 0xdc29288
19:16:51: AngelScript: global PanelObjectList control = 0xa6bb5d8 (2)
19:16:51: AngelScript: Exec->LightPopulate(control,sceneMgr)
19:16:51: AngelScript: Output->ExecuteString (1, 1) : Error : No matching signatures to 'LightPopulate(ControlBool&, SceneManager&)'


we can see there that :
1) i first declare control as a ControlBool global property
Execution successful
2) i declare it as a PanelObjectlist
And then i get an undefined signature function as this function is registered for PanelObjectList.

So what i think is , although i declare it a second time with the good type, it is still considered by AngelScript as a ControlBool.
This can be the reason of my first problem perhaps even if i don't know how, but really that seems that i cannot register twice the same GlobalProperty with different type.( and if it is not a bug, AngelScript should perhaps in a next version, complain about redefinition )

So my first question is how can i unregistered my global control property for AngelScript to recognize the new one?
I tried to register it again with value 0, but it seems to change nothing.

My second will come perhaps later if it don't resolve my first problem ;)

[Edited by - DaesDemon on September 8, 2005 12:27:21 PM]

Share this post


Link to post
Share on other sites
You have already detected the problem yourself.

You're registering a global property using the same name more than once and this fails. AngelScript should return an error code in this case (if it doesn't, let me know so that I can correct that behaviour). I don't see you verifying the return code.

Another thing. You're deleting the control pointer, but the control is still registered as a property with AngelScript. That's a dangerous business, though in your case you don't seem to use the property after deleting the control so it doesn't matter much.

If you want to use dynamic configurations, like you do, then you have to use the latest WIP (available from the site), which allow you to register configurations in groups, where the groups can later be removed and replaced. Look for BeginConfigGroup(), EndConfigGroup(), and RemoveConfigGroup() in the manual. Earlier versions of AngelScript don't support dynamic configurations, except for additions.

Another possible solution would be to register a pointer to a pointer to the control. That way you could change the control, without having to reregister it with AS. This won't allow you to change the property declaration though.

Regards,
Andreas

Share this post


Link to post
Share on other sites
Thanks WitchLord i was thinking on something like this,

No i logged all the messages i can get (those i know of;) ) from AngelScript and it doesn't complain on the Reregistration. (that's why i was thinking it was possible)
I am doing as you said (assert the result) and i am login now with the asIOutputStream for execution.
This is not in the code, because i use a wrapper Class for your engine that log everything.

But wouldn't it be convenient to have an UnregisterGlobal... to avoid this kind of problems.

I am using the 2.0.3b version so I am affraid i will have to use the last version of your library because i would like control to be the 'code' for all my controls( so different type ).But as i will be away for two weeks until tomorrow, i will not begin that now ;)
Anyway, i am really happy, that it seems to you still possible; After a first euphoric "Great it works great", i am now stuck on different problem (like my other message) that takes me time to understand. But i guess that is the way of learning :).
Thanks a lot for your support.
Friendly
DaesDemon


Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this