Context: OSX EL Capitan GM
Xcode 7
Xcode 7.1 beta
Swift OSX Cocoa Application
with both Document and CoreData
Problem: Trying to achive a one to many relationship between tabs in a NSTabViewController.
Expected results: Select Parent item in a populated NSTableView on first tab, switch to second tab and see a NSTableView populated with children of that parent .
Actual results: The Tables on both tab views are fully operational with creating/adding and deleting rows, however there is no relationship between the two. Meaning child rows are not filtered.
Setup:
Created a new Swift OSX application with Document and Core Data and Use Storyboard checked.
Replaced the MainViewController with NSTabViewController (subClassed as MainTabViewController).
Renamed first tab Profiles and created a subclass of NSViewController named ProfilesViewController with a Title of Profiles View Controller and assigned the tab view to have that class in IB identity inspector.
Renamed the second tab Commands and created a subclass of NSViewController class named CommandViewController with a Title of Commands View Controller and assigned the Command tab view to that class in IB Identity inspector.
Added NSTableViews to both the ProfilesViewController and the CommandsViewController in IB. Set the Columns to 1 and the Table View Cell for each to Editable.
Created core data entities
Profiles with attribute profileName of type String
Commands with attribute commandName of type String
Added a relationship (and inverse) between the entities Profiles <--->> Commands (ie one to many with Profiles being parent and Commands being children
I then added the following code (courtesy of Mike Swan in this discussion on StackOverflow: http://stackoverflow.com/questions/28184218/what-is-the-new-way-of-binding-an-nsarraycontroller-to-the-managed-object-contex) to the makeWindowControllers method in the Document.swift class:
let tabViewController = windowController.contentViewController as! NSTabViewController
for object in tabViewController.childViewControllers {
let childViewController = object as NSViewController
childViewController.representedObject = self
}
This code initializes a variable in each childviewcontroller of the mainTabViewController to contain a reference to the document instance. This is to make it "easier" to bind the NSArrayControllers to the managedObjectContext in document later.
In the ProfilesViewController I added an NSArrayController using IB, set it to Entity Name Mode in the Attributes Inspector with Profiles as the Entity and Prepares Content enabled. I bound the NSArrayController parameters to ProfilesViewContoller and Model Key Path to:
self.representedObject.managedObjectContext
I added +/- image buttons to the ProfileViewController and bound them to canAdd/canRemove on the NSArrayController and connected actions to add/remove appropriately on the NSArrayController.
In the NSTableView I bound the TableViewCell (NSTextView) Value to the TableViewCell in IB and set the Model Key Path to objectValue.profileName.
In the NSTableView I bound the TableView Content to the Array Controller with controllerKey of arrangedObjects.
In the NSTableView I bound the TableView Selection Indexes to the Array Controller with controllerKey of selectionIndexes.
Built and ran application and all works as expected, I can add and remove persistent rows in the NSTableView.
I then repeated the above process on the second tab, Commands with binding the array controller to the Commands entity etc.
Built and tested and both tabs work as expected independently.
Now the problem, I have created one to many relationships between tables on the same view controller previously binding to the Content Set etc. However, I can't get this to work when the parent is on a different tab than the child. It seems that when you change tabs, the MOC is changed and the selection for the parent is lost.
Any suggestions on how to accomplish/fix this would be greatly appreciated. Even a "you can't get there from here" is okay, I will stop beating my head on the wall and find a way to keep the two on the same view always, but that seems to be a unreasonable restriction.
Thanks Frank