How can I select value in ComboBoxItem?

[muxa4epen]

Hi, I use SmartGWT2.0.
I have ComboBoxItem with values: id, name.
In ListBox at GWT I could use methods:
getItemCount(), getValue(index), getItemText(index), setSelectedIndex(index).
But I need something like this in ComboBoxItem.

I need this methods to perform selection of record by given id or name in ComboBoxItem.

Can anybody help me?

[svjard]

setValue()

[shortpasta]

I observed this -- any ideas?

When I do a setValue, the ComboBox edit box shows the right selection, but when I click the "Down arrow", the list of selections shows up, but right value is not highlighted: instead the first value is always highlighted.

On the other hand, getValue () returns the value from the edit box and not the one highlighted...

Using SmartGWT 1.3 / GWT 1.7

[muxa4epen]

setValue()

Thanks. But it really don't highlight correct value when you open the list.

How can I iterate through all records in the list?
And is there any method like selectValue() instead of setValue()?

[Isomorphic]

@shortpasta This works in samples (and in countless applications), please show a standalone test case where the behavior is incorrect if you believe you've found a bug

@muxa4epen setValue() has the behavior that you are expecting from your (fictitious) method selectValue(). Something is wrong with your code. Make sure you are passing a value for the declared valueField on the SelectItem, and check that the letter case of the value is correct.

If you want to manually work with the data (such as iterate through all values in the list), you can call DataSource.fetchData() directly, and use the RecordList available from the DSResponse to iterate down all records. This will not help you select a record, which would work if your code were correct.

[shortpasta]

Here is a sample showing the behavior we have described and how we think that it does not work -- it may very well be that this is just how you designed it:
http://www.smartclient.com/smartgwt/...bobox_category

Note that the ComboBoxItem does not select the proper item, while SelectItem does.
I can understand how ComboBoxItem, being editable, does not select the matching text, but in that case, I think it should at least not select the wrong text, as it seems to always select the first item...

And the code:

ComboBoxItem cbItem = new ComboBoxItem();  
        cbItem.setTitle("Select");  
        cbItem.setHint("<nobr>A simple ComboBoxItem</nobr>");  
        cbItem.setType("comboBox");  
        cbItem.setValueMap("Cat", "Dog", "Giraffe", "Goat", "Marmoset", "Mouse");

[Isomorphic]

@shortpasta That's not selection, it's rollover (try hitting up and down keys or hovering over the combobox). It indicates what will be selected if you hit Enter. It's at the top because people place the most common values at the top.

[shortpasta]

Rollover works, but when I click the "Down arrow", the proper item is not selected.

I have attached a screenshot to illustrate this.
The first image shows the rollover working as you described.
The second image shows the "Down arrow" clicked, and the pick list does not reflect the proper selection.

I think that independent of the original design, the ComboBoxItem behavior should be that when the "Down arrow" is clicked, and an exact match is found in the pick list, it should be highlighted.
What do you think?

[Isomorphic]

No, that's not a good idea because the matching value is the least likely choice for the user, and may be scrolled offscreen, and may require specialized data fetches to retrieve in the databound case. Furthermore, highlighting the already selected value is redundant with the information already displayed in the combobox.

[shortpasta]

Fair enough...
According to the docs, both SelectItem and ComboBoxItem support loading from DataSource, so why the different behavior between the two? Does that mean that SelectItem does the scrolling and specialized fetching for the databound case while ComboBoxItem does not?

[ccocco]

When a drop-down list is expanded/shown (e.g. a down arrow button is clicked), it should always show the currently selected item as highlighted. Users expect this and I've never seen a combo box work differently. This is a typical UI standard. The selection should always match the item displayed in the edit box.

[Isomorphic]

If you think so, then you should perhaps address all the concerns listed in point #9.

[ccocco]

Sure, post 9 comments:

"No, that's not a good idea because the matching value is the least likely choice for the user,"

ccocco: Typical UI standards for drop-down lists are displaying 3 choices minimum and 8 choices maximum at once. If the list contains more than 8 choices, a vertical scrollbar should appear. Using the keyboard, the user can navigate to the drop-down arrow, select it to display the list, and then use the arrow keys to move up and down based on the current selection. If the list is very large, they would easily become annoyed trying to navigate to the last selection if they wanted to choose one near it for choices grouped in a common fashion, or if they selected the incorrect one initially (e.g. the one before it or after it), which isn't hard to do.

"and may be scrolled offscreen"

ccocco: The drop-down list should always scroll the selected choice into view when the down arrow is clicked to display the list.

"and may require specialized data fetches to retrieve in the databound case. "

ccocco: This is a tough call. For large, performance intensive lists of values, a paging paradigm should be used to fetch partial values initially and then incrementally as the scrollbar is clicked or dragged. On the other hand, the design should be considered if a list has so many values that it takes more than 7-8 seconds to populate and display (this is the amount of time a user can wait before losing attention).

"Furthermore, highlighting the already selected value is redundant with the information already displayed in the combo box."

cccocco: It's not redundant, it provides context to the user as to where they are in the list of choices. It also reflects the current selected value in both the list and the edit box. The user can become confused as to why a different value is selected in the list than what is reflected in the edit box, as a selection in a list (e.g. containing a highlight) implies that a particular choice is currently selected (chosen) one.

[Isomorphic]

This seems to be a restatement of what was already covered?

In a nutshell, in the one case where it would be of benefit to the user to select the previous value - a large list of items where the user might want to make an adjacent selection - the current behavior already hilites the previous value. Try it - open a databound comboBox, scroll, select something, re-open it.

If the ComboBox is databound and is pre-populated with a value, ensuring that the record for that value is present in the list would require a specialized and expensive DataSource operation (select a range of records where a field contains a specific value). We could add support for a DataSource to advertise that it supports this special variant of fetch, and allow you to enable it's use in the ComboBox, but that hardly seems worth it - in practice, when replacing an existing value, most users type something in.

Maybe the case you're concerned about is a very large list of values that is *not* being provided via databinding?

[ccocco]

Quite a few questions were asked along with what I thought the primary issue was, that being that a non-databound ComboBoxItem always sets the selected list value to the first one instead of the one previously selected and ultimately displayed in the edit box.