|
From: Wesley M. <we...@we...> - 2005-11-11 07:11:38
|
Hi Jim,
Yeah, I was afraid I'd broken stuff. Placing a .ics at the end seems
like the correct approach, since the "// Process files." block
expects the files to be the full path to a real file. I don't think
it's a kludge, since under normal operation, that's how a calendar
name would be mapped onto a file, right?
I think then this needs to be combined with a modification to line 70:
// Build the list of files we need to check.
if ($find_all || $recursive_path == 'yes' || $support_ical == 'yes') {
// Open the directory.
This will force it to check other .ics files, such as
corestorage.ics, in the $search_path for the name pulled out of
Info.plist, if $support_ical == 'yes' but you still specify the
calendar name in the request. I imagine that if $recursive_path ==
'no', at this point you would use $cpath to identify the directory
containing your iCal directory with the corestorage.ics and
Info.plist contents.
This seems to work for me in my very brief test. Without your change,
and the change to line 70, selecting a specific calendar doesn't work
unless $recursive_path == 'yes'. What do you think?
Later,
Wes
On Nov 10, 2005, at 10:47 PM, Jim Hu wrote:
> I've seen a problem where calendars aren't showing up when a
> specific calendar is selected, as opposed to
> all_calendars_combined...this is using what's in the CVS and not
> using recursive searching.
> As far as I can tell, availableCalendars() never pushes the
> calendar onto the cal_filelist array. I patched my install by
> forcing a .ics extension onto $filename.
>
> } else {
> foreach ($cal_filename_local as $filename) {
> array_push($files, "$search_path/$filename".'.ics');
> }
> }
> ...but that seems very much like a kludge. Any thoughts?
>
> =====================================
> Jim Hu
--
Wesley Miaw
we...@we...
|