Using message asc(“ˇ”) in Pan 6 shows 255 while in Pan X it is 711. Using message asc(“ÿ”) in Pan 6 gets 216 and in Pan X it is 255. I believe this is the difference between MacRoman and Unicode UTF-32.
Another way of putting it is – ASCII and Unicode are not the same thing. They are the same for characters below 128, but not above 128.
Also, there is a bug in the chr( function, so it does not currently work for characters above 256. I was going to point out that this was fixed in 10.1.1, but I didn’t see it in the documentation. Turns out, I fixed it after 10.1.1, so the fixed version will be in 10.1.2.
Cool. I thought it didn’t work with any multi-byte value. I didn’t do extensive testing, since I knew it didn’t work with really large values, and the code had to be completely rewritten for that. The new version uses a completely different conversion method and even works with emojis.
Autocorrect apparently changed asc( to ask( and in trying several in both versions of Panorama I got myself twisted around on the re-conversion. Clearly though, I have some work to do to convert Pan 6 procedures that used the higher values of chr( and asc(.
I don’t know if you would want to use this technique or not, but here is a formula that will convert a number into text using MacOSRoman encoding.
binarytotext(byte(NUMBER),"macosroman")
So the formula
binarytotext(byte(255),"macosroman")
will produce ˇ, just like chr(255) did in Panorama 6.
I suppose I could create a macosromanchr( function that would do this, would that be worth doing? If yes, it might not get into a released version for a while.
The same thing can be done in reverse for the asc( function.
binaryvalue(texttobinary(TEXT,"macosroman")[1,1])
So the formula
binaryvalue(texttobinary("ˇ","macosroman")[1,1])
will produce 255, just like asc("ˇ") did in Panorama 6.