Reputation: 17677
I have a NSTableView with the delegate and datasource pointing to my controller. I have tried implementing the
- (id)tableView:(NSTableView *)aTableView objectValueForTableColumn:(NSTableColumn *)aTableColumn row:(NSInteger)rowIndex
Method, but no matter what I return, the table always shows "Table View Cell" in the data. Any ideas of what I could be doing wrong? Attached are two pics showing that I have the delegates set properly (it also shows the proper number of rows).
Note that I have also just tried returning @"Hello World"
for everything, but I get the same result.
Upvotes: 35
Views: 11074
Reputation: 329
Most of the responses involve converting the table view component to a cell-based table view. If that’s what you want then that’s fine, you’re good to go. At the time the question was asked, cell-based tables were the norm and when Apple changed the window component to a view-based one it obviously caused a lot of confusion. Today, Apple’s docs recommend that you should use view-based rather than cell-based tables.
The problem described in the question arises if you use - tableView:objectValueForTableColumn:row:
in your datasource. You cannot use this method with view-based tables, it is only for cell-based tables. Instead you need to use the NSTableViewDelegate
method - tableView:viewForTableColumn:row:
. You don't need to make the object conform to the NSTableViewDelegate
protocol to use this method but it must be set as the delegate of the table.
In response to Cœur, quoting from the Apple On-line docs.
NSCell-Based Tables Are Still Supported In OS X v10.6 and earlier, each table view cell was required to be a subclass of NSCell. This approach caused limitations when designing complex custom cells, often requiring you to write your own NSCell subclasses. Providing animation, such as progress views, was also extremely difficult. In this document these types of table views are referred to as NSCell-based table views. NSCell-based tables continue to be supported in OS X v10.7 and later, but they’re typically used only to support legacy code. In general, you should use NSView-based tables.
Upvotes: 10
Reputation: 227
Newer version of XCode:
Upvotes: 9
Reputation: 604
Just change the Content Mode
to Cell Based
for the table view in IB. IB will display Text Cell
as the cell placeholders, which are populated at runtime by whatever you return from tableView:objectValueForTableColumn:row:
Upvotes: 58
Reputation: 17677
Finally figured it out. My cells for some reason seem to contain both a TableCellView AND a text field cell. I removed the Table Cell View
's and now everything is working. I have no idea how I got in that state.
Upvotes: 11
Reputation: 22948
It looks like you might be missing the all-important -numberOfRowsInTableView:
data source method. See Table View Programming Guide: (View-based table view) The Required Methods and Table View Programming Guide: (cell-based table view) Providing Data To a Table View Programmatically for details.
Basically, the very first NSTableViewDataSource
method that's called is numberOfRowsInTableView:
. Only after you return a non-zero quantity from within that method will the subsequent tableView:objectValueForTableColumn:row:
or tableView:willDisplayCell:forTableColumn:row:
methods be called.
Upvotes: 0
Reputation: 3975
You're misunderstanding how the result of -tableView:objectValueForTableColumn:row:
is used by the frameworks.
To do more-or-less what you're trying to accomplish above, override the delegate method -tableView:willDisplayCell:forTableColumn:row:
instead. Here is an example cribbed from one of my own apps:
- (void)tableView:(NSTableView *)tableView
willDisplayCell:(id)cell
forTableColumn:(NSTableColumn *)tableColumn
row:(NSInteger)row;
{
NSString * displayName = [self.senders objectAtIndex:row];
[cell setTitle:displayName];
[cell setState:[self.selection containsObject:displayName]];
}
This is the "old school" way, using cell-based tables (which are still the default).
Upvotes: -1