Type coercion in executeScriptedEventHandler

[zola]

Hi

I'd like to implement a scripting module for angelscript but I'm having diffulties to implement the executeScriptedEventHandler method in a generic way. My major problem is that I can't really decide on the EventArg what derived type it is. I think I would need this for correctly prepare the parameters for my scripted handler function?

I could leave this to the scripted handler function itself (providing some functions that extract the desired data) but this would mean that I have to add the EventArg ( extensions and basic CEGUI types (string), ...) to the script engine which I'd like not to do .

Any hints or ideas how I could go about this problem are welcome.

Thanks
Tom

[CrazyEddie]

Hmmm. That's a bit of a problem In the gigantic Lua binding module I had everything exposed, so this issue didn't come up. The interface was put in with the intention that the script would receive and process the EventArgs structure in some way. The solutions I currently see for this are less than elegant...

You could use C++ RTTI typeid operator, this may or may not scare you

Another possible solution requires changes in the system itself, but is not particularly great IMO... The EventArgs structure gets a type field that tells you its actual type (which is basically a poor mans RTTI, except it's less useful as things get extended).

With both approaches, you're basically looking at some kind of conditional in executeScriptedEventHandler that decides what the object really is.

I can't see any means of adding addional interface that would ease this, since all subscribed event handlers take EventArgs&. I am, as ever, open to suggestions If you want the type field added to EventArgs I'll do it.

CE.

[zola]

Maybe I was just hoping for a miracle

I like the events as they are right now. In C++ its easy enough to handle them since you know what eventtype you registerd and you can cast types at any time.

For the AS scriptingmodule I'll provide some methods that can extract information form an event . The Scripted eventhalder can then use these methods to extract the info it needs from the EventArg. I think this is a moderate expense and it will also be fairly easy to extend for future EventArg types.

A drawback is that it will leave a lot of responsibility to the eventhandler (which shouldn't be the case for scripts) but at the moment I can't think of a decent solution.

Thanks
Tom