Re: Core Data: Progress bar using Sheet, modifying context in thread
Re: Core Data: Progress bar using Sheet, modifying context in thread
- Subject: Re: Core Data: Progress bar using Sheet, modifying context in thread
- From: Bill Coleman <email@hidden>
- Date: Fri, 4 Aug 2006 19:46:34 -0400
On Aug 4, 2006, at 5:45 AM, Jakob Olesen wrote:
Read the Core Data documentation on multithreading, but really, try
to avoid threads.
OK. So the question remains -- how do I do document-modal processing
without a thread? I got the idea of using threads from an archived
CocoaDev article.
When you set "Automatically prepares content", the controller
observer notifications from the NSManagedObjectContext.
I looked at this, and the documentation says "Returns a Boolean value
that indicates whether the receiver automatically prepares its
content when it is loaded from a nib."
Now, my NSArrayController was loaded from a nib when the document was
created or opened. Is the documentation just very misleading here?
If I set this to NO, will it automatically update when returned to
YES? Or do I have to call something in the NSArrayController? (I'm
already calling rearrangeObjects at the end of the import)
No, but you can probably turn off "Automatically prepares content"
during the import. (I haven't tried that)
OK, I'll try this.
This smells funny. DO NOT use the NSManagedObjectContext bound to
your controllers outside the main thread.
Then I'll need another approach. How do I create Core Data entities
within a thread separate from the main thread? Is there another way
to get the concurrent processing?
The exceptions are probably race conditions.
Likely.
My progress bar also seems to jump back and forth a bit, even
though I'm steadily increasing the value passed to
setDoubleValue:, and I don't change the maximum value after the
import starts.
I believe NSProgressIndicator isn't thread safe either. Somebody
correct me if I am wrong.
You should try to do the import in the main thread. The sheet does
not prevent that. You want to surrender the CPU to the run loop at
regular intervals in order to update the screen, respond to
"Cancel" buttons, and generally avoid the spinning beach ball.
This is the core of the problem. If I do the processing in the action
method for the menu, then no further events are processed in the
application.
I want this to be document-modal, not application modal.
You can get the run loop to call you back using [self
performSelector:afterDelay:] or NSNotificationQueue. This is
cooperative multitasking.
Ugh! I did this for years under MacOS 9....
If you really must use a thread, here is how to do it:
Create a new NSManagedObjectContext, hook it up to your
NSPersistentStoreCoordinator, and use only the new context from the
thread.
Always use -[performSelectorOnMainThread:] to send messages back,
even for the NSProgressIndicator.
I tried this with the progress indicator, but the progress wouldn't
update. I'll try again.
Bill Coleman, AA4LR, PP-ASEL Mail: email@hidden
Quote: "We invented personal computing."
-- Bill Gates @ TechNet / MSDN 2003
_______________________________________________
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