Re: Cocoa binding and threads.
Re: Cocoa binding and threads.
- Subject: Re: Cocoa binding and threads.
- From: David Burnett <email@hidden>
- Date: Wed, 16 Aug 2006 14:48:01 +0100
Chris Hanson wrote:
On Aug 14, 2006, at 10:18 AM, David Burnett wrote:
I'm attempting to multi-thread my Cocoa application which is heavily
based on Cocoa Bindings using Core Data and I'm having GUI update issues.
Do not modify objects that are bound to in anything but the main thread.
That is what I though It was doing :-)
the values from the Entities in the Managed Context does not update on
adding a new entity until either
I click on the window.
Move the mouse over a control that changes the cursor.
Change focus on/off the window.
They worked fine before I started to run this code of a new thread.
It sounds like you just took the logic that was on your main thread and
wrapped it in -[NSThread detachNewThreadSelector:toTarget:withObject:].
Is that what you did?
Not quite, I did rearrange the code so that the parts that I knew
affected the GUI and bindings could be called using
performSelectorOnMainThread.
The new Entity is created in createGenomeEntity and one of its values
is changed in AddNewFlame. Both are called using
performSelectorOnMainThread: withObject: waitUntilDone:YES so all of
the changes in the bound values should be performed on the main thread.
From the above, it sounds like you're still *accessing* managed objects
associated with the same managed object context used by the controls in
your main thread on your detached thread.
Are you saying that just *reading* values from different objects in a
single context in different threads is not supported. That is a bit of
blow IMHO, especially when multi-core CPU's are going to lead to a more
threaded software architecture.
Back to the main topic, I do have code that attempts to read values from
a different managed object, the currently selected but as far as I'm
aware the new object is created (insertNewObjectForEntityForName...) and
all values are set / altered in functions that are called using
performSelectorOnMainThread. Calling processPendingChanges using
performSelectorOnMainThread appears to solve the issue, still leaving
the question as to why the changes where pending.
If you want to perform this operation on a separate thread, you'll have
to create a separate context on that thread and connect it to the same
persistent store coordinator Then when you make changes on your
detached thread, you can save those changes to your persistent store,
send the collection of object IDs that changed over to the main thread,
and refresh those objects in the context you're using in the main thread.
Ouch !
Dave
_______________________________________________
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