In debug mode, the compiler will emit a warning if you try to call a
non-function.
On 2006-04-12, at 12:43 EDT, Jim Grandy wrote:
> I haven't checked, but would the compiler really catch this technique?
>
> LzView.prototype.__LZcheckwidth = function () { ... }
>
> then later, in a separate method:
>
> this.__LZcheckwidth = null;
>
> And then later:
>
> __LZcheckwidth();
>
> We're masking out a method declared in the prototype by putting a
> null attribute value in front of it. But the method has been
> properly declared.
>
> jim
>
> On Apr 12, 2006, at 9:10 AM, P T Withington wrote:
>
>> I'm working on making the translator work in debug mode. My hope
>> is to make these kinds of errors easier to find and fix in dhtml.
>> You should already be able to do that in swf though, if you just
>> turn on warnings in the piece of the LFC you are working on. Just
>> put
>>
>> {
>> #pragma 'warnUndefinedReferences=true'
>> ...
>>
>> }
>>
>> around the code you are working on. Eventually we want to be able
>> to do this for the whole LFC.
>>
>> On 2006-04-12, at 11:45 EDT, Jim Grandy wrote:
>>
>>> We don't just use this technique here. In LaszloView.as, we clear
>>> __LZcheckwidth and __LZcheckheight to null in certain situations,
>>> and then call them without checking for null.
>>>
>>> On Apr 12, 2006, at 5:50 AM, Henry Minsky wrote:
>>>
>>>> OK will do.
>>>>
>>>>
>>>> On 4/12/06, P T Withington <[EMAIL PROTECTED]> wrote:
>>>> This looks like a 'stupid AS trick' to me. Don't try this at home.
>>>>
>>>> I would just change the loop to test d.enabled, and change
>>>> LzDelegate.disable to just set the flag and not muck with the
>>>> innards
>>>> of the delegate.
>>>>
>>>> [This is why nullable types suck.]
>>>>
>>>> On 2006-04-11, at 11:50 EDT, 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
>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Henry Minsky
>>>> Software Architect
>>>> [EMAIL PROTECTED]
>>>>
>>>> _______________________________________________
>>>> Laszlo-dev mailing list
>>>> [email protected]
>>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>
>>
>
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
