Re: display dialog bug
Re: display dialog bug
- Subject: Re: display dialog bug
- From: Christopher Nebel <email@hidden>
- Date: Mon, 20 Jun 2005 17:03:36 -0700
On Jun 20, 2005, at 4:28 PM, Paul Berkowitz wrote:
On 6/20/05 3:54 PM, "Christopher Nebel" <email@hidden> wrote:
On Jun 18, 2005, at 3:50 PM, Paul Berkowitz wrote:
There's a quirk with 'display dialog' in Tiger that has had enormous
consequences for many of my shareware script users...
What you describe has very little to do with "display dialog", and
mostly to do with how you're reading and writing to that
preferences file of yours.
Nevertheless to specify buttons as 'list of string' and then return
one of them as Unicode text is indeed quirky, to say the least. I
don't think you can fairly expect everyone to check what the flavor
of the month of the returned button is if you haven't changed the
type of the list of buttons. Make it all Unicode (which it is in
fact) in the Dictionary and get it over with.
In fact, it *has* been all Unicode text (at least for the buttons)
since Panther (maybe Jaguar -- not quite sure about that). The reason
it says "list of string" on the input side is that it accepts
"string" or "Unicode text" or any of the other text types, expressing
that in an 'aete' is awkward, and people in the past have gotten
fussy about under-specifying the type ("omg, it says it takes Unicode
text! now I have to coerce everything beforehand!"). It says it
returns "Unicode text", which it does, and that's the really
important bit.
If I give it a some text 'as string' to write (i.e.
write (someTextHere as string)
that seems to work fine. I do not seem to have to also do
write (someTextHere as string) as text
Are you saying that's not safe, that write itself needs an explicit
'as'
parameter - or may need it some day soon?
Those two things above are not semantically the same. In the first
case, you're making AppleScript do the coercion and relying on the
type semantics of "write"; in the second, you're specifying a data
format to "write". As it happens, they have the same net result, and
I think they will into the future -- much too much stuff would break
if we changed that. I think I prefer the second, because the intent
is clearer, but practically speaking it doesn't matter.
Similarly, at the moment 'read' always does 'read as text' if I
don't give it any other 'as something' parameter. In fact that's
the whole reason for my problem: it won't read 'as Unicode text'
unless you tell it to, it reads 'as string' by default, and always
has done. That's how I got those ASCII 0 characters when reading
(with no parameter) some Unicode. Might this change some day too -
so that it might default to 'as Unicode text'. That would break a
hell of a lot of scripts...
...which is precisely why we won't do that. (Probably. =) ) We have
been thinking about this problem, and while I can't discuss any of
the possible solutions, I will say that backward compatibility is
always a factor.
--Chris Nebel
AppleScript and Automator Engineering
_______________________________________________
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