On Jul 19, 2009, at 17:05, I. Savant wrote:
On Jul 19, 2009, at 7:58 PM, Quincey Morris wrote:
... and you'd *still* have to prevent the table view from treating
[NSComboBoxCell] like a text field.
In what way?
Are you referring to the fact that a menu can represent an object,
whereas a combo box is just a (possibly-pre-baked-chosen-from-the-
menu) string? In both cases it's not the NSTableView but your custom
data source that would make these decisions (ie, what that new
"object" that was set really means in that context).
I meant, if you used the NSComboBox methods that told you which item
of the popup list was chosen (e.g. indexOfSelectedItem), you'd know
what was chosen -- if something *was* chosen from the list -- as a
selection index, but the table view would nevertheless set the
underlying string as the value of the property bound to the column.
Storing or using such combo box selection indexes is tricky to do with
a table view, because they don't fit into the bindings *or* the data
source patterns. Even knowing where you might usefully call these
selected item methods is puzzling.
So yes, if you understand that the value corresponding to the column
is a string which *may* match (isEqualToString:, not ==) a list of
strings you separately maintain, then there's no problem.
The easy-to-fall-into pitfall is having the data model property be an
index into an array of (say) state names, but returning the string
name of the state in place of the index when supplying data to the
table view. In that case, changing the string for one row changes that
string everywhere it's used, which is usually not what's intended.
_______________________________________________
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
