[Laszlo-dev] RE: Idle callbacks are the devil's tools!

[Max Carlson]

This seems like a bad idea to me.  I've had a lot of cases where I 
wanted to bind a method to an event, invoke it by name directly.

Another thing that would be nice is if onevent could take a list, 
allowing a single method could bind to multiple events.  One case where 
I've wanted this is when I want a drawview to redraw when its height or 
width are changed.  As of now, I have to have the event bindings invoke 
a third method.

-Max

Oliver Steele wrote:
> I think Tucker had a proposal to do away with the distinction between  
> event= and name=, and to instead specify that any method whose name  
> begins with 'on' is automatically registered as an event handler for  
> that event.
> 
> On Jun 8, 2005, at 2:30 AM, Max Carlson wrote:
> 
>> I've been stumped over this very mistake a number of times.  It  would 
>> be nice if the compiler warned for events that don't begin  with 
>> 'on'.  I've filed a feature request at http:// 
>> www.openlaszlo.org/jira/browse/LPP-401
>>
>> -Max
>>
>> Don Hopkins wrote:
>>
>>> Sarah spotted the mistake I made in the following test. I was using
>>> event="foobar" instead of name="foobar". It works correctly when I  use
>>> name="foobar", since delegates call names, not events.     -Don
>>> -----Original Message-----
>>> From: Don Hopkins [mailto:dhopkins at DonHopkins.com] Sent: Tuesday,  
>>> June 07, 2005 5:15 PM
>>> To: 'OpenLaszlo development development'
>>> Cc: 'Don Hopkins'
>>> Subject: Idle callbacks are the devil's tools!
>>> Am I doing this wrong, or is there a bug in LzIdle.callOnIdle?  When 
>>> you run the following code (enclosed), the foobar method doesn't
>>> get called. The documentation for callOnIdle is worded strangely.  It 
>>> says:
>>> LzIdle.callOnIdle(d) Calls the given delegate at the next idle  
>>> event. This can be used for a
>>> non- recursive callback.
>>> Shouldn't that be "non-repeating"? (I don't think "recursive" is the
>>> right word to describe a repeating callback.) The documentation  should
>>> be explicit about the fact that the delegate is called only once, and
>>> then unregistered. (And the behavior of the code should match the
>>> documentation! ;-) To work around this problem, I'm just  registering 
>>> an LzIdle.onidle
>>> callback, and unregistering it when it happens. I want to defer some
>>> layout processing until after all replication has happened. But
>>> unfortunately the replication seems to be happening via onidle
>>> processing too, so we're both waiting in the same line, and it  calls my
>>> lazy layout callback before all the replication is finished. Is  
>>> there a way to register a lower priority onidle callback that will
>>> only run once all the pending replication and instantiation is  
>>> finished?
>>> I'd like for my idle callback to go to the end of the line each time
>>> something changes. If I unregister and reregister my onidle  callback 
>>> (instead of checking
>>> to see if I'm already registered and not doing anything in that case,
>>> keeping my place in line) will my delegate go to the end of the line
>>> behind any pending replication callbacks? But that would require more
>>> processing, so I'd prefer a lazier way to be lazy. I am  considering 
>>> using a timer instead, but that would introduce an
>>> unnecessary delay, and it still might fire too early. It would be  
>>> nice to have a reallyidle event that gets fired when the
>>> idle queue is empty.     -Don
>>> <canvas
>>>   width="100%" height="100%">
>>>   <attribute name="del" value="null"/>
>>>   <method event="oninit"><![CDATA[
>>>       this.del = new LzDelegate(this, 'foobar');
>>>       Debug.write("calling LzIdle.callOnIdle", this.del);
>>>       LzIdle.callOnIdle(this.del);
>>>     ]]>
>>>   </method>
>>>   <method event="foobar" args="args"><![CDATA[
>>>       Debug.write("foobar should be called, but isn't...", args,
>>> this.del);
>>>     ]]>
>>>   </method>
>>> </canvas>
>>> _______________________________________________
>>> Laszlo-dev mailing list
>>> Laszlo-dev at openlaszlo.org
>>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>>
>>
>> _______________________________________________
>> Laszlo-dev mailing list
>> Laszlo-dev at openlaszlo.org
>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
>>
> 
>