Re: calendar selection

I found this solution posted by johnedayhttp://www.johneday.com/1086/reference- … pplescriptwhere the author 1. detected the event identification contained in com.apple.ical SelectedEvents 2. SQL'ed calendar and event id's3. to reference Application "Calendar"'s calendar id's event id4. and then to sqlite3 the ~/Library/Calendars/Calendar Cache database4. After the Calendar Cache database's calendar and event id are identified, Calendar's event's properties and contents could be processed

Applescript:

-------------------------------- ABOUT--------------------------------http://www.johneday.com/1086/reference-selected-calendar-events-applescript-- Written and tested in Yosemite, Calendar Version 8.0-- The plist may take several seconds to update after a new event has been selected.-- Only the first instance of a recurring event will be referenced.

Re: calendar selection

Shane, It appears that in my attempt to find an ASobjC method, I have run afoul of some rule, of which I was not familiar. If an applescript runs a shell script calling sql on my calendar's database , from your perspective it would be illegitimate or hacking my own computer. I, however, do not clearly comprehend your analysis.

Are you saying that 1. the applescript sql method is illegitimate as it places my calendar library cache at risk for destruction or corruption?2. although I am accessing my own calendar's library information, it is illegal?3. something else altogether different?

If this data is on my computer, I do not understand where illegitimacy arises, in an attempt to extract it.If you might explain your thoughts further, I would greatly appreciate your insights.

Re: calendar selection

Calendar data is handled by the Core Data framework, which is also used by lots of other parts of the OS, as well as many apps. In turn, Core Data generally uses SQLite to serialize the actual data to disk.

You can't do any harm reading that data directly -- only if you write to it. However, there's no guarantee that the SQLite database won't change. It can change because Apple decides to modify the behavior of the relevant framework, but it can also change if they update the Core Data framework.

So it's not legitimate in the sense of being a back-door approach, and therefore potentially fragile. But that doesn't mean you can't use it.

That said, now that I look closely at the code, it's in two parts: reading the real ID (which is different from the iCal scripting ID) of the selected event via defaults, and then getting the iCal event ID and calendar ID via sqlite3. It seems to me that you can use defaults to get the real ID, and then use one of my calendar libs and a bit of ASObjC to get the iCal event ID and calendar ID -- no need for sqlite3.

So something like this:

Applescript:

use AppleScript version "2.4"-- Yosemite (10.10) or lateruse framework "Foundation"
use framework "EventKit"
use script"CalendarLib EC" version "1.1.1"
use scripting additions

Re: calendar selection

akim wrote:

What might some of the possible reasons for these differing results?

One's returning a string and the other an NSString. As you're passing the result to a method that ultimately requires an NSString, coercing the NSString to a string is just a waste of time. But you can do so if you want to compare them.

Applescript:

as you said returns a more standard string…"{ iCal = ( \"3207A4D8-FA77-4DAF-8E50-75810465D860\" );}"It does not return a missing value.

I understand your discussion of illegitimate access and that the underlying or Core Data framework might change without notice from Apple. In your opinion, should the ASObjC return a a missing value when the AS shell script returns a string?

I wish I knew the reason that might explain the lower case c ical NS script yielding an NS string,rather than returning an error. If you could explain, I would appreciate the education. In either regard, thanks for your great help.

Re: calendar selection

It seems that ical works to read the values, but that they're cached somewhere by the app, and presumably whatever process synchronizes the cache insists on iCal. So whatever you get the first time, you continue to get (until you reboot the script editor).