I’m trying to add new ical events via applescript, but I’m running into a problem with the URL property. The URL I am trying to enter contains spaces, and as such doesn’t make it into the calendar entry.
Here is the script I’m using:
tell application "iCal"
tell calendar "Recurring Charges"
set theDate to current date
set myURL to "timelog://start/?status=(null)&client=company name&creator=&category= &project= &"
make new event at end with properties {summary:"Backups: Admin", description:"Text description goes here", location:"", start date:theDate, allday event:false, end date:theDate + 135 * minutes, url:myURL}
end tell
end tell
I’ve narrowed it down to the spaces in the url that cause it to not be entered in the iCal event. I’m just not sure why. I can manually copy and paste that url directly into an iCal event with no problems. And, TimeLog (the program that generates that url, can enter it into an event directly without issue.
Any help would be appreciated!
Browser: Firefox 3.6.4
Operating System: Mac OS X (10.6)
If you have more than spaces to encode I suggest you google for and download Satimage.osax which is a Scripting Addition which contains the commands escapeURL and unescapeURL.
A scripting addition is not needed. Built-in Perl can do it with URI::Escape
set a to "timelog://start/?status=(null)&client=company name&creator=&category= &project= &"
set b to do shell script "perl -e 'use URI::Escape; print uri_escape(\"" & a & "\")';"
--> "timelog%3A%2F%2Fstart%2F%3Fstatus%3D(null)%26client%3Dcompany%20name%26creator%3D%26category%3D%20%26project%3D%20%26"
Then I guess there is an URI::UnEscape as well. Could you please show that one as well, as I wouldn’t for the bare life of me try to figure out the Perl incantation to do that. For completeness.
As you may have guessed I actually have Satimage.osax installed, and I think that this is the easiest way to accomplish url encoding/decoding. (It should be fast too, -but that wouldn’t matter much if there were only one url to encode/decode at a time.)
Off topic:
If there were problems with a Perl or Python or Satimage.osax installation on some clients machine,
I’d prefer having trouble with the Satimage.osax.
I haven’t tried it personally, but it’s apparently possible to include OSAXen in scripts saved as application bundles. This of course should be done with the blessing of the OSAXen authors.
@Stefan : I agree, there are still a lot of well established osax’s that aren’t ported to 64 bit. But in this special case what Satimage.osax concerns, it is ported to 64 bit - and the previous versions are still available. That’s the exception for my part. Having spoken about trouble with different solutions, I must be fair enough to say that it is much more likely to have trouble with an osax than with Perl, Python, Ruby, but when you first get troubles with one of these,
then we are talking about troubles of a different scale.
@Nigel: I believe the trick is that there should be a space in the spelling, like this: “Scripting Additions” when you are creating the ScriptingAdditons folder within the bundle. There is a very good post by Julio about this.
I will write a script that uses curl or something to download the Satimage.osax directly to the user, when I would need it for a script at least, ensuring the latest, - and correct version. With the trouble of eventually adjust the addresses manually now and then. I will have no trouble with the terms of Satimage. Thats a very small price to pay. Thanks for the link to their licensing terms; I hadn’t really read it.
there is a second more serious portability problem.
As Scripting Additions’ terminology is not protected by a tell block, there is always an insecurity to get a terminology clash with other reserved words or variable names.
That is an issue I haven’t given a thought. -And that is a serious one.
It is definitively a rather big issue. I haven’t experienced any any such problems recently.
As long as I have the Dictionary of Satimage.osax available, and aware of the situation, I think I’ll be able to live with that.
I’ll only use Scripting Additions which are ported to 64-bit, and from there onwards, I think it will take time before the platform changes again, but Operating System Upgrades might break things sooner or later. But that regards all solutions.
By the way I found this link to Matt Neuburgs book AppleScript the definitive guide where Terminology clashes are explained: here.
I actually have Satimage.osax installed, and I think that this is the easiest way to accomplish url encoding/decoding. (It should be fast too, -but that wouldn’t matter much if there were only one url to encode/decode at a time.)