So the event.isAnyModifierKeyDown() returns false on Firefox even when some modifier key is in fact down? Didn’t find any definitive about that with a quick googling, all complaints I came across were years old, but I only had a few moments to spare so that didn’t really prove anything. SuperDevMode is probably your friend here, to see what’s actually going on there and what kind of values the event really contains.
If the decimal separator is specified as a comma and setGroupingUsed(false) is called, it will result in the numbers not being validated correctly. It will simply say that the value is not valid. There’s no problem if setGroupingSize(0) is called instead of setGroupingUsed(false). In your example UI you can just add the numberField.setGroupingSize(0) to see the problem.
If you call setValue with a large number or enter a large number in the field, the validation will also fail. You can see the problem in the example UI by specifying 123456789,12 in the “Default settings” field. The problem lies in NumberField.changeVariables in which the double value is converted to a string using toString. This results in E notation, that cannot be validated using the NumberValidator.
I hope to see these things fixed in a future version.
I have run into a problem when I bind a NumberField to a BigInetger. The following is the code.
NumberField numberfieldElement = new NumberField("Total number positions:");
numberfieldElement.setConverter(StringToBigIntegerConverter.class);
numberfieldElement.setNullRepresentation("");
numberfieldElement.setErrorText("Invalid number format!");
...
binding
When I enter numbers, I always get “Invalid number format”. If I don’t have the binding, it works fine. Is the converter wrong?
Tao: I’m afraid the component is pretty tightly tied to Doubles for now, so the BigInteger itself is probably the problem
Brian: Sorry, I had somehow completely missed your comment. I’ve had absolutely no time to work on this lately, but I’ll add those to my list of things to check out when I next have an opportunity. Thanks for the feedback!
Version 0.1.4 uses shared state instead of legacy communication and should work with Vaadin 7.6 branch as well (tested on 7.6.0 and 7.6.4), although on the flip side it doesn’t work with 7.3 branch or older. Haven’t had a chance to look into the other reported issues yet.
I finally got around to testing that and it seems to work fine in my Firefox at least – are you still having issues there or has some Firefox update possibly fixed the problem?
Well, I pushed out the SHIFT fix as well, in its own version (0.1.5) so that it’s easy to switch back if anyone still experiences problems with the solution.
And this is what I get when I continue three months old commit and think I remember what all I still had to do… forgot to fix the issue where a workaround in TextFieldConnector overrides the formatted value on the client-side. I really need to get those automated tests configured so that I can have proper regression testing with this addon. A quick fix added in version 0.1.6, it’s ugly but seems to do the trick. So much for the easy-to-rollback version for the SHIFT fix.
Hey Anna,
I’ve been testing out the NumberField since it currently looks like the best alternative for os. However, we’re struggling a bit with issues likely caused by
BigDecimal.valueOf(newValue).toPlainString() .
I’ll be happy to help out, but since I’m old and stubborn, I would like to change it into a maven project (actually did that in my fork, me and ivy are new acquaintance and didn’t hit off immediately… So it was faster to turn it into a maven project). Is that ok with you?
I’ve actually been considering converting the project to Maven myself, so I’d be fine with that I’m pretty swamped with work right now myself so I haven’t had any chance to check out your issue yet (sorry about that), so you are completely welcome to take a shot of it yourself. I’d really like to get rid of as many of those forced conversions as possible, and preferably drop the hard-coded dependency to Double and have the Number type to be configurable, but that’s quite a bit more work than I’m likely to have time for in the foreseeable future.
hi ,i’ve a question. I define a field by Double In an Entity ,when i use numberfield,
numfield.setDecimalPrecision(5);
numfield.setMinimumFractionDigits(5);
when numfield.setValue(0.000001d),but display by 0.00000
when numfield.setValue(0.001111d),but display by 0.00100.
I don’t know where has a mistake
java.lang.NullPointerException: null
at com.vaadin.ui.AbstractTextField.changeVariables(AbstractTextField.java:193) ~[vaadin-server-7.7.6.jar:7.7.6]
at org.vaadin.ui.NumberField.changeVariables(NumberField.java:335) ~[NumberField-0.1.6.jar:0.1.6]
at com.vaadin.server.communication.ServerRpcHandler.changeVariables(ServerRpcHandler.java:627) [vaadin-server-7.7.6.jar:7.7.6]
Project has now been converted to use Maven instead of Ivy. Sorry @Anders for not being able to get through your pull requests, it was faster to make my own version than try to figure out what all had changed in yours. I’m still trying to figure out if I can incorporate changes from the other pull requests.
Initial Vaadin 7 compatibility version for Vaadin 8 projects that want to use NumberField is now available
here . True Vaadin 8 conversion is still underway.
Why can’t I use NumberField with 4 or more decimal? I can set it to 4 or 5, I can write into the field (it allow) but when I leave the field it decrease the decimals to 3.
How can I use it with more than decimals?
I’m pretty swamped with work right now myself so I haven’t had any chance to check out your issue yet (sorry about that), so you are completely welcome to take a shot of it yourself. I’d really like to get rid of as many of those forced conversions as possible, and preferably drop the hard-coded dependency to Double and have the Number type to be configurable, but that’s quite a bit more work than I’m likely to have time for in the foreseeable future.