On Oct 3, 2008, at 10:48 PM, Jeff Wilcox wrote:
Not explicitly, but maybe. This seems to be taking place when the
content for the NSTreeController is changing (explicitly) in one
thread, causing a reload in the outline view, and in another thread
the NSOutlineView's drawrect is getting called. I can't say for
sure that this accounts for all of the cases but that seems like a
common theme.
Thoughts?
Don't do that.
You cannot change model or controller objects that are bound to in a
thread other than the main thread and expect things to work. The
reason you can't is that Key-Value Observer notifications (the
foundation of bindings) are posted *around* the change, synchronously,
in the thread which is performing the change.
It looks like you're trying to force it to work by adding
@synchronized blocks, but they're insufficient to do so. This is
because Cocoa doesn't provide the necessary hooks into NSTableView,
NSTreeController or the bindings machinery where you could lock at
every point you'd need to.
Ultimately, you need to accumulate the changes to make on your
background thread, and then push them to the main thread to actually
be applied. If you're using Core Data and the SQLite persistent store
this is straightforward because each thread can use its own managed
object context atop the same coordinator, and saving in the background
thread will generate a notification that you can use to inform the
foreground thread to update.
-- Chris
_______________________________________________
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]
