Committing (rather than cancelling) cell changes on focus loss

[Jonathan Giles]

This was by (UX) design, but that does not always mean it is right. As 
usual, file issues and we can discuss what the default should be.

-- Jonathan

On 26/01/16 8:47 PM, Konstantin Pasko wrote:
> Hi,
>
> speaking about UX and TableView / TreeTableView:
> I've "discovered" a strange behaviour of those controls, that differs 
> from Swing JTable or WPF's Datagrid.
> When I selected a row and then removed it -- another row gets selected 
> (JavaFX).
> When I selected a row and then removed it -- nothing is selected any 
> more (JTable & WPF).
>
> Is it by design or should I file a bug? Unfortunately I can't find a 
> page with TableView / TreeTableView UX specification any more, but 
> this behaviour is not specified there.
>
> It causes a problem in the application I'm working on, where the 
> selection has a business meaning.
>
> Regards,
> Konstantin
>
> 2016-01-25 23:19 GMT+01:00 Jonathan Giles <jonathan.giles at oracle.com 
> <mailto:jonathan.giles at oracle.com>>:
>
>     Hi all,
>
>     I've been aware for a very long time that many people would love
>     to see the default behavior for the ListView / TreeView /
>     TableView / TreeTableView controls change from being 'cancel edit
>     on focus lost' to 'commit edit on focus lost' when users are
>     editing the value of a cell.
>
>     I believe the main JBS issue is this one:
>     https://bugs.openjdk.java.net/browse/JDK-8089514
>
>     I've developed a proposal on how this can be changed without
>     breaking any APIs. Additionally, the semantics don't change by
>     default - all current users won't be impacted, only those that
>     opt-in by overriding a new protected method. I've posted a brief
>     summary of the proposed changes as a comment in the JBS issue
>     linked above. I am very keen to hear thoughts in the JBS issue
>     (don't spam the list!), and let's see how things shape up from
>     this discussion.
>
>     -- 
>
>
>     -- Jonathan
>
>