I have a script that I run as a background app. The script has very complex and deeply nested set of conditionals, so the only way to truly know that it always works is to perform regular test runs.
I’ve set traps of “display notification (the info)” each followed by “delay 3” so I’d have enough time to actually read what the steps have been and how the script is performing. In the end, the script displays a dialog containing an actual summary of the info that I really want to know.
If I run the script in Script Editor, the delay-chained notifications roll up nicely as I wait for the script to finish off the process with the dialog window.
However, when I run the script as an app from the menu, it seems to completely ignore the notification delays: It jumps straight into displaying the dialog window, and after I’ve clicked OK, it will retrospectively display just one notification, one that would appear to be the first notification to come up in the script.
So things are coming up in the wrong order and I completely miss about a dozen notifications from the middle.
Is there any way how I could have a background running script not speeding ahead of its time?
I just wanted to chime in that, yes, there’s a problem with “delay” in Applescript in Yosemite. My scripts were working when run from Applescript Editor too, but not from Script Debugger, so I reported it as a bug to Mark. Turns out it’s an Applescript bug with Yosemite that delays do not function correctly unless the script is being run from Script Editor. I haven’t found a work around other than upgrading the OS… although I didn’t spend a lot of time looking.
The release notes for Applescript on El Capitan noted that they’d fixed this:
Also not unimportant to mention is that It uses a lot of CPU. The sleep command itself will use no CPU at all but excessive execve() and invoking an new process will. It also loses accuracy (from 3.8 - 5.5 seconds over 10 runs).
You could also choose repeat 3 times with 1 second delay. You have the best of both worlds, the next incoming event will not be delayed more than 1 second (if 3 seconds is an problem at all).