Re: Handlers and Tell Blocks
Re: Handlers and Tell Blocks
- Subject: Re: Handlers and Tell Blocks
- From: Paul Berkowitz <email@hidden>
- Date: Wed, 28 Aug 2002 09:22:15 -0700
On 8/28/02 5:10 AM, "has" <email@hidden> wrote:
>
>
> Handlers require their own internal application tell blocks and are
>
> impervious to application tell blocks in which they may be called.
>
>
This statement's confusing, but if you mean what I think you mean, then no.
>
If you send a message from within a tell block, that message will be
>
received by the object specified by that tell block. Now, whether that
>
target is an application object, script object or any other sort of object
>
has no bearing on the message dispatch process. And what that object does
>
with the message it subsequently receives is entirely up to it.
I meant a HANDLER, which i think I said there. Sorry if it was confusing. If
you call a handler within a tell block, the tell block has no effect on the
handler. The handler needs its own internal tell blocks, should you happen
to want any. The handler belongs to the script, not the application, once
you call it with 'my', and is free of the tell block in which the call
occurs.
The whole discussion, which I know was very confusing, was prompted by a
study of the Mail Scripts which Apple kindly provided. They are much more
modular and OOP than most of my own scripts, and the author has usually set
them up so that he tells objects directly, rather than using all the 'of
some object' construction. This goes so far as to be calling handlers which
use application keywords - properties of the objects he's telling - without
bothering with variables when calling. (In the handler declarations
themselves, they of course are represented by variables). Like this:
tell application "Microsoft Entourage"
tell eachContact
theScript's setFirstName(newEntry, first name)
theScript's setLastName(newEntry, last name)
theScript's setTitle(newEntry, title)
...
In this case 'first name', 'last name' and 'title' are all keywords of
Entourage: property labels of 'contact'. If you go to the handler being
called in the Import Helper script, you find it's called
on setFirstName(theCard, theValue)
where 'theValue' is a parameter that represents 'first name' of 'contact' as
far as Entourage is concerned but might well have been 'FirstName' property
'entry' for some other application using this second Helper script.
Later on, he gets into more of a twist, where inside the Entourage tell
block is a secondary call to application "Address Book". I'm aware that this
is not ideal (it _does_ involve Apple Event calls to Address Book through
Entourage, which is wasteful - don't tell me not to bother with this!) but
did save the author a lot of complicated sorting-out he'd otherwise have to
do. (I'd quote it here, but it's going to be awfully confusing without text
formatting, particularly as both applications have a class 'group'.)
That's what started me thinking that there might well be cases when it might
be OK to call one app inside inside another, especially if it's only for a
line or two to call another handler with 'my'. I got a bit carried away with
it in my example (based on a real-life example, but boiled down out of all
meaning). I'll try to come up with a better example. My own practice has
always been to throw in more variables so I can close out the tell block,
then make the handler call outside the tell block. Sometimes - when the
application property concerned evaluates to a string, say, it seems
"cleaner" that way, but perhaps is unnecessary. That's what I was wondering.
In other cases, where the parameter remains an application object, it may
gain nothing - it might even be better to call from within the tell block,
for all I know. My example included both types. I'll try again later, with
smaller, clearer units. Thanks for giving it a go, anyway.
--
Paul Berkowitz
_______________________________________________
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.