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: Sean Murphy <email@hidden>
- Date: Fri, 31 Mar 2006 16:29:46 -0500
On Mar 31, 2006, at 1:50 PM, Sean McBride wrote:
Hi all,
Some operations in my app take several minutes and so the app
currently
SPODs; I would prefer to add a progress bar. The app uses bindings
and
is single threaded.
One idea is to spawn a worker thread to do the lengthy work like this:
for (num items)
lengthy computation
performSelectorOnMainThread:@selector(advanceProgBar:)
But the 'lengthy computation' part would read and write to my model
objects, and those objects are connected to UI objects via bindings.
I've searched the archives and this has been discussed before. KVC/
KVO/
bindings are not thread safe. Which- I believe, I'm no threading
expert- means it's entirely unsafe for my worker thread to touch any
object that is involved in bindings.
So now I'm really unsure of how to best approach this, any
suggestions?
Hey Sean,
To keep things simple, I wouldn't use a separate thread just for
displaying some status information in a view. I would only introduce
another thread if it could help with the data processing (or, in your
case, the lengthy computation) part. Spawning a thread would bring
the whole question of thread-safety into the picture, as you talked
about, and why worry about that if the benefits aren't worth it?
So, maybe you could use notifications in your data object, which lets
the model inform the view 'indirectly' and stay within the MVC
design. As it loops through the computation it could notify a change
in progress, and the controller object could handle this. You would
need to call [progressIndicator display] after setting the value,
instead of [progressIndicator setNeedsDisplay] because the latter
only performs a re-draw during the next event loop, and in your case
the next event loop takes place after the computational for loop is
finished.
Since you are using bindings, you might be able to even find a better
way, using the method above as a guideline. Hope that helps. There
may also be an even better approach..I am still fairly new to cocoa
and still learning myself, so anyone can feel free to correct me!
- Sean
_______________________________________________
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