If I set the format settings (ubercart configuration)
. for thousands
, for decimals
The javascript function doesn't work anymore, it inserts a bid price that couldn't be placed.
Is their some hardcoded formatting set?
TIA,
Fossie
If I set the format settings (ubercart configuration)
. for thousands
, for decimals
The javascript function doesn't work anymore, it inserts a bid price that couldn't be placed.
Is their some hardcoded formatting set?
TIA,
Fossie
Comments
Comment #1
Garrett Albright commentedAha. When the JavaScript functions check values, they do so by stripping all characters out of a number except for digits and the period character, then converting that number using JavaScript's standard number conversion functions (which expect the period to be the decimal point). So:
"1,234.56" => "1234.56" => 1234.56 as a number - correct
"1.234,56" => "1.23456" => 1.23456 as a number - incorrect
I will have to modify the JavaScript a bit to deal with this circumstance of using the comma as the decimal point. Thanks for bringing it to my attention. Please stick around because I may have some patches I'll ask you to test in the future.
Comment #2
Garrett Albright commentedComment #3
Garrett Albright commentedOops. Closed the wrong issue.
Comment #4
Garrett Albright commentedHmm. It's interesting because it looks like Ubercart itself is not very tolerant about values which are not formatted with a period as the decimal point in its input; see uc_product_validate() in uc_product.module (lines 632-665). But I made some tweaks and now UC Auction should be more tolerant for values formatted with different decimal and thousands separators - more tolerant than Ubercart itself, even. But please test it when you download the new one.
Comment #5
fossie commentedThx,
I'll try it as soon as possible and keep you informed.
Fossie
Comment #6
Garrett Albright commentedfossie, have you been able to give this a try yet?
Comment #7
rsm08 commentedI works I can tell you.
But mind you there's no validation for the amounts entered. So if a user on a system that's configured in "reverse" ("." for thousands and "," for decimal) enters fx.:
10.50
The system will interpret it as
1050
I don't know if this will be the same if 10,50 is entered when running with "normal" decimal-configuration.
Regarding Ubercart's stubborn validaton function that ignores "reverse" decimal-configuration and will never accept "," as decimal separator, I put this code into a custom validation function and put in my own amount validation:
Maybe someone can use it or have a better solution..
Comment #8
Garrett Albright commentedI'll close this one then.