SelectItem event to capture the same item selected again?

[JLivermore]

SmartClient Version: v9.1p_2014-10-20/PowerEdition Deployment (built 2014-10-20)
GWT 2.6.1
IE-11

SelectItem - ChangedHandler and ChangeHandler do not fire if you select the same item twice.

I need an event I can tie into specifically for when the user selects the same item for the second time?

[Isomorphic]

ChangeHandler fires when there is a change in the data value, and there is no change in the data value in this situation, so they would not be expected to fire.

We'd suggest first re-examining whether it makes sense for your application to take action when the user does something that's effectively a no-op and does not trigger any action in the vast majority of typical applications.

Also consider accessibility - if re-selecting the same item triggers something, how do you do that with a keyboard - press up then down again?

If this action triggers some kind of "refresh" or similar, you are probably better off with an actual button that can be pressed to trigger it.

Finally, if you really want to pursue your current approach, you could add something like a ClickHandler or MouseDownHandler to the pickList via pickListProperties.

[JLivermore]

We do have a very specific case the SelectItem being a range of dates, and the last option is a custom date selection. It is the last custom date selection (the no-op) where I need to capture the custom dates in a custom dialog. So in this case, they could select another custom date again from their current custom dates. So this translates to the same value being selected again, which is what I need to tie an event to capture the custom date again.

Thank you for the pointer to MouseDownHandler, but the Javadoc does not mention MouseDownHandler for SelectItem?

[Isomorphic]

Again you'd be adding a MouseDownHandler to the pickList via pickListProperties.

But if what you're doing is launching a modal dialog or similar to allow specialized date input, there are simpler solutions, like just marking the item as no longer selected after the user has entered data in the dialog, launching the dialog from a button instead of rolling it into the select, various things like that.

Again it's odd to have to select something that is already selected, in most other applications, that would do nothing.

[JLivermore]

The MouseDownHandler is called before the value actually get's set in the SelectItem:

ListGrid pickListProperties = new ListGrid();
        pickListProperties.addMouseDownHandler(new MouseDownHandler() {
            @Override
            public void onMouseDown(MouseDownEvent event) {
                GWT.log("TimeFrameWidget.PickListProperties.MouseDownHandler");
                GWT.log("previousValue : " + previousValue);
                GWT.log("        value : " + timeFrameWidget.getValue().toString());
                
                }
            }
        });
        this.setPickListProperties(pickListProperties);

This pickListProperties is a ListGrid. Can I leverage any Event associated with the ListGrid for the SelectItem when setting the pickListProperties? I would like to find another Event that gets called after the SelectItem is set? Unless there is a way to access the new value that is set from the MouseDownHandler.onMouseDown(MouseDownEvent event)? When I do a event.getSource(), the source is the ListGrid, so I'm not sure how to get the new value for the SelectItem?

Perhaps the way to go would be to call a deferred command in the MouseDownEvent that will be called after the SelectItem value is set and then check the new value? This seems to work.

[Isomorphic]

Generally, you can use events on AutoChildren so long as you don't interfere with default event handling. It's best to be circumspect here and not install a huge number of handlers that cancel events and so forth, as you could interfere with default behaviors. We give some more detailed guidelines in the AutoChildren overview.

Using ListGrid APIs like getEventRow() you could figure out what was clicked. A DeferredCommand is also fine. Or, just for completeness, you could use any of the previously mentioned alternatives, which avoid the issue with having to detect selection of an already-selected row.

[JLivermore]

Thanks for the follow up and more details. AutoChildren is new for me, I will read up on that.