macToIso with numtochar(1) strange result

[jmburnod]

Hi All

I'm a little confused with MacToIso.
I read in the doc:

Characters whose ASCII value is less than 128 are the same in the Mac OS character set and Windows Latin 1, so they are not changed by the macToISo function.

I use chartonum(1) like itemdel and it seems it is changed by the macToISo function
On Mac: MacToIso(numtochar(1)) = "ä" (ascii = 138)

When i open the stack on windows (numtochar(1) appear like a kind of S with an inverse circumflexe (ascii = 138)

Thanks for your lights

Best regards

Jean-Marc

[Mark]

Hi Jean-Marc,

MacToIso/IsoToMac is for converting texts, not binary data. Try converting the items, not the itemDelimiters.

I must admit that it is slightly odd that isoToMac/macToIso alters the control values, but I'm not really surprised. Just don't convert chars 1 to 31.

Kind regards,

Mark

[jmburnod]

Hi Mark,
Thanks for your comment
I experiment the conversion from mac to windows which converts automaticaly the content of fields where I use numtochar(1) like itemdel.
Replacing numTochar(138) with numtochar(1) at the first open when the platform = "win32" seems working.

Kind regards
Jean-Marc

[Mark]

Hi Jean-Marc,

I think I misunderstood your original question. You mean that ASCII 1 is converted to ASCII 138 when you move your stacks from Mac to Windows. That shouldn't happen. I think this should be reported as a bug.

Kind regards,

Mark

[jmburnod]

Hi All
Is there someone to confirm this result before sending
a message to the quality center ?
Thanks

@Mark
Thank again for spend time to examine my bad english and also to share my confusion about macToIso in this case

Kind regards
Jean-Marc

[jacque]

According to an ASCII chart I have, some characters below ASCII 32 have values on Windows but no value on Mac, and ASCII 1 is one of those. So I think macToISO is doing the correct thing.

To be safe, use a character that is the same on both Mac and Windows. These include ASCII 3,8, and 22 -31. I usually choose ASCII 8 (the delete key) because the user cannot type it so I am sure it will never be in the text I'm parsing. I also like ASCII 3 (enter key) for the same reason.

Or you can do the conversion from 138 to 1 as you are doing now, which reverses the macToISO change. But it is easier to choose a character that won't change at all.

[Mark]

Jacque,

Those characters that have no value are control characters. They used to make the punch reader ring a bell and such things. They do have a value on Mac according to the ASCII charts I have, but you can't see them.

You can't convert ASCII 138, because there are languages using this character in normal texts. Assuming that ASCII 138 is the same as ASCII 1would corrupt the data.

Kind regards,

Mark

[jacque]

The MetaCard character viewer reports those as "Windows only" characters, which implies to me they have different values in WIndows than in Mac. I know what control characters are, but apparently Windows uses some of those differently now that we are no longer using teletype machines.

I have had good success using the characters in that chart that report compatibility in both Mac and Windows.

Edit: I shouldn't say "different values", I should have said "different uses". Naturally the numerical value doesn't change.

[jmburnod]

Jacque,
Thanks for your lights.

I usually choose ASCII 8 (the delete key) because the user cannot type it

I choosed ASCII 1 for the same reason

Mark,

You can't convert ASCII 138, because there are languages using this character in normal texts. Assuming that ASCII 138 is the same as ASCII 1would corrupt the data.

You're right I can do that for english and french but not for german neither for others langages.

Do you think it justifies a note in the LC dictionary ?

Kind regards
Jean-Marc

[jmburnod]

Hi All
Sorry. I forgot giving some news about this thread
Finally I choosed "©", numtochar(169) instead "ä" numtochar(138) as itemdel
Best regards
Jean-Marc