Couldn't we just add a flag to LzEvent that determines whether
onReadyChange() is called? Seems much simpler to me...
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?
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.
--
Regards,
Max Carlson
OpenLaszlo.org
