After a ton of testing and waves of frustration, I think this is finally ready to test again.

UIcheck() System Events Test Script 2 (UIcheck-100605-1525.zip, 10k)

Again, please run this and let me know what your results are, including OS version and a vague hardware description.

A few observations:

The script is much larger, but the re-useable parts are fairly self-contained. Most of the size comes from error logging and timing functions. Please feel free to pilfer whatever you want from this example.

One of the biggest problems noted by the previous test script was -609 “Connection is invalid” errors. Thanks to a great post and followup by Bill Cheeseman on the CocoaBuilder site, I figured out why those were happening.

Essentially, AppleScript was sending commands to an application which wasn’t ready yet or that was shutting down. For whatever reason, AppleScript doesn’t necessarily clear the reference to an application that’s been sent a quit command. It’s possible, and quite likely that sending a command to an application immediately following a quit command won’t restart the application, it will cause a -619 connection error since AppleScript will try to send the command to the vanishing application.

Additional testing proved that hypothesis. Several other applications all threw -619 errors when cycled too quickly. So these errors weren’t the issue. There were still occasional “-50 Parameter error” errors, which seem to occur randomly whenever sending a command to System Events. These appear to be the most traceable problem I’ve found.

That noted, System Events seems incredibly slow to quit. On 10.3.9 it requies two tries almost every time. After testing some delay statements to pause the script, I ended up looping around a try statement which quits and re-launches the application. If the application responds correctly, the try doesn’t fail and the repeat is exited.

Hopefully this will continue to work. In testing I found the scripts seems sensative to humidity, mean looks, cute girls and smelly lunches. They’d work one day and fail inexplicably the next. This iteration however, seems to be working.

The next step is to build in an error-catching loop into the iPhoto date setting routines to make sure the script doesn’t fail and skip over any photos.

Previous posting on this topic is here: AppleScript System Events Bug

Update Thanks to everyone who helped test this, I’ve rolled these functions into my iPhoto AppleScripts which should be more robust now.

Despite the number of people successfully using my iPhoto AppleScripts, I’ve had a troubling number of people report problems as well. These weren’t just little problems, the scripts completely failed to run.

I asked several of these people to run the scripts from Script Editor and send me the error message they got when the scripts failed. All but one of the problems happened during a call to the System Events background application. Most infuriating was the fact that I couldn’t reproduce the problem. Today I managed to recreate what I believe is the problem.

The script below is a test script which pounds on System Events then tries to detect and recover from System Events crashes.

UIcheck() System Events Test Script (UIcheck.zip, 4k)

Please download the script and post your results in the comments. I’m seeing a consistent 3-9% failure rate for System Events on my PowerBook.

This is public domain, use at your own risk, etc. Please post improvements if you have them.

Update: Please post your OS version alongside any results.

Update 2: More on the System Events AppleScript bugginess Including a new test script.

Joe’s iPhoto AppleScripts for Date Manipulation have been updated. I’ve been working on these for a while towards the goals of making Automator actions and a standalone Application, but some unknown incompatibility introduced by iPhoto 5.0.4 pushed this to the front burner.

Some areas of improvement:

• Better UI Date Entry – Dates entered directly in info pane, no more popping the Batch Change window
• Language Independence – All language specific UI calls removed, should work with any language or date format
• Date format sniffing – The date format is now discovered gracefully and checked for accuracy.
• Faster – Extensive refactoring and efficiency tuning, now I can really blame iPhoto for the slowdowns.
• Works with iPhoto 5.0.4 – I’ve been testing it all evening with absolutely no problems (I probably shouldn’t say that)

I still don’t know why the previous scripts stopped working with 5.0.4, but I was thankfully able to get these all working with the newest iPhoto in a few hours this morning. Good application design really does make a difference. I know I’m still not working in true OOP, but breaking the code down into simple, self-contained chunks really makes maintenance simpler. The return curve (that agonizing time spent staring one’s own code and having no idea how it works) is much shorter when each component is named descriptively, has a concise, easy to grasp function and doesn’t draw from anything but it’s explicity input parameters.

Idea for next time: If these scripts obliterated the existing clipboard, would that be a dealbreaker? Or just an annoyance? What if they ran a lot faster?