Re: Puzzling display dialog
Re: Puzzling display dialog
- Subject: Re: Puzzling display dialog
- From: kai <email@hidden>
- Date: Mon, 19 Feb 2007 23:00:11 +0000
On 19 Feb 2007, at 19:15, Luther Fuller wrote:
On Feb 19, 2007, at 9:55 AM, kai wrote:
A distilled, stand-alone snippet would really be the best way for
others to confirm whether or not the problem can be reproduced on
their machines. Under the conditions outlined so far, I certainly
can't replicate it here.
If the code mentioned is part of a larger, more complex script,
then I'd probably check to establish that the routine was not
somehow wrapped in a try statement, where the error handler
contains an alert.
Both errors were Finder errors.
They may have been reported by Finder, but they'd still have been the
errors that I described earlier. (The examples I gave were in
stripped down form, merely for the sake of simplicity.)
Last time I looked, error number -1700 [errAECoercionFail] was an
Apple event manager message, and number -2753 [OSAUndefinedVariable]
was a static AppleScript error (a parse and compile-time exception
that might also occur at runtime).
The first was caused by trying to write an integer to a file
comment instead of Unicode text. The second was caused by trying to
write an undefined value via the Finder.
That's not quite the case. By itself, an integer can be coerced to
text automatically, so it wouldn't normally produce an error.
Something like this, for example, should work:
----------------
tell application "Finder" to set comment of (choose file without
invisibles) to 104
----------------
As I suggested earlier, concatenating an integer and text produces a
multi-item list, which wouldn't normally be coerced to text
automatically - and which would therefore result in the coercion
failure (error number -1700). So this errors:
----------------
tell application "Finder" to set comment of (choose file without
invisibles) to 10 & "four"
----------------
From the Event Log:
tell application "Finder"
choose file without invisibles
alias "path:to:some:file.txt"
set comment of alias "path:to:some:file.txt" to {10, "four"} -- note
the list here
"Finder got an error: Can't make some data into the expected type."
Both errors were preceeded by a 'display dialog', but the error was
in the Finder. The Finder did not pass the error to my script (I
tested explicitly for this), but simply presented an error dialog
(with my application's icon).
At this point, I can't help feeling that the display dialog command
is a bit of a red herring. Are you saying that the parameter error
("The cancel button cannot be the same as the default button.")
*doesn't* result when an error occurs - and when the dialog statement
is commented out?
And ... yes, this is part of a very much "larger, more complex
script". Since I've fixed the problem, I'm not going to worry to
much about reproducing for now. There are other things that need
doing now.
Pity. We might have been able to collectively learn/report/fix
something from sharing that...
I was just curious if anyone had seen this behavior before.
So far, only when attempting to display an alert (but not a dialog)
that defines the cancel button as the default button.
----------------
display alert "Maybe that wasn't such a good idea." buttons
{"Cancel"} cancel button "Cancel"
----------------
display alert "Choose your weapons." buttons {"Swords", "Pistols",
"Feather Dusters"} cancel button 3
----------------
---
kai
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/mailman//archives/applescript-users
This email sent to email@hidden