But what you're doing in that situation is forcing not just your widget, but
likely all widgets to wait until your timer completes. In a threaded
environment, that's not okay.
You should be able to restructure your program to be more event-driven, such
that setTimeout is enough, and your widget will play nice with all the
others.
n.
On Jun 11, 2006, at 1:53p, Lokkju, Inc Widgets wrote:
Eh, perhaps you are not thinking of all usage scenarios. For example,
I want to make async xmlhttprequest calls, but I don't want a method
to return until either the call completes, or a timeout occurs. You
can't set your timeout with sync xmlhttprequest calls (not to mention,
other problems that the sync version of xmlhttprequest causes), so
either you need a sleep method, or else you use a while loop that
burns cpu cycles waiting for a flag to get set. A simple sleep
function would make life much easier, in this and other scenarios.
While I understand the use of setTimeout, in the above situation, it
really won't work - afaik, there is no way currently, without use sync
xmlhttprequest calls, to make a method not ruturn till after the
request is done, or after a specified period of time (and, at least in
the tests I have done, using a setTimeout to call the abort method on
the XMLHttpRequest does not work - the sync XMLHttpRequest pauses the
execution of the timeout).
On 6/11/06, John Louch <email@hidden> wrote:
Sleeping your widget is not something we want you to do ever. If you need
to wait you should use a timer.
Thanks,
jl
> There is one major thing that is missing from javascript core, and yet
> is extremely simple - we need a widget.sleep(milliseconds) or
> widget.wait(milliseconds) function. As of right now, the only way to
> emulate this is with burning cpu cycles in a while loop with
> setTimeout. Of course, it can be done with widget.system calls, but I
> prefer not to use widget.system unless absolutely necessary, since I
> for one have an aversion to running a widget that uses widget.system
> calls (security reasons).
>
> This would be ridiculously easy to add!
>
> Please, please, any Apple Dashboard team members, consider adding this!
>
> Thanks
> Lokkju
> email@hidden
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Dashboard-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
http://lists.apple.com/mailman/options/dashboard-dev/email@hidden
>
> This email sent to email@hidden
--------------------------------------------------
John Louch Internet #: email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Dashboard-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/dashboard-dev/email@hidden
This email sent to email@hidden
