where there changes in text encoding?

This is one of those frustratingly weird and impossible to duplicate anywhere but the affected machine things. I released a beta of a web product the other day built with the latest version of Xojo and it works well for almost everyone but I’ve got one user with a French localized machine and one 4 character string that doesn’t match.

The string comes down a socket and is compared against a constant stored in the program. So I know the socket fragment might not have a text encoding set but the constant in the program should. It is generated originally in another program that is still built with RB2011. The 2 strings match on every other system including my own, but on this one French system “XTdb” != “XTdb”

It feels like a text encoding issue, that the constant in the program has been converted and no longer matches the simple ascii string from down the socket. So I’m off next to try to send some code that logs the encoding that it thinks the strings have and to output the string in bytes of hex so i can look at them below the level of encodings but the back and forth with users like this and getting the results back is very hard when I can’t duplicate the problem here and I am hoping that someone else has hit something like this too and has some wisdom to share.


Anything coming from a socket has no encoding. You must set it explicitly using DefineEncoding. The fact that it’s a French system does hint at an encodings issue, but “XTdb” is straight ascii, so that doesn’t add up. I’d look for some stray trailing character, like an extra carriage return or a tab. Dumping the hex values would reveal that.

You might try performing a binary mode search using StrComp instead of checking for equality with the “=” operator.

Wasn’t there a change about strings being terminated with a null character now? Though I might mix that up with CStr …

Been doing a huge amount of debugging on this issue and it’s not quite what I thought :wink: I still dont have a solution but thinking out loud. The problem is that the initial “set my ID” command is sending a number, and then later when another command is sent that needs to reference that initial unique ID number, that number is 1 higher! Only on French systems, it works perfectly on my system of course. (and maybe on other language systems, but am only testing on these 2 at the moment.)

When I make my initial connection and send the unique id it’s “1100636324” but later on when I send a command that has a reply ID of what should be that same number it’s coming through as “110636325” so of course it doesn’t match and the command logs an error that it can’t find where it’s supposed to go. (that number is generated just by a call to microseconds and will be different each session with the machine)

The first connection is sent as a string in a different sort of packet, the string is generated via the format( theValue, “-#.#####”) command, even though this particular value will never have a negative or a decimal. Later on when I send the next command it’s treated as a memory block so I’m actually using memoryBlock(offset).doubleValue = TheValue so there are still strings in the mix. But what can possibly be different on a French localized system that causes the format command to return one number lower? Or the doubleValue to return one number higher? I would expect whole extra digits of data if it were text encoding being wrong, or unprintable characters and if endian issues are impacting then I’d expect the number to be wildly different, but the one is just one number higher than the other and only on a French OSX… I am going to be thinking about this for a while I fear.

Please don’t use doubles for this. When you initially get the microseconds value, store it as an integer (32 or 64 bit probably doesn’t matter, as it just has to be unique) and use the integer value for everything.

I understand the lack of precision involved, but microseconds returns a double, so it never occurred to me that it would be a problem in that particular case. It shouldn’t be a problem as it’s just RB apps talking to RB apps so they should be the same. Except that as of this last release of Xojo, there is a difference between the various localized versions.

I will experiment with turning them into int64’s as they are the same size and see if that makes a difference. thank you!

CType should help since it’s 8 bytes interpreted as a Int64 instead of a double