I have a device that keeps time using the old date (1904 based) and when we download the device we have a big memory block that we move through and turn into appropriate unsigned integers of 1,2 or 4 bytes in length. Time is the only 4 byte value. So for May 15, 2025 01:55:10 the time would be E44AF9FE, which would get turned into total seconds and a date.
I was thinking I had a problem with ‘date’ based on region settings when a customer on a Mac in Taiwan was having trouble, but it actually seems to be an issue somewhere else. When moving thru the memory block the following method is called. It is sent a ‘BinStr’ that is for instance the string above E44AF9FE and it should return that value as an unsigned int and it does, except not in Taiwan.
dim i,j As Integer
dim m As UInt32
j=len(BinStr)
if j>4 then break
for i=1 to j
m=m+AscB(mid(BinStr,i,1))*pow(256,(j-i))
Next
return m
In Taiwan it appears that it is returning a signed value, so all I get is 0x7FFFFFF as a decimal, since that’s max Int32. When I set my Mac to the Taiwan region, however, I cannot reproduce the behavior… so maybe it’s something else? Only the 4 byte value is a problem, which makes sense, since the smaller numbers will not have the max bit set.
I could probably fix with just using UInt64 in the above, but am curious if anyone has an idea as to what might cause this.
…you are mixing a bytewise operation (AscB) with a characterwise operation (Mid). Use MidB and see how that works.
You might also look at the MemoryBlock operations that directly return numeric values stored as bytes (MemoryBlock.UInt32Value(offset), for example), which will let you skip the string manipulations altogether.
Get a sample of the binary stream there and inspect it. Apply some manipulations there too. Bring the results and samples back to the lab. Something related to local CPU Endianess, alignment, who knows what may need observation and detection.
Some good suggestions here - but I wonder why I am unable to re-create the issue myself when I set my Mac to region Taiwan (English and all other date, number settings in that panel set the same). Is there some likely secondary system setting that someone using a Mac in Taiwan would have set differently? All I can think of would be something in accessibility like keyboard.
We have had issues with non-English PC/Mac in past, but this is first time (that I know of) where the region might be the issue.
I think the Taiwan link here is a red herring; I just don’t see any possible involvement of the region in any of your code. If the actual bytes being returned by the device are different, I would start there and work backwards towards the device. Perhaps the device itself is configured differently in Taiwan for some region-specific reason?
If you haven’t already, try rebooting your Mac after switching the language to see if that shows the problem. We have found that macOS / Xojo can act differently compared to just switching the language and launching an app.
If your data originates in a memoryblock it will always be safer to work on that data rather than converting it to a string. However, if you must work on strings containing binary data then you should be using LenB / MidB instead of Len / Mid.
So, as I suspected, changing ‘m’ to UInt64 fixes the issue but would have liked to have figured out why the problem arose to begin with. Probably time to update a bunch of the deprecated calls, etc. This app has been in ‘if it ain’t broke…’ mode for a long time. Thanks all.
