Re: Displaying progress of lengthy operation: complication with bindings and threads
Re: Displaying progress of lengthy operation: complication with bindings and threads
- Subject: Re: Displaying progress of lengthy operation: complication with bindings and threads
- From: Mike Blaguszewski <email@hidden>
- Date: Fri, 31 Mar 2006 19:00:39 -0500
On Mar 31, 2006, at 1:50 PM, Sean McBride wrote:
One idea is to spawn a worker thread to do the lengthy work like this:
for (num items)
lengthy computation
performSelectorOnMainThread:@selector(advanceProgBar:)
How about splitting your computation into short stages and then in a
secondary thread that looks something like this (incorporating Sean's
suggestion about notifications):
for item in (items)
for stage in (stages)
if (!userCanceled)
performSelectorOnMainThread(perform_computation(item,
stage))
else
performSelectorOnMainThread(abort computation)
return
where perform_computation looks like:
perform_computation(item, stage):
...
postNotification(statusChangedNotification)
Use the blocking form of performSelectorOnMainThread, and you've got
your control flow all in one place, but with all the work happening
on the main thread. The only shared data is the boolean userCanceled.
If your work stages are the right size, then the runloop overhead
should be minimal, but you'll still have a responsive GUI (even if
it's just a cancel button in a modal window).
--
Mike Blaguszewski / Ambrosia Software, Inc.
_______________________________________________
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