On 2015 Oct 18, at 12:18, Michael de Haan <m...@comcast.net> wrote:
> I have not worked that much with SplitViewControllers,
The fact that it is a split view controller is not relevant here. You’d have
the same issue with any kind of controller.
> The immediate hurdle was to supply each “child” controller of the splitView
> with access to the same managedObjectContext. And, as you saw, it involved
> duplicating code in that childViewController.
Oh, I see what you mean. Worse than duplicating code, it involved duplicating
references to objects.
> But, there was also another wrinkle. A race-condition and initially the child
> controller of the SplitViewController in the stand-alone window, was asking
> for a managedObjectContext from a stack that was not yet set up. That’s why I
> turned to notifications, which were only sent after “DidFinishLaunching” was
> reached.
Instead of sending the managed object context in the notification, it would be
better to delay opening windows which need the managed object context until
after the managed object context is available. In your first message, you said
you were doing this:
> resultWindowController =
> storyBoard.instantiateControllerWithIdentifier("ResultController") as!
> NSWindowController resultWindowController.showWindow(self)
“from appDelegate”.
You could do that, for example, in -applicationDidFinishLaunching, *after* your
Core Data stack has been initialized. Keep it all on the main thread, please.
Then there is no race, and you can access the managed object context as I
suggested at the end of my last reply.
Just show me how to do that in Swift :)
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
