Just installed Mac OS X 10.6.1 Snow Leopard and I have run some preliminary tests of iCal publishing to MobileMe and…

There was no mention of changes to iCal in the release notes. However, preliminary test with all-day events in a calendar (and it was these all day events that were preventing the calendars being viewed once published – post 1, post 2 and post 3), with iCal running in either 32 bit, or 64 bit mode, seem to work.

Fingers crossed that the problem has been fixed.

In a blog post yesterday I said I had a fix for the Mac OS X 10.6 (Snow Leopard), iCal and MobileMe problem…. Well, it looks like I spoke too soon….

Yesterday I received a solution for Mac OS X 10.6 (Snow Leopard), iCal and MobileMe Problem from Stuart (see earlier post) as a blog post comment.

I followed the advice, and tested it, and it all worked for me, and I was able to add back the all-day events to my calendar and it could be viewed on the web. This morning I went to check that the calendar was still accessible and the ‘error’ was being returned. I removed the all-day events and the problem was solved….

So, bottom line. Still don’t have a fix!

UPDATE – within 10 minutes of posting this the original blog post on a possible fix received an email from Bob saying that the fix works for him.

Just received a solution for Mac OS X 10.6 (Snow Leopard), iCal and MobileMe Problem from Stuart (see earlier post).

THIS DOES NOT SEEM TO WORK IN ALL CASES

If you run iCal in 32 bit mode then it is possible to have all day events in iCal. To get it to run in 32 bit, quit iCal (if running), find it in the Applications folder, cmd-I to open information and click on ‘Open in 32-bit mode’. Restart iCal, and if it contains all-day events it should now publish OK.

The iCal information window

THIS DOES NOT SEEM TO WORK IN ALL CASES – see this post

Some more information on the iCal, MobileMe, and Mac OS X 10.6 (Snow Leopard) problem.

Picked up this information on a 10.6 discussion at Apple. Followed the message and I can confirm that it is all day events that cause the problem. I published a calendar with one event, worked fine. Added an all-day event (no start and no stop time), wouldn’t work. Removed the all-day event, problem solved….

In an earlier post I wrote about how iCal, MobileMe, and Mac OS X 10.6 (Snow Leopard) were not playing very well together….

Today I received an email from Apple in which they thanked me for the small dummy iCal file I had sent that had the problem. Interestingly I received a ‘fixed’ file back from them which worked, i.e. I could publish to MobileMe and see it when accessed using Safari, but unfortunately all appointments (except repeating events for some reason) were off by 7 hours!

Hopefully a fix will be out for this soon….

For me this problem is a ‘show-stopper’ for which I need to find a fix – urgently. I know everything with iCal and MobileMe was working before the upgrade to Mac OS X 10.6 (Snow Leopard), but now it isn’t.

I have reported the problem to Apple, and hopefully they will get a fix out soon.

The problem is highly reproducible…

I have a rather complicated calendar that I publish via MobileMe with no ‘titles’, so people can see when I am free, but not what I am doing. Under 10.6 the publication goes OK, and the file can be downloaded from MobileMe and re-imported in to iCal with no problems. The calendar is also visible when logged in to the MobileMe site. However, if the calendar is accessed via a http://ical.me.com/username/calname type link the page will not display and will report an error – see http://www.me.com/not_found/. If the webcal://ical.me.com/username/calname type link is used the file will download and display in iCal with no problems. The file will also display OK in Google Calendar.

To explore this further I created a much smaller iCal file that only contained a couple of weeks of appointments, and some repeating events. Again the file appeared to publish OK under 10.6, but it still gave an error if accessed by the http://ical.me.com/username/calname type link. The file could be downloaded and would import OK in to iCal.

Interestingly, when I imported the file in to iCal running under 10.5.8 it loaded OK, and when published to MobileMe the file could be accessed via a http://ical.me.com/username/calname style link with no errors. All very odd.

The fact that an iCal file can be created so easily, and can be published, and work with 10.5.8, but not with 10.6 suggests it is a 10.6 problem.

One final thought. There is an outside chance that the problem is with MobileMe and not 10.6, or just my MobileMe account….

Apple have said they will call me back on Monday. I have sent them the new ‘mini’ file, so hopefully they will be able to get to the bottom of this quickly.

Watch this space…..

