We have a user in Sweden where they use commas for the decimal separator.

We use MD24, generally for conversions of money, storing to 4 dec places.

The MD24, conversion converts 1234567800 to 123,456.78

The MC24, conversion converts 1234567800 to 123.456,78

Both these are correct and as expected.

The online help for this says when using MC, substitute a period (.) for the comma, this conversion MC24. gives a result of .123456,78.

Either the online help is wrong or there is a bug in the conversion handler, either way I am happy to use MC24, conversions.

On another issue, (Oystein?) when a user enters 5.50 on a UK/US/Aus keyboard using the keypad with a period, everything is fine.

When entering in Sweden the key used is a comma, eg 5,50.

This results in 550.00.

Is there any tricky way of handling this, rather than go through thousands of programs and add a subroutine call to check for values and handle them properly. OI is not picking up the Windows characters and handling these, and I dont really expect it to.

I can do this manually, but I was hoping for a quicker solution.

Also, how then can bound controls, or controls with conversions be handled, eg using INVALUE etc with such user settings.

Oystein, as a developer in this region I though you'd be the one to have the ideas here.

Thanks

Colin

Colin,

We have a user in Sweden where they use commas for the decimal separator. We use MD24, generally for conversions of money, storing to 4 dec places. The MD24, conversion converts 1234567800 to 123,456.78 The MC24, conversion converts 1234567800 to 123.456,78 Both these are correct and as expected. The online help for this says when using MC, substitute a period (.) for the comma, this conversion MC24. gives a result of .123456,78. Either the online help is wrong or there is a bug in the conversion handler, either way I am happy to use MC24, conversions.

On another issue, (Oystein?)

Huh? Me?

In my own apps I've used the decimal format for a couple of bound fields (measurements) - DECIMAL(5,1) to be precise. But even if the comma is the official decimal character in Norway (like in Sweden), I've just kept the default (MD1) validation and MD1 conversion formats. E.g from using calculators Norwegians are used to the decimal point also, so they recognize the point as a decimal character all right. I just had to fix it so users couldn't key in a decimal comma. When the field expects a decimal point, every other non-numeric character, even the comma, is just ignored. So on every relevant control (of which there aren't very many) I have a CHAR handler that instantly converts a comma to a point:

declare function Set_Property

declare function Get_Property

if ScanCode=0 then

if VirtCode=,' then

Sel=Get_Property( CtrlEntID, 'SELECTION' )

Tekst=Get_Property( CtrlEntID, 'TEXT' )

convert ',' to '.' in Tekst

OldVal=Set_Property( CtrlEntID, 'TEXT', Tekst )

OldVal=Set_Property( CtrlEntID, 'SELECTION', Sel )

end

end

RETURN 0

when a user enters 5.50 on a UK/US/Aus keyboard using the keypad with a period, everything is fine. When entering in Sweden the key used is a comma, eg 5,50. This results in 550.00.

What you describe (5,50 becoming 550.00) happens if you have an MD24 field (or MD,), which expects a decimal point, and key in 5,50. The comma is just ignored, so it's like 550 was keyed in. So that experiment in Sweden couldn't have been done on an MC24 field but a US style MD24 field. I thought you just said you were happy to use MC24, conversions.

Is there any tricky way of handling this, rather than go through thousands of programs and add a subroutine call to check for values and handle them properly.

I'm not sure what you're after. Are you talking about programs or dict entries or field controls in forms?

Wouldn't programs handling decimal values use internal values, making the problem non-existent? Or if they do use external values wouldn't those values be decimals from hardcoded MD conversions (Oconv)? Which would have decimal points which are necessary for Basic+ arithmetic to be able to handle them? Or do your programs get their conversion format from the dict or field controls? Which are MC. Or???

OI is not picking up the Windows characters and handling these, and I dont really expect it to.

¹⁾)

I can do this manually, but I was hoping for a quicker solution. Also, how then can bound controls, or controls with conversions be handled, eg using INVALUE etc with such user settings.

INVALUE is an internal value, which in your case is an integer 10000 times the external value. E.g, the value might be 987654 which equally well represents the external value 98.7654 US style or 98,7654 Swedish style. Or is there something here that I don't know? Don't you always set INVALUE with an integer? Do you sometimes set it with internal values with decimals, i.e, extra decimals beyond the 4 you store? And if so - would this fail in Sweden since a decimal value from Basic+ would have a decimal point?

Oystein, as a developer in this region I though you'd be the one to have the ideas here.

I'm afraid you've lost me. More details please.

But I might be away and not able to reply. I'll check the forum on Saturday and Sunday, but Monday through Wednesday I'll be offline.

- Oystein -

PS. I've checked what you said about MC24. vs MC24, and my observations agree exactly with yours.

Oystein

Thanks for your response.

It has been most helpful.

I do in fact use MD conversions, but because there are so many of them in the system, I was looking for a simple way out.

Your suggestion to exclude commas in entry is probably the best solution, especially as these users are used to using the period for the decimal separator.

I am sorry if I confused you a little here.

Regards

Colin

View this thread on the forum...