On Tue, 15 Sep 2009 10:05:09 pm Greg Brown wrote: > OK, that helps. it sounds like you are wrapping a "detail" or "lookup" > table in an instance of DataContext to populate a list button in a > table view editor - is that correct?
Yes it is a lookup table being referenced by the ListButton but a DataContextList is used for the ListButton.listData and it provides DataContext instances to the ListButton as the list items. > You are then passing an instance > of DataContext representing a row in the master table to > ListButton#setSelectedItem(), and using the foreign key in the master > row to identify the value in the list button to select? Yes an instance of DataContext is passed to ListButton.setSelectedItem() from invoking TableViewRowEditor.edit(). The DataContext only represents a single field though because there can be multiple foreign keys. > Only the > foreign key value is initially set to null, so you actually want to > clear the selection in the list button, but you can't because of how > ListButton currently works. Yes? Exactly right. > I think you mentioned that your DataContextList class (which you use > as the list data for the list button) is coded to return -1 in this > case. Yep, the Pivot docs say to return -1 if an item can't be found in the list. > If so, that would translate to clearing the selection if > ListButton was modified so that it doesn't throw in this case. I think > it is probably OK to make this change. I just looked at the Swing docs > for comparision: > > http://java.sun.com/javase/6/docs/api/javax/swing/JComboBox.html#setSelecte >dItem(java.lang.Object) > > JComboBox#setSelectedItem() does not throw when the given item is not > in the list. It simply leaves the selection state as-is, which I don't > think is the right behavior. However, clearing the selection certainly > seems valid. > > Unless there are any objections, I will make this change. No objections what so ever :-)
