Calendar "open file alert"


(Jean Christophe Helary) #1

Update: I have written an article on using AS to automate the creation of launchd agents so as to emulate Calendar’s “open file alert”. Thank you all for your replies and insights.


When I create an “open file alert” in an event, Script Debugger does not give me anything as the file path even though the file eventually gets opened when the set time has come…

Is that a Calendar bug ?


(Mark Alldritt) #2

I’m not sure I understand the question. When you create an Open File alert in Calendar, you specify the file to open. Calendar opens that particular file at the appropriate time. There is no path to pass.


(Jean Christophe Helary) #3

The dictionary says that for an “open file alert” there are 3 properties: filepath, trigger date and trigger interval. So I’m expecting to see a “filepath” in the Explorer after I select the file.


(Jean Christophe Helary) #4

The idea being that I would like to use applescript to create such objects and when I specify a filepath property Calendar ignores it and does not open the file (that obviously has not been set) at the trigger date (that has been accepted). So my idea was to explore how would a working “open file alert” look like in SD and I was surprised to not see anything for “filepath”.


(Jean Christophe Helary) #5

Here is what I get when I call my code after launching Calendar from Terminal:

2017-12-02 11:12:59.568 Calendar[6259:166435] .sdef warning for a to-many relationship of class ‘calendar’ in suite ‘iCal’: ‘todo’ is not a valid class name.

I have no idea what that means, but it looks like a problem.

My code is here:
https://apple-dev.groups.io/g/applescript/message/143


(Shane Stanley) #6

When you see something like this, the first step you should try is to do the same thing by script. For example, I made such an event and ran:

tell application id "com.apple.iCal" -- Calendar
	tell its calendar "Test"
		tell its event -1
			properties of open file alarm 1
		end tell
	end tell
end tell

And the value returned for filepath is an empty string, even though I set a file. That tells you it’s a bug in Calendar.app — Script Debugger is just reporting what Calendar.app tells it.

(I wouldn’t be surprised if this was done deliberately as a security measure, but that’s pure speculation. I think it used to work.)


(Jean Christophe Helary) #7

Thank you for the method.

Now did you set a file by creating the event manually or with AS ?
Because when I try with AS, I can’t get to set the filepath property…


(Shane Stanley) #8

It’s never going to work from AS. Calendar.app is sandboxed, and sandboxed apps can’t use raw paths regardless of where they come from — they can only deal with file objects (and specifically security-scoped NSURLs, something AppleScript provides when you pass a file or alias to an app).

The property was implemented in the days before sandboxing, and it’s never been updated.

I just had a look in EKAlarm.h, which is the header for this in the EventKit framework. Under the url property, it says:

Note: Starting with OS X 10.9, it is not possible to create new procedure alarms or view URLs for existing procedure alarms.

That suggests it’s not even worth logging a bug on the issue.

Also, if you’re doing much Calendar scripting, might I suggest you look into CalendarLib or CalendarLib EC here:

https://www.macosxautomation.com/applescript/apps/Script_Libs.html#CalendarLib


(Jean Christophe Helary) #9

I’m not doing “much” Calendar scripting. I’m just refining that old script that I’ve used for years, but I’ll certainly check your library. Thank you.


(Jim Underwood) #10

Jean Christophe, I’m not sure I understand your specific use case, but if you’re still looking for a good/better solution, then you might consider Keyboard Maestro.

KM would allow you to create a macro, which can run a script (and much more), that is triggered by any/all of the following:

The same macro could also be triggered by a hot key, by name, or any of the Macro Triggers.

As you can image, this gives you a lot of flexibility. For example, the same script/macro could be triggered by date/time, while also being triggered on-demand.

The Macro Group of the macro can be constrained to be active only for certain apps, or to exclude certain app. I really like the Trigger by Name, since this allow me to easily search for and trigger a macro without having to allocate a scarce resource like global hotkeys.

If you have any questions about KM, you can ask here, or, even better, post your question in the KM Forum. You can test drive a full-featured trial version of KM for 30 days at no cost or obligation.


(Jean Christophe Helary) #11

Thank you @JMichaelTX! I’m actually checking scripting launchd to get that done from my original script. I’m writing a blog article about that right now. I’ll link to it here when I’m done :slight_smile:


(Jim Underwood) #12

@suzume, I just read you blog about using launchd. While that is a good tool to have, I must say it is much, much more complex that using Keyboard Maestro to accomplish the same thing.

Please see my above post for details.


(Jean Christophe Helary) #13

Well, yes and no.

No, because the finality of the code is not to run on its own but to be included in a script I run to create my jobs in the first place. For ex, the Label is automatically taken from my job name, the command is a constant in my case (the invoicing script) and the date also is automatically fed from the job deadline. So basically adding this code to the end of my job script does everything I need without requiring any effort on my part.

And Yes, because indeed, there are other ways to accomplish the same result with third parties.

But the point of most of my posts there is to show what can be done without third parties. Using what Apple provides out of the box and taking the most of it up to the limit of what’s possible (ie creating a complex native application). Also, as you may have noticed from the blog, I am a huge proponent of FOSS tools. I am a professional translator and I raise my 3 kids because FOSS tools allowed me to work on Mac. So there are places where I’m willing to go because I am professionally required to go there (sometimes run Windows software in VirtualBox, or work with Illustrator) but I try to avoid those places when I can (not saying that KM is philosophically equivalent to Windows XP or AI, but you get the idea :slight_smile: ).


(Jean Christophe Helary) #14

Also, I think it is important for users to understand how their machine works, so if this post manages to bring launchd closer to some people, I’ll be happy too.


(Jean Christophe Helary) #15

Last reply, I promise :slight_smile:
The thing is I found lots of articles and tutorials on launchd, and a lots of tutorials on creating plists in AS, but I could not find one that was putting the two subjects together in the same article. It’s done now :slight_smile:


(Jim Underwood) #16

That is great if that is what you like to do. For my entire career that has led me to do software development on a wide variety of computers, from main frames, to minicomputers to windows to Mac, I have always preferred to start my development as high up the food chain as possible.

I would rather spend my time on solving the task at hand rather than developing tools needed to do the task, especially when someone else has already developed the tools. So I have employed software libraries and third-party add-ons throughout the years.

Thankfully, there are those that enjoy tool development. I greatly applaud them! And I love to use them!

In this case, I have found that AppleScript and Keyboard Maestro make great partners. It is easy to combine one or more AppleScripts in one KM Macro to accomplish a given task. KM makes it easy to do things that either could not be done in AppleScript, or would be laborious to do so. And the reverse is true as well. I cannot create an app that I can distribute using KM, but obviously I can do that with AppleScript. So, for me, it is a matter of choosing the right tool for the job, where “right” often means (to me) the easiest/fastest way to develop the automation.

As always, it is great to have options so that each of us can choose the method that works best for us. Thanks for sharing your solution.


(Jean Christophe Helary) #17

I wish I had the skills to create “real” applications :slight_smile: I love programming but I only have so much time to learn (I’m at last getting “Learn Applescript” from Apress next monday…)