Re: Parents/Child Scripts
Re: Parents/Child Scripts
- Subject: Re: Parents/Child Scripts
- From: Paul Skinner <email@hidden>
- Date: Tue, 14 May 2002 13:22:44 -0400
On Monday, May 13, 2002, at 09:56 PM, has wrote:
Paul Skinner
The only time you can wrap or replace
an osax call with 100% reliability is when that osax call contains no
optional parameters, eg:
Au contraire mon ami. Opps, I mean Bollocks!
on display dialog (parameters)
[...]
end display dialog
Try:
display dialog "African or European Swallow?" buttons {"YES", "NO"}
Bollocks!
You'll get a dialog saying "African or European Swallow?" all right,
but it
will display only an "OK" button. Sorry, but the "record as optional
parameters" doesn't cut it here: you still end up knackering the
existing
display dialog functionality.
It's knackered alright! And it's the 'records as optional
parameters' fault! I shouldn't have used them with Display Dialog. I
should have used the terms everyone expects it to accept. (see below)
But even that wouldn't have helped. (see below) It seems that when the
Handler intercepts the parameters that were sent to DD OSAX it doesn't
get anything but the required parameter.
on display dialog (parameters)
return parameters
end display dialog
display dialog "Hello World" buttons {"Yes", "No"} giving up after 5
-->"Hello World"
As soon as I took the call all of the optional parameters were
lost! All I recieved was the text.
Here it seems that the real crux of the matter is that AppleScript
isn't passing the optional parameters that are allowed in the DD call
along with the required ones. I don't know if that's the way it's
designed to work or a bug. I doubt if they anticipated this usage.
display dialog ({message:"Hello World", buttonlist:{"Don't push me",
"Push me"}, defaultButton:"Don't push me", IconSpec:1})
Users already expect a certain interface from "display dialog". By
changing
that interface all you're really doing is confounding their expectations
and causing confusion. Instead, it'd be better to name your handler
differently, e.g. "displayDialog()".
Damn straight! Don't try this at home. I was just playing along
with the whole 'overriding OSAXen' thing because I thought there might
be a chance to plug 'records as optional parameters' ;^)
Of course if Applescript supported optional parameters then we
could nicely override Display Dialog without the user being any the
wiser...
--Display Dialog is redirected to display in the the frontmost
application.
--Note! As it stands this will make every parameter required for Display
Dialog calls.
--Don't like it? Write your Apple representative!
--Demand an optional parameter in every pot*. *MrTea's excluded.
on display dialog messageText default answer defaultAnswer buttons
buttonlist default button defaultButton with icon IconSpec giving up
after givingUpAfter
if IconSpec is not in {0, 1, 2} then set IconSpec to missing value
if givingUpAfter is missing value then set givingUpAfter to 60
if buttonlist is missing value then set buttonlist to {"Cancel", "OK"}
if defaultButton is missing value then set defaultButton to last
item of buttonlist
if defaultAnswer is missing value then
tell application (path to the frontmost application as text)
continue display dialog messageText buttons buttonlist
default button defaultButton with icon IconSpec giving up after
givingUpAfter
end tell
return result
else
tell application (path to the frontmost application as text)
continue display dialog messageText default answer
defaultAnswer buttons buttonlist default button defaultButton with icon
IconSpec giving up after givingUpAfter
end tell
return result
end if
end display dialog
display dialog "Hello world!" default answer "Please enter some text
here." buttons {"Clear", "Ok"} default button "Ok" with icon 1 giving up
after 5
--Since we can't have optional parameters they all have to be supplied
now. Missing value is a crutch here.
display dialog "Hello world!" default answer missing value buttons
missing value default button missing value with icon missing value
giving up after missing value
--Yuck! If optional parameters were allowed we could call it with...
display dialog "Hello world!"
Now folks will go read your documentation and learn how to use this new
handler in its own right. Both handlers will [continue to] function
as-per
user expectation, and so the world is happy again. (Or as happy as it
can
be without optional flippin' params...:p)
Ouch! Now quit poking me in that same old documentation spot!
Sorry, Paul, but "au contraire" back at you. (Don't argue now, else I
shall
have to say "Nee!" at you.)
Who are you who are so wise in the ways of science?
I'm not going to argue. You're right.
In this case (overriding OSAXen) records as parameters aren't the
solution to the lack of optional parameters. And while they are great
for some handlers, they are not a replacement for real optional
parameters.
There, I said it, happy? :)
has (no ordinary rabbit;)
p.s. OT aside: your script also reminds me why I never use single,
real-English words as identifiers. Some osax I've got installed decided
that the term "message" belonged to it and "helpfully" turned it into
keyword for me, resulting in a runtime error. This is why, in the
absence
of anything better, I'll prefix any such names with "the" - i.e.
"theMessage", "theParameters". With all these osaxen around, the world
isn't a safe place for uncompiled scripts with single-word variable
names
in them...:p
OSAXen authors had better use something other than single
real-English words. They're mine! They can have them when they prise the
key caps off my cold dead powerbook. Such OSAXen are summarily
dispatched from my system and their author's receive a testy email. If I
can find their email address. I know that documentation is around here
somewhere...click click clickedy click click...
; P
--
Paul Skinner
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.