Re: "intelligent" flexible popup
Re: "intelligent" flexible popup
- Subject: Re: "intelligent" flexible popup
- From: Daniel Child <email@hidden>
- Date: Tue, 21 Jul 2009 01:16:33 -0400
I seem to have fallen into the pitfall you described below. I can get
the table view to display values in a combo box from a data source,
which takes those values from an array in the model. I also have
autocomplete working.
But I can't seem to get the values I choose to "stick" (remain
displayed) in the table. Since the tableview is reusing the combo box
cell, I don't see how you specify a different value for each row (I
only have one column). (The choice values do appear when you click the
arrow, but selecting them does not store a value.) Also, I'm not clear
on when you "capture" a selection to get the value transferred to the
model.
Are you supposed to use some notification to know that the field has
been edited, and then capture that value and transfer it to the model.
Sorry if this seems basic, but I've looked over the documentation and
some sample code and just don't get it.
Thanks .
On Jul 20, 2009, at 4:38 AM, email@hidden 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 (email@hidden)
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:
This email sent to email@hidden