On Jul 25, 2014, at 5:46 PM, SevenBits <sevenbitst...@gmail.com> wrote:
> As you can see on this page (http://stackoverflow.com/a/19219705), an > NSTableView determines whether to be cell or view based based on the > implemented delegate methods. Specifically, if > tableView:objectValueForTableColumn:tableColumn:row is implemented, it is > cell based; if tableView:viewForTableColumn:tableColumn:row is implemented, > than it is view based. If this assumption is incorrect, I’d appreciate a > correction. First, -tableView:objectValueForTableColumn:row: is a data source method, not a delegate method. Second, I don't think the presence of -tableView:objectValueForTableColumn:row: makes a table view cell-based. It is merely the absence of -tableView:viewForTableColumn:row:. It doesn't make sense for two things to be checked for one decision. What if the two conflict? That would be ambiguous. Anyway, NSTableView.h clearly states that -tableView:objectValueForTableColumn:row: is optional for view-based tables. Not all table cell views support the notion of an object value, but if they do then it's set on them. NSTableCellView does have an objectValue and will also forward -setObjectValue: to subviews that respond to it. > But is it possible to use one object as a delegate for both a cell based and > view based table view? No. If the delegate implements -tableView:viewForTableColumn:row: then the table is view-based, as you're aware. The delegate is free to return nil from that method, but that just means the table has no cell view at that location. So, there's no way for the delegate to report back that the table view is supposed to be cell-based. > Each of the methods has a tableView parameter that can be queued to determine > which NSTableView is being referenced, but since the table type appears to be > set by implemented methods, and not a property, I am not sure how to do this. > > I don’t want to use a separate view controller for one of my tables as this > will massively complicate what I am trying to do. Anyone have any easy > suggestions? There's no need for a separate "view controller" if you mean an instance of a subclass of NSViewController. The delegate can be any object that adopts NSTableViewDelegate and implements the required methods for the table type. This object can have a reference to another object (your view controller or whatever). It can query that other object to learn what it needs to know to perform it's duties. Or it can even forward the calls. You can instantiate this other delegate in the NIB, if that helps. If you want it to have a reference to another controller, you can make it an outlet and connect it in the NIB, too. Finally, I'll point out that Apple is officially deprecating cell-based table views. It should be fairly straightforward to convert any cell-based table view to a view-based one, which would avoid this whole question. Regards, Ken _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
