It seems that the Spinner control does not update a manually typed-in value until the user explicitly presses enter. So, they could type in a value (not press enter) exit the control, and submit the form, and the value displayed in the spinner is NOT the value of the Spinner, it is the old value.
My idea was to add a listener to the lost focus event, but I can't see a way to gain access to the typed-in value?
spinner.focusedProperty().addListener((observable, oldValue, newValue) ->
{
//if focus lost
if(!newValue)
{
//somehow get the text the user typed in?
}
});
This is odd behavior, it seems to go against the convention of a GUI spinner control.
Unfortunately, Spinner doesn't behave as expected: in most OS, it should commit the edited value on focus lost. Even more unfortunate, it doesn't provide any configuration option to easily make it behave as expected.
So we have to manually commit the value in a listener to the focusedProperty. On the bright side, Spinner already has code doing so - it's private, though, we have to c&p it
/**
* c&p from Spinner
*/
private <T> void commitEditorText(Spinner<T> spinner) {
if (!spinner.isEditable()) return;
String text = spinner.getEditor().getText();
SpinnerValueFactory<T> valueFactory = spinner.getValueFactory();
if (valueFactory != null) {
StringConverter<T> converter = valueFactory.getConverter();
if (converter != null) {
T value = converter.fromString(text);
valueFactory.setValue(value);
}
}
}
// useage in client code
spinner.focusedProperty().addListener((s, ov, nv) -> {
if (nv) return;
//intuitive method on textField, has no effect, though
//spinner.getEditor().commitValue();
commitEditorText(spinner);
});
Note that there's a method
textField.commitValue()
which I would have expected to ... well ... commit the value, which has no effect. It's (final!) implemented to update the value of the textFormatter if available. Doesn't work in the Spinner, even if you use a textFormatter for validation. Might be some internal listener missing or the spinner not yet updated to the relatively new api - didn't dig, though.
Update
While playing around a bit more with TextFormatter I noticed that a formatter guarantees to commit on focusLost:
The value is updated when the control loses its focus or it is commited (TextField only)
Which indeed works as documented such that we could add a listener to the formatter's valueProperty to get notified whenever the value is committed:
TextField field = new TextField();
TextFormatter fieldFormatter = new TextFormatter(
TextFormatter.IDENTITY_STRING_CONVERTER, "initial");
field.setTextFormatter(fieldFormatter);
fieldFormatter.valueProperty().addListener((s, ov, nv) -> {
// do stuff that needs to be done on commit
} );
Triggers for a commit:
Coming back to the spinner: we can use this commit-on-focusLost behaviour of a formatter's value to force a commit on the spinnerFactory's value. Something like
// normal setup of spinner
SpinnerValueFactory factory = new IntegerSpinnerValueFactory(0, 10000, 0);
spinner.setValueFactory(factory);
spinner.setEditable(true);
// hook in a formatter with the same properties as the factory
TextFormatter formatter = new TextFormatter(factory.getConverter(), factory.getValue());
spinner.getEditor().setTextFormatter(formatter);
// bidi-bind the values
factory.valueProperty().bindBidirectional(formatter.valueProperty());
Note that editing (either typing or programmatically replacing/appending/pasting text) does not trigger a commit - so this cannot be used if commit-on-text-change is needed.
For those who come to this answer in search of why their spinner isn't updating despite pressing enter: you're probably using a ChangeListener - it activates only if there was a real change in the value, which JavaFX sometimes seems to get wrong. Try using an InvalidationListener.
@kleopatra I hope the site notifies you about this comment, I have a question about the answer below from Sergio. Do you have any thoughts on it? It seems such a short and sweet solution that it feels too good to be true. It's only a year newer than yours, if it is that good I would have expected it to overtake the score of your answer by now. Is there an issue with Sergio's answer that needs to be noted? Or are people stopping scrolling as soon as they get to your solution? I don't think it worked when I tried to tag you under that answer.
@pateksan didn't look at this for quite some while (forgot whether the underlying bug is fixed meanwhile) - the other answer is a hack-around based on an unspecified implementation detail. That behavior is slightly unexpected, IMO - we could just as well reject inc/dec while editing. But then, if something isn't provided, we have to go for whatever does the job :)
@kleopatra, thanks. I do have another question (sorry if I'm dragging you into an old problem): I was a bit confused when you said we could just as well reject inc/dec while editing? Rejecting inc/dec doesn't seem related to the OPs question. Is this a side effect of Sergio's code? Or another means of achieving the OPs original objective? Also, I'm still newish but your comment (the one above this, just an hour ago) might be of more use to everyone if you put it under Sergio's answer instead of yours - I'm sorry if it's rude to suggest this to someone with 2^8 more rep.
@pateksan short (and last) answer: yes - sry, this is getting just too much off-topic - to learn all about references, work through a tutorial on java basics related to weak/strong references and apply what you learned to this context (f.i. by thinking through the path of references here, writing tests, ask a question when stuck .. :) Have fun!