display dialog bug
display dialog bug
- Subject: display dialog bug
- From: Paul Berkowitz <email@hidden>
- Date: Sat, 18 Jun 2005 15:50:46 -0700
- Thread-topic: display dialog bug
There's a quirk with 'display dialog' in Tiger that has had enormous
consequences for many of my shareware script users, resulting in their
losing their entire databases of address book contacts in some cases. It was
the most difficult thing to track down that I think I have ever faced,
seeming mysterious and impossible to reproduce. (Now that I've finally
reproduced it, I still can't quite figure out why I couldn't reproduce it
earlier. It was only after running the Run-Only version of the script which
I distribute to users that I was able to repro for the first time. Now I can
repro endlessly from the source script too.)
And it's all to do with a change in the Standard Additions dictionary. In
Tiger, the display dialog dictionary entry has gained some parameters, but
it still says:
display dialog string : the text to display in the dialog box
[buttons list of string] : a list of up to three button names
→ dialog reply : a record containing the button clicked and text entered
(if any)
Meanwhile:
dialog reply n : Reply record for the ‘display dialog’ command
properties
button returned (Unicode text, r/o) : name of button chosen (empty if
‘giving up after’ was supplied and dialog timed out)
So: 'buttons' is a list of _string_, but button returned is _Unicode text_.
Hands up all those who noticed that. In fact, all the various 'string' types
listed in display dialog, including 'buttons', will now take Unicode text if
you can figure out a way of getting it in there. (For example, set a
variable to a Unicode property of some application and set that variable as
a button in a display dialog.) If the dictionary said so accurately, I might
have noticed.
As it is, I have a PREFS script that sets various preference properties to
the results of display dialogs and then writes them to a text file,
separated by a delimiter. In one case, I save time by concatenating three
properties together first, before writing to file. Of course, in Tiger where
concatenations of string and Unicode becomes Unicode no matter which is
listed first, the two values which really were still string now become
Unicode too.
Then, in my main script, when I read back the values in the prefs file and
set them to properties there, I had no idea that in Tiger I now should be
reading it back 'as Unicode text'. If I had, the results would have coerced
to string OK when checking for their value against strings. But since I
didn't know, and they were read back as TEXT, they contained interspersed
invisible characters of ASCII number 0. (Oddly, the original string values
that became Unicode only via concatenation seemed to be double-byte: there
were 3 ASCII 0 characters before every "genuine" character, whereas the
value that became Unicode thanks to display dialog's 'button returned' had
only one ASCII 0 character before every genuine character.)
Now these strings read back are NOT equal to the plain strings which they
look exactly like, and created all sorts of problems. When trying to reset
prefs, having a 'default button' set to one of these produced the mysterious
error "The specified button does not exist." Working round that didn't help
because the new result would get Unicodized again. Much worse, in the main
script, any construction such as
if a = "Last" then
-- do this
else
-- do that
end if
would always 'do that' when a simply "looked like" Last but actually had
invisible ASCII 0 characters littered throughout it. The result of 'do
that' in this case meant that all their contacts in both Entourage and
Address Book could get deleted if the also had a deletion preference in
effect. Very bad.
Now I just have to figure out if it's better to coerce the original values
to string when getting the results from display dialog, or when writing to
file, or to let it go ahead as Unicode and then read back 'as Unicode text'.
The main script is so long, with so many places where this could go wrong,
that it might be simplest to control it by coercing these values to string
just before writing to file. (I notice that the file does not even contain
the tell-tale 'utxt' key for these values as it does for lists of Unicode
values I also write to file. It doesn't seem to know.)
--
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