On Wed, 31 Mar 2021 09:25:28 GMT, Florian Kirmaier <fkirma...@openjdk.org> wrote:
> > > I don't think B is right. > I would expect a editCancel event when the index of an editing cell is > changed. > If there would be another cell, which will get the index 1 (which isn't the > case in this artifical test) then i would expect another editStart event. well, I see your point but think it's arguable :) - editEvent not/firing on cell re-use is not really specified (even overall edit spec is .. suboptimal, see [my oldish summary](https://github.com/kleopatra/swingempire-fx/wiki/CellEditEvents)) - without that spec, we might feel free to fire - from the perspective of edit handlers, that editCancel (and the assumed editStart - suspect it doesn't happen, didn't test though) are just spurious events - they are not really interested in volatile state changes, just introduced by an implementation detail like cell re-use. As to the scope of this: as I understand it, its goal is to keep the cell's editing state (flag and visual state) in sync with listview's editingIndex when updating the cell index. That should include both directions - index == editingIndex -> index != editingIndex - index != editingIndex -> index == editingIndex The first is already handled (modulo our disagreement on editEvents :), the second is not. ------------- PR: https://git.openjdk.java.net/jfx/pull/441
