Re: Time to figure out what is going on... (fixed)
Re: Time to figure out what is going on... (fixed)
- Subject: Re: Time to figure out what is going on... (fixed)
- From: kai <email@hidden>
- Date: Thu, 25 Aug 2005 06:57:00 +0100
On 22 Aug 2005, at 21:03, Glenn Sugden wrote:
tell application "System Events"
tell application process "Mail"
activate -- doesn't work
click...
.
.
.
So it looks like Mail does need to be "reactivated" to have the
front window (and therefore menu) available...
When using UI scripting, it can often help to explicitly bring the
target process to the front (and doing so is still essential when
executing a keystroke).
...and having an "activate" within the "tell process..." block
doesn't do squat.
While it's possible to activate an application, the same is not true
of a process. Run the 'tell process' block with the Event Log open to
see what happens:
----------
-- Script:
tell application "System Events"
tell application process "Mail"
activate
end tell
end tell
-- Event Log:
tell application "System Events"
activate
end tell
----------
And since System Events is a faceless app, it can't really come to
the front - so nothing much is achieved.
In fact, to be honest, I'm not sure if it even makes sense to
have "activate" within that process block...
It doesn't, really. As Deivy rightly pointed out, a process is
brought to the front by setting its frontmost property to true:
----------
-- Script:
tell application "System Events"
tell application process "Mail"
set frontmost to true
end tell
end tell
-- Event Log:
tell application "System Events"
set frontmost of application process "Mail" to true
end tell
----------
If a menu item has a keystroke equivalent, you could even use that
instead of clicking menus. (As mentioned, the target process must be
frontmost.) This technique is especially useful when trying to access
certain sub-menus - since nailing down a nested menu item can
sometimes result in a somewhat convoluted statement. So this should
also open a new viewer window in Mail:
----------
tell application "System Events" to tell process "Mail"
set frontmost to true
keystroke "n" using {option down, command down}
end tell
----------
However, I generally resort to UI scripting only when all other
attempts have failed. Looking at your original script, I believe it
should be possible to achieve something very similar by addressing
Mail directly - perhaps with something like this (some lines may need
to be rejoined):
----------
on newViewers for unread_mailbox_list
tell application "Mail" to repeat with currMailbox in
unread_mailbox_list
set msgList to (currMailbox's messages whose read status is
false and deleted status is false)
if (count msgList) > 0 then tell (make new message viewer
with properties ¬
{selected mailboxes:{currMailbox}}) to set {visible
messages, preview pane is visible} to {msgList, true}
end repeat
end newViewers
tell application "Mail" to repeat with unread_mailbox_list in ¬
{front message viewer's selected mailboxes, mailboxes whose
unread count > 0}
tell unread_mailbox_list to if (count) > 0 then return my
(newViewers for it)
end repeat
----------
But let's get back to clicking menu items for a moment - since it
seems there *is* a bug when executing a script from Script Menu...
When run from Script Editor or an applet, most scripted menu clicks
now work consistently here (Tiger 10.4.2) - without any explicit
"activate" or "frontmost" commands. So, taking the original script in
this thread as an example, this single-line statement does exactly
what it says on the tin[1]:
----------
click menu item "New Viewer Window" of menu 1 of menu bar item "File"
of menu bar 1 of process "Mail"
----------
The same statement *can* still work when run from Script Menu - but
evidently not when Finder or the target application (in this case
Mail) are already frontmost when the script is selected. (These
somewhat curious exceptions may be responsible for some of the
differing reports when running such scripts from SM.) An explicit
activate/frontmost command would be required to work around these
anomalies.
As a cross-check, the behaviour when running from FastScripts is
slightly different again. The statement works, even if the target app
is frontmost - but still fails when Finder is at the front. (Might
this be a Cocoa thing?)
And yes, I'll willingly file a bug on all this - unless anyone else's
experience differs substantially... :-)
---
kai
[1] There are some behavioural variations. If the application is
hidden when the script is run, it will be activated - and the new
window will appear behind any current ones. If the app is visible but
not frontmost, the existing windows will stay in the same layer - and
the new one will appear in front of all other apps/windows (apart
from the SE window from which the script is executed).
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden