I have tried to use the
background activity count
in Mail.app to determine when a task is done but I just get an error message error
"Mail got an error: AppleEvent handler failed." number -10000
. Is it broken or am I using the wrong syntax? Something like:
tell application "Mail"
activate
repeat until background activity count = 0
delay 0.5
end repeat
end tell
Would be very appreciated if someone else could verify this.
Thank you.
No one knows anything about this?
It looks like that’s broken.
I get the same error message when I run your script. Plus I get the same error message if I try send a command to get:
properties
background activity count
fetches automatically
primary email
But, other application properties, like application version work fine.
In Script Debugger, if I look at the application properties in the Explorer window, I see the same error message for those properties.
→ Script Debugger 8.0.6 (8A62)
→ MacOS 12.4
→ Mail 3696.100.31
tell application "Mail"
application version --works (as do most other application properties)
properties --errors
background activity count --errors
fetches automatically --errors
primary email --errors
end tell
Interesting. Please let us know what MacOS version and mail version you’re running. Your script generates an error on my system. And, as with the application properties, when I inspect the account properties in the Script Debugger explorer view, it also shows an error for some.
Some properties work, and some don’t (the ones that don’t in a script show errors in the Script Debugger explorer too).
Also, getting the account properties doesn’t help answer the OP question about background activity count.
Do those scripts generate errors on your mac?
tell application "Mail"
tell account 1
its account type-- works
its enabled-- errors
its properties -- errors
end tell
end tell
Fredrik71,
As you rightly pointed out, using ScriptingBridge allows access to problematic properties of the application.
But you are mistakenly using the backgroundActivityCount property instead of the backgroundActivityCount() method. Which by the way correctly returns an integer as a result without the need for any coercions.
Â
use framework "Foundation"
use framework "ScriptingBridge"
use scripting additions
set theApp to current application's SBApplication's applicationWithBundleIdentifier:"com.apple.Mail"
theApp's |activate|()
repeat until (theApp's backgroundActivityCount() = 0)
delay 0.5
end repeat
I don’t understand, are any of the two last examples you @Fredrik71 and you @KniazidisR posted supposed to work? I still only get 0 as the result.
Thank you both.
My script contains a repeat loop that exits when a condition is met. This should stop the rest of the lines of code while Mail.app is doing something in the background rather than returning the background activity count. That is, most likely you are testing it, but do not understand that its result should be more execution time while Mail.app is doing something in the background. And nothing more.
The script is supposed to work.
Background activity count is used by users to solve the problem of synchronizing user script activities with Mail.app activities. That is, if you correctly insert my fragment into your problematic script and the problem disappears, then this will be an indicator that the solution works.
I understood what your script was doing, it just didn’t perform as I expected. Maybe the problem is a matter of definitions: what is a background activity?
I copied 100 mails from one IMAP account to another, and while this operation was going on, executed your script expecting it to continue until the copying was done but it finished immediately. Is that result expected? What operation should I try to trigger a background activity that makes your script loop?
Thank you.
I am not the developer of Mail.app to give you the exact definition of a background activity in this particular app. Looking through Mail.app’s Preferences, I see a lot of settings to automatically run (shedule) tasks at regular intervals. I think background activity is any activity associated with these settings.
How to test I have already said. Since you are interested in the background activity, you must have some kind of big script that goes wrong precisely because of the out of sync. You add my code to it and if everything is corrected, the test is passed.
Can you create/describe a test case where your script runs for s while?
My use case is that I want to copy 100 000+ mails between two IMAP-accounts. Drag-n-drop doesn’t work, the process is always interrupted somewhere in the middle and you end up with not knowing what has been copied.
I have therefore written a script that copy one message at the time and check that the process was successful before it copies the next message. Before the final check I want to make sure that there are no active background processes, that is, the message really has been physically transferred to the destination account and there is no uploading or syncing still going on.
Yes, and it has a similar problem as with drag-n-drop, some message is corrupt or something and the import stops in the middle, without indicating where the problem is.
.
Hello, again.
The background activity count is broken, but you don’t need it to check that the copy process was successful. Every message has persistent Message ID, so you can check using it:
.
tell application "Mail"
repeat with aMessage in (get messages of mailbox "Drafts" of account "iCloud")
duplicate aMessage to mailbox "Drafts" of account "Gmail"
set iCloudAccount_MessageID to message id of aMessage
repeat until (message id of messages of mailbox "Drafts" of account "Gmail") contains iCloudAccount_MessageID
delay 0.2
end repeat
end repeat
end tell
Are you sure your solution take synching into account? When you copy a message between two local copies of IMAP-mailboxes, the copy is more or less instantaneous, but then the operation must also be synched to the remote mailbox, which takes more time and could fail.
I think, the problem is that the duplicate command doesn’t output the result to the script and the repeat loop continues right away. If there are many messages, a bunch of Duplicate events are sent at the same time, which should lead to an overflow of the event queue.
It is better to experience in action. I don’t keep more than 100 messages to check.This solution might be slow, but should work. Another faster solution would be to copy in batches, 1000 messages at a time, with hardcoded delay. For example, delay 10.
Has anyone tried the background activity count recently? Is it fixed in newer versions of MacOS?