Re: path to as string
Re: path to as string
- Subject: Re: path to as string
- From: has <email@hidden>
- Date: Tue, 28 Jun 2005 21:59:50 +0100
Paul Berkowitz wrote:
>For a long time, before we had Unicode in AppleScript or on the Mac, we
>could get a certain proportion of non-MacRoman characters via typeIntlText.
>I wish someone would direct me to me specs for that type: it seems to be a
>sort of hack
International Text isn't a hack, it's just Apple's own early solution to the problem. The Unicode system came along later and became the de-facto standard thanks to wider adoption.
>For some time now the AppleScript term 'string' has encompassed typeText,
>typeStyledText and typeIntlText. If you ask any text in one of those formats
>what class it is, the result is 'string'.
That's because AppleScripters do not need to know. Or at least they shouldn't; sometimes the abstraction leaks a bit, at which point users find themselves having to hack it in order to get the job done. That's a bug.
>You can ask for the same text 'as
>record', and then typeStyledText and typeIntlText will return style
>information ´class kstyª as well as its plain text ´class ktxtª.
Note: that's a bug, not a feature.
>The whole text thing is such a mess. If you check TextEdit, you'll see that
>'document' has a 'text' property which is supposed to be of class 'text'
>(´class ctxtª this time).
Non sequitur. TextEdit's 'text' class is part of its Apple Event Object Model implementation; no relation to either AppleScript or Apple Event Manager types.
As for Cocoa Scripting's Text Suite being designed in such a way that causes users additional confusion about what's what - well, that's another issue. Rule #1 of AppleScripting: learn to know the difference between language and application. [1]
has
[1] FWIW, if you want a better understanding of how application scripting works, aem (on my site) might be a good place to start. It provides a high-level OO wrapper around the Apple Event Manager's low-level procedural C API, without any of the fancy tricks and terminology preferred by AppleScript, appscript, etc. that obfuscate the essential mechanics.
--
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