OSCommerce Product Manager

OSCommerce Product Manager for Windows
Tasklist

FS#80 - Cannot handle regional settings for decimal separator.

Attached to Project: OSCommerce Product Manager
Opened by Mario A. Valdez-Ramirez (mvaldez) - Sunday, 22 August 2004, 05:40 GMT-6
Last edited by Mario A. Valdez-Ramirez (mvaldez) - Sunday, 22 August 2004, 06:30 GMT-6
Task Type Bug Report
Category Backend / Core
Status Closed
Assigned To Mario A. Valdez-Ramirez (mvaldez)
Operating System All
Severity Medium
Priority Immediate
Reported Version any
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

The application is not handlig well the different decimal separators. When the regional settings of Windows set the decimal separatoras "," the cleaning functions strip it and join the numbers, converting 3,05 to 305.

It seems there is something wrong somewhere else too. 3.05 in the database is displayed as 3,05 in the editing window. trying to enter a "." shows an error. The Delphi conversion routines (maybe the Currency ones) seems to be sensitive to the regional settings of Windows.

I think the problem is not that, after all, we should support regional settings. The problem is our cleaning routines. We really clean for the SQL statements, not so much for the user interface.

We have two options First option is to force normalized user data, which would mean force the decimal separator to ".". Second option is to support the regional setting and then reconvert before sending the SQL statements. (The MySQL number should use ".").

Data is being lost on this. Severity = Critical.
This task depends upon

Closed by  Mario A. Valdez-Ramirez (mvaldez)
Sunday, 22 August 2004, 06:30 GMT-6
Reason for closing:  
Comment by Mario A. Valdez-Ramirez (mvaldez) - Sunday, 22 August 2004, 06:09 GMT-6

This bug is related to Bug #77.

Comment by Mario A. Valdez-Ramirez (mvaldez) - Sunday, 22 August 2004, 06:25 GMT-6

After reviewing the current code, to support regional settings for Currency and Float values would require extensive rewriting.

The data flow goes like this NOW:

DB <--null--> Memory Tables <--asRegSet--> UI <--aslocale--> User


The passing of data from/to data structures to/from UI controls depends on FLOATTO / TOFLOAT and CURRTO / TOCURR functions that are sensitive to regional settings. There is where we are getting the problems. (The real problem, however, is that we missed this requirement during software analysis and design).

To support regional settings means to convert as follow:

DB <--null--> Memory Tables <--asRegSetNull--> UI <--aslocale--> User


The easy alternative is:

DB <--null--> Memory Tables <--forcenull--> UI <--forcenull--> User


Right now, we have mae a workaround like the third option. We have practically disabled all regional settings support and forced all functions sensitive to them, to behave as null (which we mean, dot for decimal, comma for thousands). A similar approach taken for data/time handling, where we choosed to force an IS0 8601 date format.

The final solution is to write customized CURRTOSTR, STRTOCURR, FLOATTOSTR, STRTOFLOAT functions to convert data before storing in memory structures.

Deferring final solution. Closing the bug for now.


Comment by Mario A. Valdez-Ramirez (mvaldez) - Sunday, 22 August 2004, 06:26 GMT-6

As a side note, it seems the ZEOS Library field conversion functions (AsCurrency, AsFloat) are not sensitive to regional settings.

Comment by Mario A. Valdez-Ramirez (mvaldez) - Sunday, 22 August 2004, 06:30 GMT-6

Severity no longer is critical, as now it's a bug with workaround.
Severity changed to "Normal".

Loading...