Update: Tuesday September 1, 2009 – The problem is caused by ‘all-day’ events. Move all the ‘all-day’ events from the calendar you are trying to publish to a new calendar, and then republish the old calendar. This should fix things until Apple comes up with a solution.

Update: Friday September 4, 2009 – Comment below seems to solve the problem – run iCal in 32 bit mode (see this post for more details)

Update: Saturday September 5, 2009 – The solution to the problem I posted yesterday does not work, all the time. Turning on 32 bit mode appears to allow the calendard to be accessed in some situations and not others. (More details)

Over the past year work has continued on iCalMaker.

iCalMaker2 was successfully moved over to xcode3 and work has progressed really well. However, it has now stopped again. Three reasons for this:

1. Too much work on from other sources.
2. No real advance on iCalMaker in terms of interaction with iCal (real reason for the re-write).
3. Work in iPhone and iPod Touch applications.

The biggest problem with iCalMaker has been the fact that Mac OS X 10.5 (Leopard) ‘broke’ the integration between iCalMaker and iCal (see earlier post for details). I think all possibilities of resolving the integration problem have now been explored, and it just can’t be done. So, the decision was made that as iCalMaker2 did not really do anything different (other than the document option) from iCalMaker that iCalMaker2 would not be released (in the foreseeable future). However, watch this space… it may happen.

As I said in an earlier post the new version of iCalMaker (iCalMaker2) will be able to import date and time data, from tab or comma-delimited files, using custom date and time formats. This will also be applicable to exported data…

In iCalMaker version 1.0 to 1.9, the format of dates and time that could be recognised/used by iCalMaker was limited to the pre-set style in System Preferences.

In iCalMaker2 there is a choice, you can either use the values set in the System Preferences, or some values as set by you, the user, in the iCalMaker2 prefrences.

The date/time format for importing and exporting data in iCalMaker2 can be set in the Preferences

Basically, once the “Use Own Time/Date settings” is clicked the different settings become available. For example, the date can be “Day Month Year”, “Month Day Year” etc. The month can be a number (1 – 12), or an abbreviated month (Jun for example), or the full month (June). A year can 2008, or 08. The time format is equally flexible, i.e. hour minutes and seconds, or just hours and minutes. 24 hour time, or 12 hour…

In both cases, time and date, the separator can be set to one of the available presets (e.g. :, /, – etc.), or one of the users decides (other).

Finally, the order of date and time can be set. Time and date, or date and time.

Now, the question is: should an advanced setting be added where the user can set up their unique time/date format? Should it be made possible to save previously used formats?

Anyway, back to dealing with the mapping of recurring events to the data-model and the program interface… what fun.

In Mac OS X 10.5 (Leopard) (Amazon Link) icons are bigger and bolder, and there is ‘Cover Flow’ in the Finder for navigating through files

‘Cover Flow’ looks like this…

Cover Flow in Mac OS X 10.5 (Leopard) (Amazon Link)

A great way to look for files and navigate a hard-disk. However, the iCalMaker icon didn’t look too good…

The old iCalMaker icon in Cover Flow

So, a new one had to be produced…

The new iCalMaker2 icon in Cover Flow

As can be seen, the new icon looks a lot better. This is mainly because it is bigger!!! 512 x 512 pixels, as opposed to the old icon which was ‘only’ 128 x 128…..

With the data model of the iCalendar data standard (rfc2445) complete the next thing to do was move the old code from iCalMaker over to the new iCalMaker2.

Code in iCalMaker can be divided two main groups:

1. Code that ‘talks’ to the interface, i.e. what the user sees…
2. Code that does the ‘grunt work’, i.e. the code that processes the iCal data from ical files, comma/tab delimited files, does all the exporting etc….

The code in group 1 is not really needed any more as Xcode 3.0 uses ‘data-binding’ to link the data to the interface. This makes life a lot easier.

The code in group 2 is a different story. This code is the ‘guts’ of the program. It does all the work. Most of it can be moved over with very little change, just the odd ‘tweak’ here and there to tie the data generated by the code, to the data-model, and hence to the interface. This is fiddly, but can be done.

The first sections of code to be moved over were the methods for parsing the iCal files. This needed a re-write of some sections so the data could map to core-data model. This has been done, and had been successfully tested. In addition, new code has been written directly read from iCal. More on that later….