iCal alarm to trigger Filemaker script

[wrapsterman]

When an iCal alarm goes off, I'd like it to run an Applescript that will go to an open Filemaker file and perform a (find) script using a parameter of the iCal event (event name). What would the Applescript language look like and how do I capture the script parameter from the alarm?

Thanks in advance.

[Søren Dyhr]

I could tinker with this, but it will take a while, but do you know how to get the properties out of the trigging event? ... then would I without much effort be able to change/use that into applescripted searches in a filemaker base.

--sd

[wrapsterman]

Hej Denmark!

I know that with an iCal alarm I can set it to execute a script. My iCal calendar uses an Account ID as the event name. I assume that I can use a "set" command to set the script parameter to the iCal event name in Applescript. Then I would carry that parameter over to my Filemaker find. I'm probably not answering your question but I'm no expert on Applescript. Thanks.

[comment]

AFAIK, you cannot pass a script parameter when calling a Filemaker script from Applescript. Instead, you could set a global field to the "parameter" value and make your (Filemaker) script use that.

[Søren Dyhr]

For once Michael do I think you make it too difficult, iCal has some properties which then could be stored in a AS variable, this variable is then unloaded in applescript produced requests.

Now ...an interesting crincle to the whole matter is that both iCal and Addressbook are interfaces to:

http://www.sqlite.org/ ...databases, and I seems to recall that Edoshin tinkered with ESS'ing, probably simply by utilizing this:

http://www.actualtechnologies.com/product_opensourcedatabases.php

Anyways I'll need to investigate how to grap these events properties from iCal in applescript. This is going to require some spit and polish to accomplish - but yes I would guess it's posible.

--sd

[comment]

Sure - you already mentioned this in your first reply and I didn't think it was necessary to repeat it. But I am perfectly willing to amend my answer thus:

... Instead, you could set a global field to the "parameter" value and make your (Filemaker) script use that, or just do the find using Applescript alone - whatever you find simpler.

[Søren Dyhr]

Letting an applescript call a native filemaker script isn't simpler - or when is it, a pretty fair share of the actions are overlapping?

Well I think I would embed a variation over following in the file:

current date

set bVar to date string of result

tell application "iCal"

	repeat with thisEvent in every event in calendar 6

		start date of thisEvent

		set aVar to date string of result

		if aVar = bVar then

			set cVar to summary of thisEvent as text

			exit repeat

		end if

	end repeat

end tell

create new request

set cell 1 of request 1 to cVar

find

The script is then setup as the init script for the filemaker file, and the document iCal opens is this file. Now it can really make sense to make a new calendar for this specific purpose... this is why i reference "Calendar 6"  which means the number of calendar in the creation order, so if you presently have 2 then create a new and it gets the number 3.



The reason for this move is that traversing iCal with applescript could be a little tiresome to wait for. Similar do I set the request to "cell 1" simply because it's the first filemaker field in the creation order.



The applescript only gets the first hit in "today" so the rest is ignored ... and again is the creation order important since new records in iCal can be created randomly. Say the purpose is to make a found set of contacts names found on the very day which needs some looking after, must the AS be changed accordingly.



I have now pointed out some of the crincles which need to be observed when attempting this approach ... which means that before the task at hand gets a bit closer to the genuine context and purpose.



I enclose my file and you need to change the embedded AS to the number of calendars you actually have for the testing purpose. 



------------------------------------------------



Update just after the iCal clause put in this:

delete every request

...just a tiny error otherwise would native and AS made request mix and give some unexpected results.

--sd

mySolution.zip

Edited July 23, 2009 by Guest

[comment]

Letting an applescript call a native filemaker script isn't simpler - or when is it

It is simpler when the Applescript is only a trigger for Filemaker to take some action, and you want to keep all of the action's logic in one place.

In the same vein, the original question was:

When an iCal alarm goes off, I'd like it to run an Applescript that will go to an open Filemaker file and perform a (find) script

I don't see how putting the Applescript inside the Filemaker file will be useful here.

[Søren Dyhr]

I don't see how putting the Applescript inside the Filemaker file will be useful here.

Do you mean, what happens when the file already is open? I can only say my approach seek to prevent having several files floating around, could it be contained in one single using:

Fileoptions>open/close>the embedded AS

...was there any talk about the solution deployed in a networked solution? In that case would the Opener file be the one referenced from iCal, as long as the init script in the hosted file is called, would it find the person who was mentioned in iCal.

--sd

[comment]

The file is already open, according to the OP. Not that it matters much, either way. I believe the question has been answered.

[wrapsterman]

You guys are giving me some good homework, but unfortunately I'm a bit lost.

