Script Instantiated Class Event Handling

[Alex Parlett]

Bit of a discussion, as I haven't decided what would be the best way to go about implementing this yet.

Currently using ScriptInstance only the ScriptObject defined when created can be used to receive events, however if I wanted to do something like the following, where Bar is instantiated from the C++ code in ScriptInstance:

class Foo : ScriptObject
{
    ...
    SubscribeToEvent(listbox,"SelectionChanged","HandleListBoxSelectionChanged");
    ...
    HandleListBoxSelectionChange(StringHash eventType, VariantMap& eventData) { }
    ...
}

class Bar : ScriptObject
{
    ...
    Foo@ foo;
    ...
    Start()
    {
        foo = Foo();
    }
}

It will never work because the ScriptInstance will only look for the method in Bar. There are work arounds in we can have Bar have all the event listeners or have global functions to handle the events. It would help clean-up and improve the angelscript code if in some method we could allow pure script classes which aren't instantiated through the ScriptInstance to receive events as well.

I have some ideas based around the receive script classes example in the docs, so I think allowing the scripts to do something like this:

SubscribeToEvent(this,listbox,"SelectionChanged","HandleListBoxSelectionChanged");

Should be possible but its then comes the handling in ScriptInstance and ensuring the correct object receives the correct event, if ScriptInstance is even the right place to handle this but I expect it should be since we'd want to associate the script classes with the ScriptInstance which instantiated the original class.

Any thoughts or ideas would be good to hear on the concept.

[Chris Friesen]

In javascript it is common practice for libraries to have the last object in a method be the receiver of the function.  This behavior is then invoked using the apply/call methods on a function object.  In lua it is the first aurgument when calling a method via the '.'.  Lua will conventionally pass this if you call the method via the ':' operator.

How about this?

If an Object calls the Subscribe then have it be the reciever.  If you call the global method subscribe have the last parameter be the reciever as an overload to the current api.  Shouldn't break anything then.

I agree that I am fighting code quality on event handlers.  Every other pubsub system i have used the event supports an array of subscribers.  In the web world not many people mind to unsubscribe from events to coupling the destruction of the object to event unregistration is very useful.

[Alex Parlett]

Seems a good way to move forward, have an optional parameter at the end for specifying which object has the event handler, hit a major snag at the moment though which actually has an impact on everything Angelscript and not just subscribing to events. To know which ScriptEventListener to use Urho relies on setting UserData void pointer to point back to the correct location, as soon as you do something like:

class Foo{...}

class Bar
{
   Foo@ foo;

   Bar()
   {
      @foo = Foo();
   }
}

That UserData pointer to the ScriptEventListener class it lost, no matter if you're still in Bar instead of inside Foo. It seems to be because you move from one class to another, and the angelscript internal object changes even if its a pure script class and therefore the current user pointer data is lost.

My current test still works in a way, you have one method to instantiate and one method to create the event listeners, since the process of calling that second method will reset the user data pointer back to the proper ScriptEventListener it works, but it does require the parent to set all the event listeners even if they are methods in the children:

SubscribeToEvent("Update","HandleUpdate",@foo);

[Alex Parlett]

Pull Request Up for anyone interested: https://github.com/urho3d/Urho3D/pull/100