Community
Participate
Working Groups
i would like to influence the presentation of numbers in the Spinner-control via NumberFormat, e.g. with a leading zero for minutes
Created attachment 24469 [details] diff Spinner.java (+NumberFormat) Spinner.java.orig
*** Bug 94601 has been marked as a duplicate of this bug. ***
I would love to use your patch, but SWT code base must be portable to embedded devices and I'm pretty sure J2ME doesn't support java.text.NumberFormat. Steve, what can we do ?
NumberFormat is part of J2ME-CDC. See for example http://www.jcp.org/aboutJava/communityprocess/review/jsr036/J2ME_CDC_Specificati on.html
Sorry, I wasn't clear. AFAIK SWT needs to be J2ME CLDC 1.0 complying.
Your bug has been moved to triage, visit http://www.eclipse.org/swt/triage.php for more info.
The key problem (for Windows at least) is the usage of the Windows GetLocaleInfo function for getting the decimal separator. While this function will take the control panel settings into account (which allows overriding the decimal separator compared to the locale default), all other parts of Java don't. This creates two major problems: - The return value of Spinner.getText() can't be reliably parsed - neither with NumberFormat.parse() nor with Double.parseDouble() - The decimal separator displayed in a Spinner control will look alien compared to other controls with contents formatted with the standard Java localization functions Using "new DecimalFormatSymbols().getDecimalSeparator()" instead of "OS.GetLocaleInfo()" would be consistent with the rest of Java. If this is still considered too non-portable, the default should be using "." (so the return value of Spinner.getText() can be reliably parsed with Double.parseDouble()) and a setDecimalSeparator() method should be added to Spinner. I know that I can use getSelection() instead of getText(), I just want to stress that getText() is not consistent with the rest of Java now. The minimum should be the addition of a setDecimalSeparator method, even if the getText() behavior must remain for compatibility reasons.
Interesting, are you saying that "new DecimalFormatSymbols().getDecimalSeparator()" is not equivalent to "OS.GetLocaleInfo()" ? I will not change the behaviour in Spinner, it is the correct behaviour imo (using the decimal separator set in the control panel). The application code really should be using getSelection(). Why are you using getText() ?
> Interesting, are you saying that "new > DecimalFormatSymbols().getDecimalSeparator()" is not equivalent to > "OS.GetLocaleInfo()" ? Exactly. > I will not change the behaviour in Spinner, it is the correct behaviour imo > (using the decimal separator set in the control panel). That depends on the definition of "correct". It would be correct for a Windows-only application. It's imo wrong for a Java library because it is inconsistent with the rest of Java. > The application code really should be using getSelection(). Why are you using > getText() ? I *am* using getSelection() now. But the behaviour of getText() is still somewhat incompatible. If you insist in leaving it as is, you should also document that (if a decimal separator is used) its return value is more or less useless for anything but putting it back into another (or the same) spinner. It can't be reliably parsed nor should it be used to be displayed in some other GUI element because its decimal separator is not the same as in output generator by Java's NumberFormat/DecimalFormat machinery. iow: The behavior is alien to the rest of SWT. A well-behaved application wants to use the same decimal separator for all displayed numbers. But it's impossible for a Java application (i.e. without native code) to determine Window's control panel regional setting. So when you put something like a static text, a text input field or a drop down box containing a number into your GUI, it will be next to impossible to use the same decimal separator as the spinner widgets. You might argue that SWT tries to feel as "Windows native" as possible. But then, SWT is lacking methods to give a application access to its locale behavior! The easiest solution would really be to add a setDecimalSeparator method.
This is a one-off bulk update. (The last one in the triage migration). Moving bugs from swt-triaged@eclipse to platform-swt-inbox@eclipse.org and adding "triaged" keyword as per new triage process: https://wiki.eclipse.org/SWT/Devel/Triage See Bug 518478 for details. Tag for notification/mail filters: @TriageBulkUpdate
