I've done another test, where I delayed nested event emission (code
here:
https://github.com/hjohn/jfx/commit/fe63a4ee2284c0ed440c4521504a3c5db55f631d)
No tests broke. Basically, the change will queue up at most one nested
event emission. It will use the historically correct old/new values for
each emission.
Even though nothing broke, I saw a rather curious practice in
SpinnerValueFactory. The value factory has an internal value property
on which it places restrictions using a change listener which will cap
the value to a minimum or maximum when its out of range. This value is
in turn bound to a read only property Spinner#valueProperty.
Depending on where you check the value of the spinner in user code, you
get different results. Assuming a spinner in the range of [0, 100] with
a current value of 99, changing the value to 200 triggers the following
events when observing Spinner#valueProperty:
99 -> 200
200 -> 100
When you observe Spinner#valueFactoryProperty#valueProperty you instead
see:
200 -> 100 (send out by a nested emission)
99 -> 100 (send out when the top level emission finishes)
When you apply my change, both these would be the same for both properties:
99 -> 200
200 -> 100
I think its odd in the first place these events are published. When I
limit a spinner to a certain range, I'd never expect to see out of range
values published. Instead I'd only expect:
99 -> 100
Still, I think the delayed version sends out more consistent events in
this case.
--John
