the advantage of delegate.disable is that it's faster than unregistering.
I wonder if the disable method is used anywhere in the LFC. If it's not,
we should consider removing it. If it is, we should check for null.
A
On Apr 11, Henry Minsky wrote:
> There is a method for disabling a delegate which is currently implemented as
>
> LzDelegate.prototype.disable = function (){
> if ( !this.enabled ) return;
> this.enabled = false;
> this.disc = this.c;
> this.c = null;
> }
>
> This has the unfortunate side effect of causing an error in DHTML runtime if
> you then try to call
> this delegate, because the inner loop of LzEvent.sendEvent does
>
> for (var i = dll; i >= 0; i--){
> d = this.delegateList[ i ];
> //pointer may be bad due to deletions
> if ( d && ! d.event_called){
> d.event_called = true; //this delegate has been called
> calledDelegates.push( d );
> // d.execute( sd ); inlined
> // We don't worry about deleted contexts here, because
> // we assume that delegates registered on events are
> // properly managed
> d.c[d.f]( sd );
> }
> }
>
> And d.c will be null, causing an error in 'real' javascript. Should I put a
> check here for the disabled flag,
> or should we bind d.c in LzDelegate to some inert event while it is
> disabled?
>
>
>
> --
> Henry Minsky
> Software Architect
> [EMAIL PROTECTED]
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
