PDA

View Full Version : (Beta) ComboBox issues



DarekKay
8 Dec 2011, 3:38 AM
First of all - thanks again for all the fixes in beta. Now I found another two ComboBox issues:

1.) onValueChange-event doesn't fire automatically after selecting an item (you have to press return to achieve this)

2.) ComboBox.setEnabled(false) makes the TextField disabled, but you can still select other items and change the value by pressing the arrow.

madmaxmatze
11 Dec 2011, 4:05 AM
With Dev Preview 5 this problem was not existing. My current workaround is to use the CollapseHandler.

The issue can be tested using:

LabelProvider<String> comboLabelProvider = new LabelProvider<String>() {
@Override
public String getLabel(String item) {
return item;
}
};

final SimpleComboBox<String> comboBox = new SimpleComboBox<String>(comboLabelProvider);
comboBox.setTriggerAction(TriggerAction.ALL);
comboBox.add("value1");
comboBox.add("value2");
comboBox.add("value3");
comboBox.add("value4");
comboBox.addValueChangeHandler(new ValueChangeHandler<String>() {
@Override
public void onValueChange(ValueChangeEvent<String> event) {
Info.display("ValueChangeHandler", "new Value: " + event.getValue());
}
});
comboBox.addChangeHandler(new ChangeHandler() {
@Override
public void onChange(ChangeEvent event) {
Info.display("ChangeHandler", "new Value: " + event.getSource());
}
});
comboBox.addCollapseHandler(new CollapseHandler() {
@Override
public void onCollapse(CollapseEvent event) {
Info.display("CollapseHandler", "new Value: " + comboBox.getCurrentValue());
// workaround to force trigger of ValueChangeHandler
// comboBox.setValue(comboBox.getCurrentValue(), true);
}
});

RootLayoutPanel.get().add(comboBox);

DarekKay
20 Dec 2011, 5:04 AM
With Dev Preview 5 this problem was not existing. My current workaround is to use the CollapseHandler.

I use that workaround, too. But is there any possibility, this one gets fixed?

EthiC
23 Dec 2011, 6:02 AM
Any word about the ComboBox not firing the valueChangeEvent untill focus is lost?

Added to that, if I do a: (the 2 booleans can be omitted)


comboBox.setValue(comboBoxValue, true, true);

The event is fired as it is supposed too, but the combobox itself still displays the empty message, instead of the selected value.
<-- solution was to remove the statement setting the empty text

sven
23 Dec 2011, 6:25 AM
Any word about the ComboBox not firing the valueChangeEvent untill focus is lost?


That is the expected behaviour as with any other field too.

EthiC
23 Dec 2011, 6:41 AM
Thank you for your quick reply.
In 2.x we used a SelectionChangedListener on the ComboBox and that did fire that event after selecting the item with the mouse.
I guess we'll use the CollapsedHandler then for this situation.

sven
23 Dec 2011, 7:30 AM
You should be able to get the ListView from the ComboBox instance, get the selection model and on that you can listen to the SelectionChangedEvent

EthiC
23 Dec 2011, 8:24 AM
Doesn't seem to work for me:
The selectionModel's selectionChangedHandler and selectionHandler receive events when the list is openened and if an item is being hovered. (selectionChangedHandler seems to even break the combobox when used (in debug mode + Chrome))
I only need the actual click event, which doesn't trigger an event in these cases.

ListViewSelectionModel<Breakdown> selectionModel = presenter.getView().getTitleComboBox().getListView().getSelectionModel();
selectionModel.addSelectionHandler(new SelectionHandler<Breakdown>() {
@Override
public void onSelection(SelectionEvent<Breakdown> event) {
System.out.println("on selection " + event.getSelectedItem() + " type: " + event.getAssociatedType());
}
});

sven
23 Dec 2011, 8:42 AM
Sorry i was wrong. It uses an event preview internly. You will need to use the same kind of logic. Take a look at init(ListStore<T> store) of ComboBoxCell

XGhost
5 Jan 2012, 7:43 AM
Guys,

Is there another way to execute some logic right after user has changed ComboBox value? I've got ComboBox and Grid on my page and I need to refresh Grid data every time user changes ComboBox value.

I can understand that comboBox.addValueChangeHandler(...) works only when comboBox losts a focus. Is there any simple way to handle select event for ComboBox?

sven
5 Jan 2012, 7:48 AM
Extending ComboBoxCell and overriding onSelect is also a solution.

