Re: AppleScript Editor's “tell” application pop-up menu (was Re: Mail Rule Scripts)
Re: AppleScript Editor's “tell” application pop-up menu (was Re: Mail Rule Scripts)
- Subject: Re: AppleScript Editor's “tell” application pop-up menu (was Re: Mail Rule Scripts)
- From: Emmanuel LEVY <email@hidden>
- Date: Sun, 23 Jan 2011 15:43:50 +0100
Wonderful feature, great it's available to all now.
The engineers who make Smile will be proud if we recall that the
"tell" menu was first introduced in Smile years ago.
Emmanuel
On Jan 23, 2011, at 11:59 AM, Chris Page wrote:
Not a direct answer to the OP, but I've been meaning to bring this
up and this thread seems like a good opportunity:
In Mac OS X 10.6 we introduced a new feature to AppleScript Editor
to aid in developing scripts that are intended to be run within
specific applications, e.g., Mail rule scripts. It's called the
“tell application” menu (or "tell" menu for short), and it can be
enabled via Preferences > Editing > Show “tell” application pop-up
menu. This menu appears in the Navigation Bar above the script, next
to the language selection pop-up.
The “tell” menu selects the “default target” for scripts. It behaves
as if the entire script were surrounded by a “tell” block targeting
that application (which is generally not syntactically possible,
since, for example, you can't declare properties or top-level
handlers inside a tell block). Any event/command that would normally
be sent to the current application is sent to the default target.
This effectively replaces many uses of both "using terms from" and
"tell application".
This has several uses:
1. You can compile and edit, e.g., Mail rule scripts without
including “using terms from” or 'tell application "Mail"' at all.
This can simplify the process of writing and editing scripts, and
enables you to use Mail terminology in places you couldn't before,
e.g., to initialize properties:
property acct : account "Mobile Me"
2. You can run scripts within AppleScript Editor whose run handler
would be invoked by the target application, for testing purposes.
3. You can use it to test scripts like Mail rules in AppleScript
Editor by having the run handler invoke the appropriate Mail-
specific handler with sample arguments, but without inserting "using
terms from" and "tell" blocks, simplifying testing code.
4. You can use it as a sort of AppleScript command line, issuing
individual commands without writing tell blocks. Then Select All and
write another command to replace it, then run that, and so on. (And,
of course, this works with any OSA script language.)
5. Expanding on #4, you can use it to quickly write and run
exploratory scripts. e.g., I often use this to run little scripts
like "accounts" to see all the accounts in Mail, then I might expand
it to "mailboxes of accounts" or "properties of mailbox 1 of account
1", then perhaps "unread count of mailboxes of account 1" and so on,
exploring the hierarchy and properties, and then perhaps expanding
into a more complete script. Being able to use Command-A to Select
All and immediately replace the whole script makes this a little
quicker and easier.
6. Quickly compare how scripts compile and behave with different
target applications. e.g., you might see how different applications
handle "get every window" by writing the script once and then
changing the "tell" setting and running it. In Mail, "folder" is a
property, but in Finder it's a class. Similarly, "path to desktop"
compiles differently (and script formatting shows the difference in
how "desktop" is interpreted). If you compile a script then switch
targets, the script will return to plain text and you can compile it
with the new target application and see how (and whether) it
compiles, and, depending on the script, run it to see how its
behavior compares. Moreover, if you press the Option key when
switching, it will leave compiled scripts as-is so you can run them
using the terminology from the original target. This can be helpful
for learning about the language and about application terminology
differences, and for discovering or isolating script bugs that occur
due to terminology conflicts or events being sent to a different
application from the one you expected.
The "tell application" setting is saved with each script document
and applies whenever it's open in AppleScript Editor. (It does not
have any effect outside of AppleScript Editor. When the script is
run within, say, Mail, it naturally treats Mail as the default
target since it's the current application.)
The applications available in the "tell" menu come from the Library
window. Choose Window > Library to view it. You can add and remove
applications there.
--
Chris Page
The other, other AppleScript Chris
On Jan 22, 2011, at 10:56 PM, Matthew Smith wrote:
Try:
using terms from application "Mail"
on perform mail action with messages messageList
tell application "Mail"
repeat with a from 1 to count of the messageList
set fromMsg to (sender of item a of messageList as string)
set subjMsg to (subject of item a of messageList as string)
set todoMsg to fromMsg & subjMsg
tell application "iCal"
tell calendar "Mail To Do"
set theDueDate to (current date)
make new todo at end with properties {summary:todoMsg, due
date:theDueDate}
end tell
end tell
end repeat
end tell
end perform mail action with messages
end using terms from
Matthew Smith
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (applescript-
email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden
_______________________________________________
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/archives/applescript-users
This email sent to email@hidden