Jaharmi’s Irreality renewable hyperlinks with 0% transfat since 1999

I am happy about a solution I just came up with to the problem of not being able to define an arbitrary set of dates as the recurrence pattern for an event in Microsoft Entourage 2008.

I wanted to enter an event that was split across two days, and wouldn’t have obviously fit any type of “every Wednesday” or “every second Thursday” pattern. The ideal way to handle this, I think, was available in the Steltor CorporateTime calendar I used to use: create an event and add arbitrary dates to it, so that each recurrence appeared as part of the series. You can’t do that in Entourage — or I’ve never found any trickery to allow it.

Luckily, however, the event’s start time and duration was the same on each of the two days, so I realized I didn’t need to make two different events for it. And, I only had two recurrences to deal with — if there’d been more, it’s unlikely they would have been evenly spaced.

I used my “Compare dates” AppleScript to determine how many days apart the two instances of this particular event were. I came up with 20. I entered that as the number of days between recurrences. I set the recurrence to end on the date after the last event.

The result? I got two events (and two events only), both on the days I intended, and they were linked as part of a recurrence pattern. Sweet. It’s the little victories, you know?

According to the AppleScript Overview which was freshly revised for Leopard, the AppleScript Utility is scriptable and now lets you enable GUI Scripting. I think this means — although I haven’t confirmed it personally yet — that this is the first scriptable way to enable GUI Scripting.

I’ve spent a small amount of time trying to enable it other ways in the past — including the use of the `defaults` tool — and been stymied. I’m not sure when the last time I tried was, or which version of Mac OS X. Nonetheless, a scriptable way to enable GUI Scripting is welcome.

Despite my concerns that GUI Scripting could be a source of security problems — from the perspective of a social engineering attack — there are already many other potential ways to script or automate applications for social engineering mischief. On the plus side, systems administrators and others who need GUI Scripting on or off, even for just a short time, should have an easier time enabling or disabling it on computers thanks to this change.

Hm. They actually tell you what’s new in Leopard — from a Mac OS X developer perspective, anyway — in the release notes section of the ADC Reference Library.

Who would have guessed? I think I missed this for Tiger. And, AFAIK, it wasn’t available at all for any previous version of Mac OS X. ’Twas a shame, quite a shame.

(I’ve always missed John Montbriand’s old overviews of the Mac OS classic releases; they were a treasure trove, relatively speaking, of information. Even for sys admins.)

It struck me today that when running Entourage, I have two script menus. One is specific to Entourage, the other is for the optional — but handy — system-wide Script menu. Yet both have the same icon — the stylized black and white paper-rolled-into-an-S icon — in my menu bar.

The app-specific script menu was probably more common in classic Mac OS days than it is under Mac OS X. (But yet, as I type this, I noticed that MarsEdit has its own script menu, too. I think that just shows how wired into classic’s scripting Brent Simmons was — I mean, he worked on UserLand Frontier, the original scripting environment for the Mac.)

Ah, I just wish the two menus could be one and the same. If Entourage (or any other application) detected that you had the system’s Script menu enabled, it ought to just turn its own off in favor of the system menu. Or maybe the system-wide menu could show the app-specific scripts first, so that they are always in a known location (top of list, right side of menu bar), and take over the function of the application’s scripting menu. Or, they could just have two different icons, or one could be an icon while the other was text, or whatever.

In reviewing Jesper’s list of requirements for The Email Client That Doesn’t Suck, I was somewhat surprised how many of his points are already handled by Microsoft Entourage 2004.

I’d give it 19 out of 26 points. There are some places where I’m being charitable towards Entourage, partly because it can support the requirement with a little work (which does not always mean scripting — and it should be noted that Entourage is very scriptable) or I didn’t understand what Jesper meant by the requirement.

Many Mac users discount Entourage. There are a couple of reasons that may be cited:

• Microsoft bundles it with Office 2004, so you have to buy it along with a lot of other software in order to get it. That costs more than a standalone client, even if you’re eligible for the $149 Student and Teacher Edition (which is often discounted even more).
• It’s not Universal yet, so it works natively only on PowerPC Macs. It requires Rosetta on Intel Macs today. (But Microsoft has announced that the next version of Office will be Universal.)
• It comes from Microsoft, so it must be evil somehow.
• It has a custom monolithic database for its backend. This predates any of Apple’s Core Data-type development. It can be a completely valid issue for some — such as those with network or portable home directories, or those performing regular client backups.
• It doesn’t look like a Mac OS X application. Rather, you might say it looks more like an application from classic Mac OS … and I’d agree, but there are some quick things you can do to spruce things up. (I had some on my old blog, but I still haven’t ported the old content over. Suffice it to say that changing a lot of the font choices to “Lucida Grande” in the preferences makes a big difference.)

That said, there are many valid concerns about Entourage. I voice many through the Microsoft feedback channels available to me.

However, I think there is a huge impediment to creating a new e-mail client today, simply because of how connected this kind of product is to your whole computing experience. Any developer should take that into consideration, and realize that it’s probably an unending effort.

I just upgraded Salling Clicker from version 3 to 3.5, and promptly discovered that it no longer lets me control Keynote 2. Only when I tried to using the Clicker application on my Palm Treo 650 to control Keynote did I get a message that Keynote 3.0.2 or later was required.

Needless to say, I have not yet upgraded to Keynote 3. It has been out more than a year, and the rumors peg an update that was aligned with Leopard. Apple offers no upgrade price break; you’re always buying a full copy. It makes little sense to update to the newer version of it in iWork ‘06 now, unless I really want a universal version or compatibility with this new Clicker.

Compatibility that I had, mind you, yesterday on the old version. Sigh. If they’d just put this in the system requirements on the Clicker Web site, I wouldn’t have upgraded.

Update: Salling swiftly responded to my tech support request and suggested using the script for the older Keynote 2 that is now posted.