Re: Puzzling display dialog
Re: Puzzling display dialog
- Subject: Re: Puzzling display dialog
- From: kai <email@hidden>
- Date: Mon, 19 Feb 2007 15:55:59 +0000
On 19 Feb 2007, at 14:14, Emmanuel wrote:
At 7:51 PM -0600 2/18/07, Luther Fuller wrote:
A short follow-up: After clearing up the first problem, I changed
a few lines of code only to find that the problem had reappeared.
This time it was caused by an undefined variable - I had
accidentally commented out the line that set the value of the
variable. Easy fix.
Which prompts the question: Why am I getting the "The cancel
button cannot be the same as the default button." error when I
should be getting the "undefined variable" error? Very strange!
So, finally, will you show us a minimal weird-behaving piece of code?
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.
From the first reported scenario, I'd have expected a coercion
failure (error number -1700: "Can't make some data into the expected
type." - or similar). This would be the normal result from an
unsuccessful attempt to implicitly coerce a list (resulting from the
concatenation of an integer followed by text) to a string.
------------
1 & "2" --> {1, "2"}
display dialog result
--> error number -1700 [errAECoercionFail]: Can't make {1, "2"} into
type string.
------------
The second condition, involving the use of an undefined variable,
would normally produce an error number -2753.
------------
some_variable
--> error number -2753 [OSAUndefinedVariable]: "The variable
some_variable is not defined."
------------
However, the actual result in both cases appears to have been a
parameter error (number -50), strongly suggesting the possibility
that the errors are somehow being re-mapped.
The only way I'm able to reproduce that in the context of the error
message is with something like:
------------
try
display dialog "What kind of car do you drive?" buttons {"Cancel",
"Automatic", "Manual"} default button 3
error (* almost any error *)
on error number n
if n is not -128 then display alert "Oops." buttons {"OK"} default
button 1 cancel button 1
end try
--> error number -50 [paramErr]: "The cancel button cannot be the
same as the default button."
------------
If the explanation is not along these lines, then the behaviour is
puzzling indeed.
---
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