http://gwt-code-reviews.appspot.com/1619803/diff/7001/user/src/com/google/gwt/user/client/ui/ValueListBox.java File user/src/com/google/gwt/user/client/ui/ValueListBox.java (right):
http://gwt-code-reviews.appspot.com/1619803/diff/7001/user/src/com/google/gwt/user/client/ui/ValueListBox.java#newcode127 user/src/com/google/gwt/user/client/ui/ValueListBox.java:127: setValue(null); I still believe we shouldn't call setValue here, as it will result in two calls to updateListBox. Either the updateListBox() below should be put in an 'else' block (so we either call setValue or updateListBox, but not both; as setValue will call updateListBox for us), or we should assign this.value instead. The only difference is that setValue will set the value as "hasBeenSet", so it depends how we want the following code to behave: box.setAcceptableValues(Arrays.asList(null, "foo", "bar")); box.setAcceptableValues(Arrays.asList("foo", "bar")); On the second call to setAcceptableValues, do we want the value to still be 'null' –and as a consequence change the options in the list box from null/foo/bar to foo/bar/null–, or do we rather want the "uninitialized value" to be "foo" rather than "null". I don't have a strong opinion on this, but to me, as we introduce the concept of "uninitialized state" or "uninitialized value", I think the value should be "initialized" only when setValue is called, and in the mean time, any call to setAcceptableValues could change the current value. http://gwt-code-reviews.appspot.com/1619803/ -- http://groups.google.com/group/Google-Web-Toolkit-Contributors
