[Laszlo-dev] Generic notifying events [Was: For Review: Change 20090427-hqm-Q Summary: fix for swf9 context menus, mouseEnabled no longer always set to true on every sprite]

[P T Withington]

On 2009-04-28, at 12:59EDT, André Bargull wrote:

> On 4/28/2009 6:02 PM, P T Withington wrote:
>> On 2009-04-28, at 09:21EDT, André Bargull wrote:
>> [...]
>>> We don't want to scan the text everytime to detect a hyperlink.  
>>> That's why we implemented the workaround at LPP-7551.
>>> Maybe we could re-use the notifying event mechanism Tucker used  
>>> recently. But that means hyperlinks aren't active and aren't  
>>> displayed as clickable in swf9, until a listener for ontextlink is  
>>> installed..
>> I guess I had better make notifying events generic! :)
>> Here's my proposal.  Add a method to:
>> LzDeclaredEventClass {
>>  function actualEventClass() { return LzEvent; }
>> }
>> You would subclass this class and create a singleton that you would  
>> initialize your events to (instead of LzDeclaredEvent) if you want  
>> your actual event class to be something different (like a subclass  
>> of LzEvent).
>
> This requires you to write two classes for each special event type:  
> One subclass of LzDeclaredEventClass and one subclass of LzEvent.
> Can this be optimized in some way?
>>

Yes.  Silly of me not to think of this the first time around:

class LzDeclaredEventClass {
   var actual;

   function LzDeclaredEventClass(actual=LzEvent) {
     this.actual = actual;
   }

   function actualEventClass() { return this.actual; }
}

So all you have to do is make your own declared event instance to  
initialize your event to, you don't have to make a separate class.

>> Add a method to:
>> LzEvent {
>>  function onReadyChange(newValue) {}
>> }
>> When ready changes it's value, onReadyChange will be called with  
>> the new value.  You can override this method in a custom event  
>> class to connect/disconnect the event with a runtime-specific  
>> callback.  This is more efficient than having a permanent callback  
>> that checks the event's ready state on each callback.
>
> We should ensure onReadyChange doesn't get called for standard  
> LzEvents to avoid unnecessary overhead, because events are in  
> general a performance critical area.


And the way to do that is simply to make LzNotifyingEvent a subclass  
of LzEvent.  LzEvent won't have that method (or call it), only  
subclasses of LzNotifyingEvent will.

I'll be sending around a change later for review...