[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]

[André Bargull]

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?


> 
> 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.