Committing (rather than cancelling) cell changes on focus loss
jonathan.giles at oracle.com
Tue Jan 26 07:48:55 UTC 2016
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.
On 26/01/16 8:47 PM, Konstantin Pasko wrote:
> 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
> 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.
> 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:
> 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
More information about the openjfx-dev