Re: waiting for Mail to complete a send
Re: waiting for Mail to complete a send
- Subject: Re: waiting for Mail to complete a send
- From: kai <email@hidden>
- Date: Sun, 11 Dec 2005 22:25:42 +0000
On 5 Dec 2005, at 23:38, Jim Brandt wrote:
This piece of a script worked before Tiger and Mail version 2.0.
The intent was to select a particular message to send, wait until
it was sent
and then quit the mail application.
Unless the message is extremely short, most of the time Mail quits
before
the message has finished sending and I have to restart Mail to get
it to
complete.
Is there a more appropriate way to wait for the send action to
complete?
Does the "Out" mailbox even exist anymore in Mail?
Just noticed this while doing a bit of catching up, Jim - so
apologies for the delayed response.
Dealing with your last question first, the "Out" mailbox still
exists. Its name is actually "Outbox", although the two labels are
synonymous. However, for situations like this, I generally use the
application property for the top level mailbox: outbox. (Whichever
identifier you use, this particular mailbox is usually only visible
when it contains messages waiting to be sent.) The other top level
boxes are: inbox ("Inbox"), sent mailbox ("Sent"), trash mailbox
("Trash"/"Deleted Messages"), drafts mailbox ("Drafts") and junk
mailbox ("Junk").
So, if a mailbox's presence/absence, or the name you're using for it,
isn't the cause of your problem - what is?
I was interested to read Matt N's recent story (http://tinyurl.com/
cshz2), which began:
This kind of thing (a sudden burst of speed) really can cause
problems...
Whatever changed in Tiger/Mail 2, I believe the behaviour you're now
experiencing is related mainly to timing issues. Here's my take on
what happens in your script:
-------------------------
tell application "Mail"
-- first, identify the target message:
set msgList to outgoing messages
repeat with msg in msgList
if subject of msg is thedate then
set msgID to msg
exit repeat
end if
end repeat
(* the above repeat loop shouldn't normally be necessary - but see
below *)
-- send the identified message:
send msgID
-- at this point the message should be moved to Mail's outbox...
-- however, as the repeat loop below is about to be entered, the
message hasn't yet reached the outbox
-- and, because 'messages of mailbox "Out" is {}', the loop is
skipped
repeat until (messages of mailbox "Out" is {})
tell application "System Events" to do shell script "sleep 5"
end repeat
-- so Mail receives a 'quit' command even *before* the message can
be sent:
quit
end tell
-------------------------
I suspect that your shorter messages are sneaking under the wire -
before Mail completes its quit routine - while the sending of a
longer message is cut off in its prime. This means that, before we
start checking for an empty outbox, we need to make sure our message
has actually hit Mail's outbox. Generally, I'd expect something like
this to work pretty well:
-----------------------
tell application "Mail"
tell (first outgoing message whose subject is thedate) to if exists
then
send
repeat while exists
delay 1
end repeat
end if
repeat until (count outbox's messages) is 0
delay 2
end repeat
quit
end tell
-----------------------
Would that life in general, and Mail scripting in particular, were
that simple...
In fact, this works fine - as long as every outgoing message has been
created by a script. However, Mail presents us with yet another issue
involving manually produced outgoing messages. This probably hasn't
yet manifested itself at your end - since I'd have expected your
script to produce an error under such conditions. Nevertheless, the
potential for this kind of error/failure exists, as demonstrated by
this next example...
Of the 3 outgoing messages involved in the following tests, only
message #2 was created by a script (using the 'make new outgoing
message' command):
----------------
tell application "Mail" to outgoing messages
--> {application "Mail", outgoing message id 80711712 of application
"Mail", application "Mail"}
----------------
These references to the application suggest that the manually created
messages (items #1 and #3) have been assigned no properties. Closer
inspection bears out this possibility:
================
tell application "Mail" to outgoing message 1
--> [no result]
----------------
tell application "Mail" to outgoing message 2
--> outgoing message id 80711712 of application "Mail"
================
tell application "Mail" to properties of outgoing message 1
--> [error:] "NSReceiverEvaluationScriptError: 3"
----------------
tell application "Mail" to properties of outgoing message 2
--> {message signature:missing value, visible:true, html
content:missing value, vcard path:missing value, class:outgoing
message, sender:"kai <email@hidden>", subject:"some
subject", content:"some content", id:80711712}
================
So it seems that, as soon as we try to extract a property from a
manually created outgoing message, our script is likely to bomb. This
caveat extends to conditional filter statements, such as that in my
suggested script above (which, even though it doesn't error, can fail
silently nonetheless - as if none of the outgoing messages meet the
filter's criteria). Aye Caramba! :-/
All this brings us back to the last resort of a repeat loop,
constructed carefully enough (one hopes) to take account of Mail's
current batch of idiosyncrasies:
-----------------------
tell application "Mail"
repeat with m in outgoing messages
tell m to try
if subject is thedate then
send
repeat while exists
delay 1
end repeat
exit repeat
end if
end try
end repeat
repeat until (count outbox's messages) is 0
delay 2
end repeat
quit
end tell
-----------------------
That works well enough for me - so I hope it does the trick for you,
too. Let's just keep our fingers crossed that a few fixes for Mail
scripting are forthcoming soon...
:-)
---
kai
_______________________________________________
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