Selecting something in the dropdown would fire the CollapseEvent event. So depending on your application, that maybe also a solution

XGhost
5 Jan 2012, 7:57 AM
Thanks Sven.

A bit unexpected but it works.

Could you please help me with one additional problem:

I'm adding combobox data to the store. After it I need to make the first item selected. Currently I'm doing the following magic:

store.addAll(data.getPeriods());
periodsComboBox.clearSelections();
periodsComboBox.setValue(data.getPeriods().get(0));
periodsComboBox.setText(data.getPeriods().get(0).getName());

Is there any simpler way to preselect one of the Combobox items?

nomad
12 Jan 2012, 8:39 AM
ComboBoxCell class is missing constructor which accepts custom appearance. Is there any workaround for this?

arkadye
13 Mar 2012, 2:51 PM
All solutions proposed above are hacks.

In GXT 2.2.5 ComboBox had the following functionality:

ComboBox.addSelectionChangedListener() - ability to listen for selection change events, which were fired both when user made a selection in the drop down and when ComboBox.select() or ComboBox.setSelection() methods were invoked programmatically.
ComboBox.select() and ComboBox.setSelection() - ability to select an item programmatically, which will populate the combo box field with selected value and fire the SelectionChanged event.

We need this functionality in GXT 3.0 as well. Please implement it before the release.

Thanks in advance.

Arkady.

donp
30 Mar 2012, 8:59 AM
I agree that the proposed "solutions" are absolutely not solutions, and that those workarounds could be characterized as hacks.

The more important point here is what a standard and reasonable expectation would be of the API. It would be reasonable to expect that when a combobox selection changes, the SelectionChangedEvent would fire. That is not what is happening according to the previous posters.

The combobox selection changes when a user selects an item in the combo list. While this is similar to the CollapseEvent, it is not the same, and that is why relying on CollapseEvent would be a hack. Users have other ways of making a selection than this.

This needs to be fixed in a robust way, so that the API conforms to normal and reasonable expectations of behavior.

Thanks,
Don P.

WesleyMoy
3 Apr 2012, 1:54 PM
ComboBox now fires SelectionEvent when an item in the drop down list is selected. This allows you to react to the user choosing an item from the drop down list without waiting for the user to move focus away from the combo box.

Look for this change in the Release Candidate build.

arkadye
3 Apr 2012, 2:38 PM
This is great, thanks.

Now the only remaining issue is to fix the select() APIs to trigger the selection programmatically.

Best regards,

Arkady.

WesleyMoy
3 Apr 2012, 6:41 PM
What behaviour is it exactly that you're expecting from ComboBox.select? Specifically, under what situation do you plan to use ComboBox.select such that you're not setting a new value anyway (at which point, you should use ComboBox.setValue)?

In Ext GWT 2, ComboBox.select does not fire the SelectionEvent, so we are not unintentionally omitting the event from ComboBox.select in Ext GWT 3. In fact, you will notice this in the JavaDoc comments for each:



* Select an item in the dropdown list by its numeric index in the list. This
* function does NOT cause the select event to fire. The list must expanded
* for this function to work, otherwise use #setValue.


This is because ComboBox.select selects (highlights) one of the items in the dropdown list. It doesn't dismiss the list the way a user would when the user clicks on an item. If you would like for an expanded drop-down list to be dismissed, again consider using setValue (after calling collapse to dismiss the dropdown list).

aron-soartech
9 Apr 2012, 1:42 PM
ComboBox now fires SelectionEvent when an item in the drop down list is selected. This allows you to react to the user choosing an item from the drop down list without waiting for the user to move focus away from the combo box.

Look for this change in the Release Candidate build.

Using gxt-3.0.0-rc.jar, the event is fired, but the ComboBox still doesn't return the correct value until focus is lost on the widget.



cb.addSelectionHandler(new SelectionHandler<String>() {
@Override
public void onSelection(SelectionEvent<String> event) {
cb.getSelectedIndex() //returns -1
cb.getSelectedText() //returns ""
cb.getValue() //returns null
}
});


Is this the expected behavior?

arkadye
9 Apr 2012, 1:52 PM
event.getItem() returns you the selected item.

Best regards,

Arkady.

aron-soartech
9 Apr 2012, 2:19 PM
Why cant I read the value off the ComboBox itself?

If the selection changed event has fired, then does it not logically follow that calling getSelectedIndex() etc on said ComboBox should return the expected value?

