This looks good. Now, if I want to make use of this in 4.2, is it going to be a mess to back portthe rest of your new event stuff?
On Tue, Apr 28, 2009 at 4:02 PM, P T Withington <[email protected]> wrote: > 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... > > -- Henry Minsky Software Architect [email protected]
