Question

I m wondering how one would implement an outline view like the one Xcode 3 is using for the build configuration:

When using an NSOutlineView/NSTableView with bindings and an NSTreeController/NSArrayController, the view s columns get bindings assigned to, not the individual cells, for obvious reasons. If every row in a column uses the same cell, then it s a piece of cake. However if every row (potentially) uses its own cell type (and with that potentially its very own collection of bindings), then things get funky.

Looking at the screenshot one can clearly see that the textfield cell needs just a single binding for "value". While the popup button cell needs at least one for "content", one for "contentValues" and last but not least one binding for "selectedIndex / selectedObject / selectedValue". And the checkbox cell needs a binding for "value" and (probably) one for "title".

How would one accomplish this with as clean (and little) code as possible?
(Or as one might ask: How would Apple have done it?)

…

Here s what I ve tried myself so far:
I provide the appropriate (copied) cells via [outlineView:dataCellForTableColumn:item:] and bind them to the individual data models (from [item representedObject]). I know the exact amount of data (< 500 rows) being displayed in the outline view, so having one cell per row shouldn t be too much of a memory issue, no? I got the data to get displayed properly via bindings (yay!) however I m unable to change any of their values. O_o Apparently the value change simply never gets thru to the data model. Is there more to it than a simple [checkboxCell bind:@"value" toObject:rowModel withKeyPath:@"value" options:nil]? (as this seems sufficient for getting values, but not for setting them accordingly.)

I couldn t find any information on this topic. Lots of info and hints for using custom cells per column, but none for using them on a "per row" basis. :(
This would make some great stuff for a Cocoa tutorial, wouldn t it? ;)

Answer 1

The data cell of a column isn t copied. The cell is configured for the proper value for the column in each row and drawn in its proper place. A good place to hook in is at the NSTableColumn method -dataCellForRow:. In a custom subclass, you could override this method and pass either its -dataCell for normal operation or some alternate cell type.

I had an occasion to have a checkbox column representing "include" in an outline view that only appeared for children (non-root items). The root items couldn t be excluded, only their children, so it made sense only to show the checkbox for non-root items.

I created a custom NSTableColumn subclass that took a delegate (my data source controller) and checked to see if it responded to the selector -deadCellColumn:shouldShowDeadCellForRow:. If it did, I called that method (which was implemented on my data source controller) to ask it if I should show a "dead cell" (a basic NSCell subclass that draws nothing) and swapped it according to the answer. If the delegate didn t respond to the selector, the table column returns its normal -dataCell.

The custom cell (which I called "DeadCell") was needed here because I wanted to ensure nothing got drawn and nothing was editable. I m not sure it was strictly necessary but I did it anyway. This isn t much use in your case, but I wanted to state it anyway for completeness.

Your situation is a bit more complicated, especially because Bindings are involved (and different data cell types can have different bindings for their value -- popups can be especially challenging). In my case, I eschewed bindings for the tried-and-true data source mechanism. It simplified things greatly. :-) For your case, it s easy enough to swap cell types around using data source methods.

友情链接