To be sure I've made my problem clear, I currently create alarms in iCal with Filemaker setting the event name to "AccountID". When an alarm goes off (at a specific time), I go back to Filemaker and perform a find on one or more accounts for which an alarm has triggered. I'd like Filemaker to perform the finds for me if the Filemaker file is open.

Am I correct that your solution, Søren, is a startup script ("init script") that you run each day when you open the file and that it only searches by date, not time? Can you please dumb down just a bit in your explanation of the implementation of the code, where it goes, etc?

I plugged the code into the Applescript editor and got errors when I tried to compile it. Does that matter? Thanks.

[Søren Dyhr]

Ah ok, then is not of much use - then must the document iCal opens be a compiled app build upon this applescript:

current date

set bVar to date string of result

tell application "iCal"

    repeat with thisEvent in every event in calendar 6

        start date of thisEvent

        set aVar to date string of result

        if aVar = bVar then

            set cVar to summary of thisEvent as text

            exit repeat

        end if

    end repeat

end tell

tell application "Filemaker Pro" 

    go to layout 1

    delete every request

    create new request

    set cell 1 of request 1 to cVar

    find

end tell

Layout 1 is obviousy not strict enough, use the unique name of the layout, so the actions happens with the correct focus.

--sd

[comment]

Perhaps it would be easier if you explained the purpose behind all this.

[wrapsterman]

Sure. We are a small business that frequently calls our customers. Sometimes we need to call them back at a specific time. Our database sets these events in iCal which is nice because even if Filemaker isn't up, iCal is. What I'm trying to do here is basically bring that alarm back into Filemaker, automatically pulling up the account when it needs to be called. Hope that helps.

I'm still experimenting with Soren's solution.

[comment]

Our database sets these events in iCal

If the events are already in the database, then why do you need to look for them? Wouldn't a simple "tap on the shoulder" from iCal be enough?

[Fenton]

I think I see the problem. iCal can trigger alarms. The alarm has an option to run an AppleScript. But the AppleScript which the alarm runs does not know which event triggered it. So it cannot get any data from that event to go look for in FileMaker.

An idea I had (at this late hour) is that if you had the event alarm run the script at the alarm time, then the event's date (actually a timestamp) would be a little less than the current time, likely the only event of that calendar near that time.

So, to get the summary of that event, the AppleScript could do something like:

set d_start to ((current date) - 60)

set d_end to (current date)





tell application "iCal"

	tell calendar "Home"

		set alarm_event to every event whose start date is greater than d_start and start date is less than d_end

		set sum_txt to summary of item 1 of alarm_event

	end tell

end tell

Edited July 24, 2009 by Guest

[comment]

the AppleScript which the alarm runs does not know which event triggered it. So it cannot get any data from that event to go look for in FileMaker.

I was under the impression that the Applescript already had the event info - it never occurred to me to check iCal itself to see what it can do.

Anyway, as I said earlier, if the events are also stored in the database then Filemaker can find them just as well - all it needs is a trigger to run a script that finds events around current time.

[Søren Dyhr]

An idea I had (at this late hour) is that if you had the event alarm run the script at the alarm time, then the event's date (actually a timestamp) would be a little less than the current time, likely the only event of that calendar near that time.

Your approach isn't particular far from mine, but yikes it takes time if the calendar holds a lot of alarms. This is why brought up the Sqllite ... since both calendar and addressbook are sort of runtimes build upon Sqllite, which have some Applescripted measures to traverse the base behind ... but it isn't a fast implementation.

http://www.entropy.ch/blog/Software/2008/02/09/Leopard-Reading-Out-Address-Book-Data-From-a-Widget.html

So ESS might even build a relation, so all it takes is a GTRR and the days alarms is used for filtering.

--sd

Edited July 24, 2009 by Guest

[pvanderh]

I think that it could be as simple as setting up a applescript to open that file. save that script as a app and then tell ical alarm to "open file" and choose that script/app. in the past i have not had luck getting ical to open scripts so that is why i say to save it as a app out of applescript. be sure to check run only and uncheck startup screen.

this is what the applescript might look like...

[color:red]tell application "Finder"

activate

end tell

tell application "Finder"

open "Macintosh HD:Users:Shared:open_test.rtf"

end tell

the open "Macintosh HD:Users:Shared:open_test.rtf" would need to be replaced by the path to the particular file that you want to open. the only problem with this would be that you would have to make a different script for each different file that you would want to open.

[Søren Dyhr]

Where does the parameter transfere take place in this suggestion? It's exactly as Fenton discripe it - you should have an idea which of the alarms that actually trigged the opening of the compiled applescript.

--sd