utf-8 issue (thin space)

Posted by Darren Parr on 17-Jun-2016 03:33

Hi

I'm trying to test for the nujmeric seperator of thin space. Its used in the "Dutch (belgium)" region and we use -useOsLocale with our GUI client. We want to support this for this user. Our source code is not encoded in utf-8 but our client and server are running in utf-8 successfully.

With utf-8 set, ASC(cThinSpace) returns -1. It looks like OE is letting me use it as a numeric seperator buts it doesnt seem to be in the utf8 codepage as progress sees it. Any idea how to produce a thin space character using CHR?

Thanks

Darren

Posted by Darren Parr on 17-Jun-2016 10:35

OK. Ive managed to settle on the following. I hope someone else sees this in the future if they come across the same problem. .net is the answer. It returns a value I can at least test for.

cDecimalSep = System.Threading.Thread:CurrentThread:CurrentCulture:NumberFormat:NumberDecimalSeparator.

cNumberSep  = System.Threading.Thread:CurrentThread:CurrentCulture:NumberFormat:NumberGroupSeparator.

SESSION:SET-NUMERIC-FORMAT(IF ASC(cNumberSep) = 49824 THEN " " ELSE cNumberSep,cDecimalSep) NO-ERROR.

All Replies

Posted by bronco on 17-Jun-2016 05:09

try: message asc(chr(14844041)) view-as alert-box.

Posted by Darren Parr on 17-Jun-2016 05:35

Thanks. The character looks OK. I don't seem to be able to assign CHR(14844041) to session:numeric-seperator on a utf8 appserver. I'm actually passing this down to an appserver to ensure the client and server have the same settings.

Any idea how I can acheive that?

Posted by bronco on 17-Jun-2016 06:04

Well, if you are passing your integers/decimal's as themselves to the AppServer (instead of string), why would you want to set the numeric separator on the AppServer? Reporting? (sorry for answering your question with a question)

Posted by Darren Parr on 17-Jun-2016 06:37

I'm using -useOsLocale. So the webclient has a valid multi-byte value for the numeric seperator.

On the appserver we already store seperators against each operator. We are checking that the clients session matches the servers.

The reason for doing this is the client has legacy activex controls and .net components which don't look at the progress numeric seperator but look at the locale. So it makes sense to ensure the client is using the same settings.

The appserver uses the operator to set the environment. With an interactive client we want the settings to be the same and so I'm passing the numeric seperator which is set and trying to set the numeric-seperator on the server too. Then I compare the two seperators to make sure they are the same.

So on finding a space as the value we want on the server, I'm trying to set the numeric seperator to chr(14844041). I then compare the value from the one which came in. The only issue is that progress does not allow a multi byte seperator to be used as numeric seperator when using the set-numeric-format method.

Any ideas?

Darren

Posted by Darren Parr on 17-Jun-2016 06:41

Hi

The numeric-separator attribute also doesn't allow this character to be set.

-Darren

Posted by Darren Parr on 17-Jun-2016 09:55

This is very bizarre. I'm using 11.6. I can create a thin space character using the character code you've very helpfully furnished me with. This cant be assigned to the numeric separator as its a multi-byte character.

When using -useOsLocale and dutch(belgium) you get a special character as the numeric-separator. There is no way of doing anything to the resulting value stored in the numeric-separator or numeric-format attributes. Its not a normal character and its ascii value returns -1. yet if you leave it untouched it works and shows the data with a space.

So using dutch (belgium) with utf8 charset, message CHR(14844041) = session:numeric-separator always shows "false". Any idea how I can detect the locale better so I can set server locale correctly.

-Darren

Posted by Darren Parr on 17-Jun-2016 10:35

OK. Ive managed to settle on the following. I hope someone else sees this in the future if they come across the same problem. .net is the answer. It returns a value I can at least test for.

cDecimalSep = System.Threading.Thread:CurrentThread:CurrentCulture:NumberFormat:NumberDecimalSeparator.

cNumberSep  = System.Threading.Thread:CurrentThread:CurrentCulture:NumberFormat:NumberGroupSeparator.

SESSION:SET-NUMERIC-FORMAT(IF ASC(cNumberSep) = 49824 THEN " " ELSE cNumberSep,cDecimalSep) NO-ERROR.

This thread is closed