I think you should definitely try to get the loop working in another
thread. I know it can be tricky, especially if you are dealing with
some thread unsafe classes, but it is worth it and will likely be very
beneficial in the future. (On an utterly unrelated aside, this looks
interesting: http://www.apple.com/macosx/snowleopard/)
Just so you know though, if you absolutely cannot do that and you
cannot even break up the loop, you can still get the progress bar to
update by calling -display on it after setting its new value.
That won't run the event loop, so the UI will still be unresponsive,
but it will synchronously redraw the progress bar. You can also use
this in combination with -setUseThreadedAnimation to make the
animation run smoothly.
Adam Leonard
On Jun 10, 2008, at 10:59 PM, Graham Cox wrote:
On 11 Jun 2008, at 2:40 pm, j o a r wrote:
On Jun 10, 2008, at 3:17 AM, Graham Cox wrote:
though out of curiosity I wonder if there is a way to do this
"cooperatively" on the main thread without having to break up the
loop doing the actual work. For example, in Carbon one can run the
event loop for a short period or just for one event on each cycle
of the loop - and this code can live in the progress dialog
controller, so it works transparently with respect to the loop
that drives the progress indicator. I'm not sure that approach is
considered "good" in this day and age though I used it a lot on
Mac OS 6/7/8/9. Just wondered if such an approach is feasible in
Cocoa.
Yes, you can do that. You would typically use a NSTimer to
repeatedly schedule small pieces of work to be performed on the
main thread. You wouldn't have to use a modal session to do this -
It is certainly not a requirement to lock out the user while
processing data.
Sure, I can easily implement piecemeal work using a timer. That's
not quite the same as I was asking. I was wondering if I could do
something like:
while( notFinished )
{
/* do some work */
letTheEventLoopRunABit();
}
This was a pretty common idiom in the pre-OS X days, though of
course one must bear in mind what the stack looks like when the
event loop is allowed to run. It ain't pretty ;-)
That said - No, it is not considered to be a good approach. It's
almost impossible to implement it in such a way that it doesn't
affect the user experience. It's typically much better, and more
"future safe", to invest your time in a multi-threaded
implementation.
Yep, seems to be the way to go. In this case it was an easy change
to allow the work to run on a separate thread. I guess the only
thing that scares me about threads are the sheer number of classes
that are not considered thread-safe, and so calling one accidentally
from another thread.
cheers, Graham
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/adam%40caffeinatedcocoa.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
