macOS Best way to do an inspector panel?

[mduser63]

Ok, I've been trying to figure this out on my own, but nothing I do really seems right, and I still don't have it working perfectly anyway, so I'm asking for advice. I've got a document-based, core-data app that makes heavy use of bindings. The Core-Data model is not particularly complicated, but it's not dead simple either. There are 5 entities in it, and they each have a fair number of attributes along with optional relationships to others in the model. Each document contains an array of one of these entities (which by relationship means there are multiple instances of some other types of entities). One type of entity is only supposed to be instantiated once per document.

I want an inspector panel that lets one view and modify the attribute values of this entity that's only instantiated once. As there should only be one inspector panel in the application even with multiple documents open, obviously the inspector panel should be in a separate nib. Here's where I'm running in to trouble. What is the correct architecture for having the Inspector panel connect to the entity that's part of MyDocument? Included in this question is the solution to the problem of making the inspector panel update itself when a different document is brought to the front. The things I'm doing now are overly complicated and don't really work at all.

If anyone can explain a good way to do this, I'd really appreciate it. It seems like it has to be a common problem because there are tons of applications with a floating inspector panel which applies to the frontmost document. If anyone can point to a good tutorial that address this rather than explaining it, that would be helpful too. I haven't been able to find one searching myself. I would like something that specifically covers Core Data and Bindings, because I'm using both.

 

[gekko513]

Searching for NSDocument in the Xcode documentation gave me the NSDocument FAQ as the first result. One of the questions were: "How can I use NSWindowController as a document browser or inspector?"

It seems relevant. Maybe it'll help.

 

[mduser63]

Searching for NSDocument in the Xcode documentation gave me the NSDocument FAQ as the first result. One of the questions were: "How can I use NSWindowController as a document browser or inspector?"

It seems relevant. Maybe it'll help.

Thanks. I had actually read that, and it wasn't quite what I was looking for. Anyway, I figured it out . You can bind instance variables of the front most document using the keypath "mainWindow.windowController.document.relevantObjectController" with a binding to Shared Application. Put the NSObjectController(s) in the MyDocument nib and set MyDocument to have outlets to them with proper methods so that they can be accessed using Key-Value Coding/Observing and everything works great. I sure do like Bindings, they're just a little hard to figure out how exactly to use sometimes.

 

[gekko513]

Yeah, I agree bindings seems a bit like magic sometimes, they make things very easy, but sometimes it's a bit hard to grasp exactly how to do something or why it works when it does.

 

[mduser63]

Well, I'm having another problem now. When I save a file, I can see that all the expected entity instances get saved into the XML file if I open it with a text editor. However, when I open it using my application, not all of the entities get loaded into the managed object model (as seen by using NSLog to show the registeredObjects returned by the managedObjectModel). I don't understand why some of them are being loaded and others aren't. Any ideas?

 

[gekko513]

The first idea that comes to mind is that the unloaded entities are referenced/related entities that aren't loaded because there's something wrong with the reference, or because it needs to be loaded in a special way to get all the references.

I have no experience with Core Data yet, though, so I'm probably off.

 

[mduser63]

The first idea that comes to mind is that the unloaded entities are referenced/related entities that aren't loaded because there's something wrong with the reference, or because it needs to be loaded in a special way to get all the references.

I have no experience with Core Data yet, though, so I'm probably off.

Well, the main entity I'm concerned with is actually a top-level entity. It has an NSObjectController responsible for it, and it's also an instance variable of MyDocument. After looking more closely at the output of the managed object models registeredObjects method, it appears that the managed object model recognizes that there should be an entity loaded, but it's still a fault:

(entity: stationInfo; id: 0x3aea20 <x-coredata://8A66BB3D-DF6F-45D1-8348-0E404838F6C2/stationInfo/p103> ; data: <fault>)

p103 corresponds to z103 in the XML file, and that is the id for the relevant entity. I added a method to do nothing more than print out an attribute of that entity, and it just shows that it's nil, even after the document has loaded.

 

[gekko513]

I'm sorry, I don't have any good advice on that. Lets hope someone with more Core Data experience notices this thread...

 

[mduser63]

I'm sorry, I don't have any good advice on that. Lets hope someone with more Core Data experience notices this thread...

Well I got an answer elsewhere. For the benefit of anyone finding this thread via a search I'll post what I found out. Core Data entities are not automatically loaded upon opening a document. Those that are controlled by an NSArrayController seem to get automatically loaded, but really the NSArrayController is issuing a fetch request to get its objects. NSObjectControllers do not automatically issue a fetch request, so you have to manually and explicitly issue a fetch request to the managed object context to make it load your entities, then do with them what needs to be done (set as instance variables, give to Object Controllers, etc).