I call that a bug, or at the very least a poorly coded ComboBox implementation.

Either the selection has changed or it hasn't. Which is it?

But thanks for the help Arkady!

kenhwallis
11 Apr 2012, 2:55 PM
The underlying issue is that Sencha fires a Selection event but it's not the GWT Selection event; it's their very own version. It doesn't have the same API or class hierarchy.

Their change is an undocumented modification to the API and it breaks implementation code.

ref: http://www.sencha.com/forum/showthread.php?193170-(3.0.0.RC)-Broke-ComboBox-API-regarding-Handler-Event-inheritance

Colin Alworth
13 Apr 2012, 3:18 PM
All inputs in html only fire change events after they have been blurred. GWT follows these same basic semantics, as does GXT - the ValueChangeEvent denotes that the user has finished editing the field, and has left it.

That said, ValueBaseField also supports a getCurrentValue() method that attempts to read from the field while it is still being edited. This isn't implemented for all Fields - it doesn't always make sense to expect a value to be read out at any time - but for fields usually implemented with an text input (i.e. ValueBaseFields), it is possible to read out the value, parse it, and return it through getCurrentValue().

Selection is a slightly different matter - we use this event to indicate that the user has made some interaction with the field, using the keyboard or mouse, and wrap these physical interactions up to be a logical intent. It is possible to use a SpinnerField or ComboBox without causing Selection events (only typing in the input), and it is possible to cause selection events with the mouse and keyboard (usually arrow keys). These are discrete changes to the field's state, but not yet value changes (which, as mentioned above, involve a blur). More precise physical events can be detected by adding Click or Key handlers to the widget as well.

All GXT Fields that can be used in a Grid or other data widget are implemented using Cells - this is done to make them usable in any cell widget, whether written by Google, Sencha, or any other GWT-based library. This is a somewhat restrictive API, and its limitations have introduced interesting issues in how we still support GXT 2 functionality, and leave room for teams using GXT to go forward and build even more features. One of the chief ways that widgets are often improved and augmented is through events, but making events consistent with the ability of a Cell to be rendered in many places at once can be difficult. GWT doesn't address this at all, so we generally use the HandlerManagerContext to allow a cell to dispatch events out through the Field that wraps it, or, if no HandlerManagerContext is available, to fire just from the cell itself.

GWT's own SelectionEvent is written such that you must use a static method to fire it - there is no way to ask it to be fired from multiple sources, as can be done with almost all other events. Our first attempt to deal with this was to copy the class and change its implementation to be like other events, able to be constructed and fired normally, but from discussions with the community, we took the approach of extending GWT's SelectionEvent as CellSelectionEvent - firing in much the same way, but able now to be dispatched to multiple sources. This has now been released as part of RC2.

So in conclusion, changing value doesn't necessarily imply that selection has occurred, nor does selection imply that the user has finished and left the field. We try to be deliberate in our API choices, especially where we are going beyond what stock GWT events and APIs generally make possible, and we welcome and try to respond to community feedback.

If you are able, I would welcome you to join us on irc.freenode.net in #extgwt to continue this discussion, or others. Not all organizations (or schedules) permit IRC, so we'll of course also continue these discussions on the forums as well.

donp
19 Apr 2012, 9:45 AM
Hi Colin,

Thanks for the reply on this.

We recently installed teh GXT RC2 build, and now see some behavior that shows further problems related to this issue.

Please take a look at this:

http://www.sencha.com/examples-dev/#ExamplePlace:combobox

Select an item (for example, Arizona) from the first list, and then observe what happens to the ComboBoxCell display value on blur of the ComboBox. The display value changes from the intended display text to what appears to be a toString() of the cell's object, resulting in an object reference string being rendered in the cell, instead of the normal display value.

Does this look like a bug?

Thanks,
Don P.

Colin Alworth
19 Apr 2012, 10:16 AM
Yep, its a bug, filed at http://www.sencha.com/forum/showthread.php?195272-ComboBox-Major-issue-with-RC2-(shows-up-in-explorer-demo-too and http://www.sencha.com/forum/showthread.php?195197-RC2-ComboBox-LabelProvider-not-used-consequently and it has been fixed. You should not be able to reproduce this at http://staging.sencha.com:8080/examples-dev/, our nightly build.

There is another combo issue still open, causing exceptions in Firefox, posted at http://www.sencha.com/forum/showthread.php?195925 - the fix for this has been committed, but a nightly build has not yet been pushed with this new code.