I would have searched, but I couldn’t figure out what to search for…
Can someone tell me what I am missing with this display dialog issue?
If I run this script:
set theFilePath to ((path to desktop) & "test.txt") as text
set theText to text returned of (display dialog "Some Text" default answer "0101")
set theFile to (open for access file theFilePath with write permission)
set eof of theFile to 0
write theText to theFile
close access theFile
set theText2 to read file theFilePath as text
theText2 reads back in strangely. It looks like “0101” but if you click the arrow buttons to move between the characters you have to click twice to move the cursor. It is the same way in the text file.
If I coerce theText to text after the display dialog command, it works fine:
set theFilePath to ((path to desktop) & "test.txt") as text
set theText to text returned of (display dialog "Some Text" default answer "0101") as text--this is the change!!
set theFile to (open for access file theFilePath with write permission)
set eof of theFile to 0
write theText to theFile
close access theFile
set theText2 to read file theFilePath as text
So I have a workaround, I am just looking to find out why it’s doing this cuz it’s buggin me.
You don’t say what system you’re using, but you are observing the difference between UTF-8 and Unicode. In the first instance, 8 bits are used to describe a letter in ASCII, but in Unicode (which OS X now defaults to) 16 bits are used to provide enough code to describe foreign language characters. Only one character shows, but it takes two moves to cover each one.
So is this expected behavior when running the script the way I have the first one written? Seems I shouldn’t have to coerce the text to text to get it to write correctly to TextEdit.
the main rule is: read the text always the same way as you write it.
So omit the as text parameter in the read line.
Anyway in Tiger you should prefer as string to get the primary text encoding (McRoman).
The read/write behavior in Tiger is:
¢ no parameter or as string : MacRoman
¢ as «class utf8» : UTF8
¢ as Unicode text : UTF16
In Tiger and earlier:
¢ write with no parameter : the current class of the item is written to file.
write as string : MacRoman written to file.
read with no parameter or as string : file data interpreted as MacRoman, returned as string.
In Leopard and later:
¢ write (text) with no parameter or as string : MacRoman written to file.
read with no parameter or as string : file data interpreted as MacRoman, returned to the script as (Unicode) text.
All OS X systems:
as «class utf» or as Unicode text : the specified class is written to file or the file data is understood to be of the specified class and is read into to the script as Unicode text. Unicode text (UTF16) data is written as big-endian and is assumed to be such unless the data begin with a little-endian BOM.
Note that as here is a parameter of the read/write commands, not the AppleScript coercion.
For maximum compatibility, it’s now recommended always to use the as parameter, which works the same way on all systems.
And Nigel too!
I can’t remember if the PPC is Big Endian or Little Endian, but I guess I’d heard it if the two systems weren’t compatible with each other.
At AppleScript Users list there were a recent post reporting that the ¹class isotº coercion trick doesn’t work anymore, but i believe that was in another context than when coercing data to be read or written, I will however examine those coercions personally, which are demonstrated in your excellent article about reading and writing files.
The examples in the above mentioned excellent tutorial still works.
It seems that I can’t find the mail I am referring to in my mailbox, nor with spotlight so I guessed I spotted it somewhere here in a different context regarding coercions that were no longer possible.
The PPC, like the 68000 before it, is Big Endian. The File Read/Write commands still default to Big Endian for compatibility. However, there’s a bug where Intel machines get it wrong when reading back as double integer or as date.
The «class isot» hack was a convenient way to switch between ISO-format date/time strings and AppleScript dates. The «class isot» class wasn’t supposed to be known about by scripters and its coercion to/from string probably only worked because the two sets of data are identical apart from the class bits. It’s not possible to coerce between «class isot» and Unicode text, which is why the hack doesn’t work in Leopard or later.
One way to get round Intel processors’s inability to read AppleScript dates correctly from file is to write and read the dates as «class isot» instead. This still works in Snow Leopard:
set theFilePath to (path to desktop as text) & "test.txt"
set cd to current date
set theFile to (open for access file theFilePath with write permission)
try
set eof theFile to 0
write cd as «class isot» to theFile
end try
close access theFile
set theDate to (read file theFilePath as «class isot») as date
Obviously, the File Read/Write commands can be used as a hack to implement the ‘date as «class isot» as string’ hack! But it’s probably not worth the bother:
set theFilePath to (path to desktop as desk) & "test.txt"
set cd to current date
set theFile to (open for access file theFilePath with write permission)
try
set eof theFile to 0
write cd as «class isot» to theFile
set ISOTtxt to (read file theFilePath from 1 as string)
end try
close access theFile
ISOTtxt -->"2010-06-23T21:37:12" (or whatever)
And Nigel too!