-- This works:
--set theIP to dotted decimal form of host of ("http://www.apple.com" as URL)
-- but this doesn't:
set theRef to text returned of (display dialog "Enter the URL for the IP address you want" default answer "http://www.apple.com" buttons {"Get it"} default button 1)
set theURL to theRef as URL -- this line fails
set theIP to dotted decimal form of host of theURL
What gives?
Found the answer in a previous post by Kai. It’s embedded here where it’s clear there are several coercions necessary:
display dialog dotted decimal form of (host of ((text returned of (display dialog "Please enter a URL:" default answer "http://www.apple.com/") as string as record)'s «class ktxt» as URL) & {dotted decimal form:"No connection."})
Yeah - I wonder if a short explanation might help to demystify this a bit, Adam.
The problem is that the coercion to URL evidently requires plain text as the input - and, from AppleScript 1.9.2 (Mac OS X 10.3), the display dialog command outputs Unicode text.
(I’ve long felt that AppleScript should feature a built-in coercion to plain text, precisely to deal with this kind of situation. Although we’re often told that this brave new world of Unicode text is the way forward, I guess it’ll still be some time before everything works together seamlessly. Until then, it looks like we’re stuck with workarounds.) 
On the face of it, one might assume that a straight coercion back to string would do the trick:
set a to "http://www.apple.com"
set b to a as Unicode text
set c to b as string
{a:a's class, b:b's class, c:c's class}
--> {a:string, b:Unicode text, c:string}
However, even though the variable c is classed as a string, this doesn’t necessarily mean it’s been reduced back to plain text. It is in fact styled text - as demonstrated by this little glimpse into the underlying structure of the values:
set a to ""
set b to a as Unicode text
set c to b as string
repeat with i in {a, b, c}
{a:{{text:a}} as string, b:{{text:b}} as string, c:{{text:c}} as string}
end repeat
--> result contains unpostable characters - so you'll just have to run the script for yourself! :P
Since neither Unicode nor styled text is any good for the coercion to URL, we have to find a way to strip out all the extraneous encoding before attempting it - hence the routine I suggested previously.
Another way to get close to what you were trying to do earlier might be:
set {text:theRef} to text returned of (display dialog "Enter the URL for the IP address you want" default answer ¬
"http://www.apple.com" buttons {"Get it"} default button 1) as string
set theURL to theRef as URL
set theIP to dotted decimal form of host of theURL
I’ve just got back to this Kai. Thank you for another of your very cogent explanations.
I find the plainOldText/UnicodeText endlessly confusing. BBEdit, for one example, saves as Unicode (of selectable type) and that means that simple searches don’t always work because the “Find” box seems to return pOT and the doc is in UcT. If you have BBEdit or TextWrangler you can see the extra coding by showing hidden characters - in between every letter there’s an inverted question mark for the leading bits of UcT. So the burning question as long as the possibility of this difference exists it how do you coerce something read from a text file to pOT in AppleScript? It’s not clear to me (even after your explanation) what the difference is between “as text” and “as string”.
Yeah, I sympathise, Adam. This string/text thing is just one of the consequences of having a more flexible vocabulary/syntax, I guess.
Essentially, there’s no difference between text and string in this context. They’re synonymous. The issue to which I was referring earlier actually relates to the style encoding that persists in a string/text after it has been coerced from Unicode text. There’s no such data in plain strings/text - just a series of ASCII characters.
For the most part, we shouldn’t need to overly concern ourselves about these differences when scripting. Much of it is intended to just work anyway. But every now and then, something might still jump out and bite us - as in the case above. What we really need for such situations (IMO) is an ‘official’ coercion that will produce plain text reliably - both now and for future releases of AppleScript. That’s really what I meant when I said:
In the meantime, we have a few workarounds that currently do the trick, albeit in a somewhat convoluted way. There are a number of possible variations - but here are just a few:
My personal favourite is the latter - an ingenious device dreamed up by Arthur Knapp that offers several benefits: it’s shorter, faster - and won’t error if fed plain text. So, to come back to your question about reading text files, I’d probably approach it like this:
set {text:t} to read (choose file) as string
-- do something with t
Thank you - quite ingenious. I think I’ll put that in a little handler called toPlainText() so I’m sure I know what I’m doing.