Open nickkolok opened 5 years ago
Yes, I can reproduce the result with the comma when dot is expected. I agree it should accept both and will implement that in the next release. But could be months away...
Possibly the change should be performed somewhere here:
https://github.com/OpenSourcePhysics/tracker/blob/12db9daa3292fe961d775f416d7eb3ba1c42cd1d/src/org/opensourcephysics/cabrillo/tracker/TapeMeasure.java#L1251
inputField.getValue()
should be replaced with something more clever.
The problem, however, is the fact that some locales use comma or dot as a group separator, e.g. 1,234
can be both 1234.00
or 1.234
.
I think that the solution contains three steps:
Adding a preference named Custom decimal separators
which is a string. Every character of the string is treated as a decimal separator. Default value: empty string. For example, if Custom decimal separators
is .,
, then both .
and ,
are considered to be a decimal separator.
When an unknown non-space character appears between two digits and there is only one such a character in the string, then a dialog opens. The dialog suggests to add the character to Custom decimal separators
.
Adding a preference containing the characters which are never suggested to be decimal separators. Adding appropriate button to the dialog described above.
If while creating a calibration stick auser types
16,5
, he will get16,50 m
. It's OK. But if a dot is used, i.e. one types16.5
, then the result is16.00 m
. In Russia (for example), both decimal dot and decimal comma are used. So, it would be great if decimal dot.
and (dare dream!) cyrillicб
andю
, which are on the same keys of keyboard with.
and,
and which are often mistyped, will be treated as deimal delimiters are replaced by decimal comma.It can be implemented by simple replacing the delimiters with comma an
killfocus
event (I don't know how it is called in Java) or, which looks more complicated but more scalable in future, by registering.
,б
andю
as decimal delimiters.