Re: path to as string
Re: path to as string
- Subject: Re: path to as string
- From: has <email@hidden>
- Date: Wed, 29 Jun 2005 20:40:29 +0100
Paul Berkowitz wrote:
>As Shane says, if everything
>just worked smoothly, I wouldn't have to know any of this - but that's not
>the case. I need to know all about it so I can take care of things.
I'm not disagreeing; I'm well familiar with the problems caused by AppleScript's faulty abstractions. Still, I think it's easy for folk to miss the forest for the trees. The most important points would appear to be (E&OE; I'm sure folks like Messrs Nebel and Page will correct any obvious whoppers;):
1. AppleScript's 'string' type is basically a legacy feature, to be used when dealing with legacy applications that require it but otherwise avoided. Instead, use the 'Unicode text' type whenever possible. Strings may or may not contain hidden style information or international characters; users should not make assumptions about this.
2. Apps and osaxen that barf when given styled text should be considered buggy. [1] Therefore, users should immediately file bugs on these apps and osaxen (or at least those still under active development).
3. As a workaround to #2, when dealing with an app or osax that absolutely insists on getting unstyled text, users should feed their AppleScript strings through a standard cleaning command that removes any style info it might have. Since AppleScript provides no official coercion or command for doing this, they need to use alternate means.
--
Two ways (that I know of - there may be more) to guarantee an AppleScript string has no style:
1. The 'string as record' hack (note the suitably severe warnings, something folk have a habit of overlooking):
on asPlainText(str)
(* Strips any style information from an AppleScript string.
- WARNING: This is a bug exploit so is not guaranteed to work.
- WARNING: This hack completely ignores any text encoding information so is totally unsafe with anything except ASCII text.
*)
set str to str as string
try
return «class ktxt» of (str as record)
on error number -1700
return str
end try
end asPlainText
2. TextCommands 'convert from unicode' command, which takes Unicode text (or anything that the AEM can coerce to typeUnicodeText, including typeText, typeStyledText and typeIntlText) and returns an AEDesc of typeText. Unlike the above hack, this gives you full control over the target text encoding and how to deal with characters not covered by that encoding (error, omit or replace).
--
Finally, a really obvious point to anyone who manipulates textual data directly, regardless of language: make an effort to learn at least a little bit about how different text encoding systems work, what their limitations are, when to use them and how to convert between them. At minimum, I'd suggest knowing about ASCII, single-byte encodings such as Latin-1 and MacRoman, and the multi-byte UTF8 and UTF16 encodings used by Unicode. And, of course, learn the basics of the Unicode system; it's the way of the future as has been so for the last decade now.
If you don't know any of this then a lot of other stuff, including crap like the AppleScript shenanigans above, isn't going to make much sense to you. (Yeah, it sucks, but them's the cards we're currently dealt.)
has
[1] It's just sloppiness; if an app/osax specifically requires typeText, it should ask the Apple Event Manager to supply the value as typeText or coerce it itself.
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden