This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal



Mar 6, 2013, 9:26 AM
12 Posts

numeric conversion bug, incorrect decimal separator

  • Category: Server Side JavaScript
  • Platform: Windows
  • Release: 8.5.3
  • Role: Developer
  • Tags: coverter,bug
  • Replies: 0
I create a form that contains a numeric field and I need to input fractional value, e.g. 10.1
 
On xPage I put an Edit control and unselect checkbox "Integer only". So far so good, I can enter my value, validation is happy, however the saved value is 101 instead of 10.1
 
It looks like this is a long-standing bug - here is another post from 2011 that describes the same problem from different angle:
http://www-10.lotus.com/ldd/xpagesforum.nsf/topicThread.xsp?action=openDocument&documentId=05C9874F20BC8CFF852578A80037509F
 
Basically if "Integer only" is checked, converter converts it to java.lang.Double (kind of unreasonable for integer value). If I pass this "integer" value to Java routine I need to expect Double as argument, instead of Long as it would reasonable. But it's the lesser half of the problem.
 
If "Integer only" is unchecked converter converts it to java.lang.Long - not even rounding up, but simply discarding the decimal dot.
 
While investigating further, this is caused by the converter expecting me to use "," not "." as the decimal separator. If I enter value 10,1 it gets saved correctly as 10.1
 
Needless to say when doing the input from Notes form, 10.1 is treated correctly and 10,1 is rejected as an invalid number. And yes, I'm running this in client, in preview mode in fact.
 
I'm running Windows 7 64-bit, my regional settings is French (Switzerland) and decimal separator is "."
 
Edited: looks like part of the problem is that XPages cannot detect correctly my locale.
context.getLocale().getDisplayCountry()  return empty and
context.getLocale().getDisplayLanguage()  = German
context.getLocale() = de
context.getLocale().getDecimalSeparator() = ,
 
If I set manually Locale in converter it treats decimal numbers correctly. Looking at predefined locale constants in Local class, there are not too many. It seems that it follows following logic - if you are not English Chinese or French, you must be German.
 
Though it beats me where it gets this info if not from OS settings and if it gets from there, why it's not correct.
 
Edited:  ok, it's the Notes client that identifies Switzerland as Germany and has no Swiss French locale as an option. So only logical that XPages uses the twisted Notes point of view when selecting locale. However again this does not prohibit Notes to use the correct decimal point...

This forum is closed to new posts and responses. Individual names altered for privacy purposes. The information contained in this website is provided for informational purposes only and should not be construed as a forum for customer support requests. Any customer support requests should be directed to the official HCL customer support channels below:

HCL Software Customer Support Portal for U.S. Federal Government clients
HCL Software Customer Support Portal