Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>I typically do not recommend bindings, and definitely not complicated bindings, to new Cocoa developers. Bindings have the unfortunately situation of tending to "do nothing" when they are the least-bit misconfigured. This makes them very difficult to debug, even for experienced developers. Bindings work very well when dealing with a big page of configuration options tied to <code>NSUserDefaults</code>, but they're a pain to build a complicated UI out of.</p> <p>That to the side, your setup seems very odd. The owner of <code>MainMenu.xib</code> should almost always be a <code>NSApplication</code>. Instead of what you're doing, you should drag a new <code>NSArrayController</code> onto your XIB and wire it up as you've described, but not make it the file owner.</p> <p>I would expect that you're seeing exceptions in your log. Probably "<code>NSArrayController</code> does not respond to selector <code>setDelegate:</code>" or the like. If you're seeing this, it's because the default <code>MainMenu</code> nib file is configured to wire the application delegate to the file owner.</p> <hr> <p>First, just a little quote from the <a href="http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/TableView/PopulatingViewTablesWithBindings/PopulatingView-TablesWithBindings.html" rel="nofollow">Apple docs</a> to reinforce the point about bindings:</p> <blockquote> <p>Populating a view-based table view using Cocoa bindings is considered an advanced topic. While it requires significantly less code (in some cases no code at all), the bindings are hard to see if you are not familiar with the interface. It is sternly suggested that you are comfortable with the techniques for using view-based table views programmatically before you move on to Cocoa bindings.</p> </blockquote> <p>I love the word "sternly" in this section. After years of development with and without bindings, I tend to avoid them except in the simplest of cases (like preference panels, where they're incredibly useful).</p> <p>Without bindings, you would follow the instructions in <a href="http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/TableView/PopulatingView-TablesProgrammatically/PopulatingView-TablesProgrammatically.html" rel="nofollow">Populating View-Based Table Views Programmatically</a>. Basically, you will implement <code>numberOfRowsInTableView:</code> and (assuming 10.7+) <code>tableView:viewForTableColumn:row:</code>. For each row and column you return a view containing the data you want. This is taken from the iOS way of doing things and is very nice and extremely flexible.</p> <p>If you need pre-10.7, then things are slightly more complicated, but still more straightforward than bindings. See <a href="http://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/TableView/PopulatingCellTables/PopulatingCellTables.html" rel="nofollow">Populating Cell-Based Table Views</a>. This uses <code>NSCell</code> rather than <code>NSView</code>. If you just need a simple table displaying string-like data, it's not hard. Just implement <code>numberOfRowsInTableView:</code> and <code>tableView:objectValueForTableColumn:row:</code>. The latter should return something that can be coerced into a string.</p> <p>If you need a custom <code>NSCell</code> for pre-10.7, try it out on your own using the docs, and then you'll probably have some new questions to post.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload