[REVIEW REQUEST] Committing ComboBox text input to the value property on focus loss

[Slavko Scekic]

JavaFX needs a good form validation framework, and needs it fast. Without
starting another conversation about that issue, I'll just say that this
ComboBox thing could be easily resolved inside such a common validation
framework.

In the meantime, a simple CSS style class assigned to an ComboBox which
holds an invalid value could solve the problem. The style class name could
be arbitrary (developer assigns it via API) or it could be hard coded, but
the developer can customize it in his CSS (which I think is easier to
implement).

On Thu, May 24, 2012 at 4:21 PM, Tom Eugelink <tbee at tbee.org> wrote:

> Personally I would vote for showing the actual value on focus lost, or not
> allow the control to lose focus at all.
>
> Keeping an unparsed input visible could create the suggestion to the user
> that the content actually is parsed. After losing focus, the control is in
> some kind of twilight state, where the value it represents is something
> different from what it is showing the user. Theoretically one could have a
> form filled with controls all showing something different than their value,
> and upon submitting the form one would be writing entirely different data.
> A very unwanted scenario.
>
> This twilight state can only be if it is visually very clear to the user,
> like for example a big red shiny border and integrated into whatever submit
> mechanism is used ("there still are errors on the screen"). Since that is
> not the case, you should really revert to the actual value on focus lost.
>
> Tom
>
>
>
>
> On 2012-05-24 00:56, Jonathan Giles wrote:
>
>> In both cases, assuming invalid input is put into
>> StringConverter.fromString(**String), and we signal this by returning
>> null, the value property is not changed, and the text typed into the
>> ComboBox remains as it was - with the invalid input still in place.
>>
>> Ideally in a future release when we have validation support this would be
>> the point where the ComboBox would indicate an invalid input has been
>> received (most probably due to a typo or a user trying their luck with
>> invalid input).
>>
>> -- Jonathan
>>
>>
>> On 24/05/2012 10:51 a.m., Richard Bair wrote:
>>
>>> OK, so:
>>>
>>> User types invalid input, hits enter. What happens?
>>> User types invalid input, tabs out. What happens?
>>>
>>> Cheers
>>> Richard
>>>
>>> On May 23, 2012, at 2:54 PM, Jonathan Giles wrote:
>>>
>>>  Hi all,
>>>>
>>>> The jira issue for the runtime bug is here:
>>>> http://javafx-jira.kenai.com/**browse/RT-21454<http://javafx-jira.kenai.com/browse/RT-21454>
>>>> The jira issue for Scene Builder is here: http://javafx-jira.kenai.com/
>>>> **browse/DTL-4415 <http://javafx-jira.kenai.com/browse/DTL-4415>
>>>>
>>>> I'm hoping to make a slight behavioural change to ComboBox in 2.2 so
>>>> that it acts in a more useful manner. Currently, in an editable ComboBox,
>>>> the value property is only set when the user presses Enter. What RT-21454
>>>> asks for is that the value property also be updated when focus is lost.
>>>>
>>>> If we don't make this change, the form developer has to consider either
>>>> forcing an event to commit the value, or getting the ComboBox editor (which
>>>> is new API in 2.2), and retrieve the text out of there. Of course, this
>>>> will burn every developer until they test their form and realise the value
>>>> property is not set.
>>>>
>>>> Therefore, I would like to make a small change to ComboBox such that
>>>> whatever the user has typed when focus is lost becomes the new ComboBox
>>>> value (assuming it is legal input to the StringConverter). There is a patch
>>>> attached to the runtime jira above which makes this change, but does not
>>>> change any API: this is purely a behavioural change to make ComboBox more
>>>> useful.
>>>>
>>>> Thanks,
>>>> Jonathan
>>>>
>>>
>