Re: display dialog bug
Re: display dialog bug
- Subject: Re: display dialog bug
- From: Paul Berkowitz <email@hidden>
- Date: Mon, 20 Jun 2005 16:28:35 -0700
- Thread-topic: display dialog bug
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.
> "read" and "write" are not at all smart about the
> encoding they use. If you want your old behavior back (which,
> incidentally, will not be Unicode-safe), then add an explicit "as
> text" to all the relevant "read" and "write" commands. Do not
> attempt to patch up the strings afterward by deleting all the nulls
> -- it's hard, and won't work with non-ASCII characters anyway. (Yes,
> I mean non-*ASCII*, not "non-MacRoman.")
Right, no point in getting rid of ASCII 0. 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?
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...
It doesn't hurt to spell it out, I guess.
>
> If you want to be Unicode-safe about your data, use "as Unicode text"
> instead of "as text", though of course that will not work for
> existing data files. I'd recommend using the plist APIs to store all
> your information, but that's not practical from pure AppleScript yet.
Right. And this is a script that still has to work in Panther as well as
Tiger. For the moment, I've decided to write and read 'as string' explicitly
since there are a few other values (not connected with returned buttons)
that are string, and people with existing older versions of the script who
will be updating to newer versions. I think the update will work smoother
this way. In due course, I can see explicitly writing these values as
Unicode text and reading them back explicitly as Unicode text. Or - who
knows - you may have plists working well by then too. The equality coercions
for Unicode equivalents of ASCII to real ASCII work fine, so there's no
problem there.
--
Paul Berkowitz
_______________________________________________
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