Re: Secondary run loops?
Re: Secondary run loops?
On 10/08/2006, at 1:48 PM, Andrei Tchijov wrote:
calling
[[ NSRunLoop currentLoop ] runUntilDate: [ NSDate
dateWithTimeIntervalSinceNow: 1.0 ]]
in place of WaitNextEvent() might help
You should be aware that doing things this way might mean that
whatever you're doing could get interrupted for a time if the user
can do things that take a while. For example, many things process
their own events whilst the mouse is down. Or you might have an
application modal dialog that gets displayed which again processes
events outside of your control. You'd also obviously want to avoid
recursion. The other thing to be wary of with the approach is that
you need to process the run loop sufficiently fast that the user
interface still seems responsive; calling the method above every,
say, 10 loops might work well on your machine but not on a slower
machine.
Using a separate thread to do the work you need avoids these
problems, although is arguably more complicated to implement.
I want to try to do the most correct thing; however, I'm not sure how
to implement UI threads (I thought you couldn't do UI from a thread):
loop
do_something() <--- this is a thread
update_status(); <-- this is UI stuff
Is the whole loop put into a thread (so you have two levels of
threads)? Even if it is, I still don't know how to get the UI to
refresh--it seems that what ever I do doesn't show up (updating a
text view, progress bar, etc) until a Cocoa event loop gains
control. My main lack of understanding comes from how to loop and
still get the UI to refresh. Andrei's solution makes that happen
(I'm used to the recursion issues that you've brought up from my
Carbon programming days), but if there's a better way (or more Cocoa
way), I'd like to know it.
Thanks!
Mark
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden