Picker: how to determine if user picked a value or canceled

[Thomas]

What event should I listen to on a picker to be able to determine the new value choosed by the user? Because the ActionListeners are trigerred only if the user confirmed a value (so it is not if it canceled) and the focusLost() method of focusListeners is actually triggered in any cases but before the new value is set (so if picker value was A previously and user choose B and confirmed, if we call picker.getValue() in the  focusLost() method of focusListeners, it will return A...)

[Shai Almog]

We don't have consistent behavior for cancellation at the time because of all the platform differences. The value should remain as it was before if the user canceled so the official way to work is to use the action listener and ignore cancellation events.

We might provide more nuanced event/behavior when we migrate to the lightweight picker implementation.

[Thomas]

The problem is that the action listener is not triggered on cancellation events. So I have no way to determine that the user finished to act with the picker if he cancelled its action...

[Shai Almog]

If the picker was opened and no action event was sent then it was probably canceled. No?

Up until recently the workaround for this was to launch the native picker directly from the display class. But we are transitioning to the lightweight picker so that might not be the best approach.

[Thomas]

Yes but how can I determine exactly when it is canceled (as I need to perform some action immediatly after this cancel event)? 

After the picker was opened, the user can take  1, 2, 3, 4s... 1min... to actually cancel or confirm it. And, without any cancel event fired, I have no way to determine when this happen if the user choose to cancel it (I can't know if he is still in the picker dialog or actually already canceled it)...

[Shai Almog]

The only workaround I have for that right now is the old workaround of using the native picker API directly, since that API is synchronous you know when it ended.
When we have a more stable lightweight implementation it will make sense exposing it this way.