Authors CurseForge

GroupCalendar 4.0 is out and is not compatible with FuBar_GroupCalendar. A whole lot of function names have been changed (tweaked really).

post a diff then?

Replace the current (non-working) AddOns/FuBar_GroupCalendarFu/GroupCalendarFu.lua file with the attached GroupCalendarFu.lua file. This should get any GroupCalendar v4.0 users back in business.

is there a way to get it to NOT show the description of the event? just the name and date/time

My guild just switched to Group Calendar 4 the other day (using 4.0.3, which is the newest); I deleted both my old Group Calendar and FuBar_GroupCalendarFu folders before replacing each of them, and I now get the following error everytime I mouse over the FuBar_GroupCalendarFu icon:
...ace\AddOns\FuBar_GroupCalendarFu\GroupCalendarFu.lua:289:attempt to call field 'GetLocalDateTimeFromServerDateTime' (a nil value)

This is using GroupCalendarFu revision 73654.

Did something change from Group Calendar 4.0.2 to 4.0.3 to break it?

That did it; should have thought of trying it.
I guess some leftover variables from 3.0 must have been mucking it up?

Thanks. :)

AHA!

The problem has returned, and I have pinpointed the culprit -- though not the solution.

I play on CST server, though I reside in EST. If I leave "Use server dates and times" checked, then it works fine, but as soon as I uncheck that option to prevent my own confusion, that's when I start getting the tooltip error I described above. Rechecking the option makes it go away again.

Any thoughts?

Made the following change to my copy -- not sure if it's 'proper' or not, but it works. :P

Line 289: eventDate, eventTime = MCDateLib:GetLocalDateTimeFromServerDateTime(event.mDate, event.mTime)

Shouldn't cause any issues, should it? Hopefully that helps anyone else with the same problem.

Ifnohk, thanks for that correction. I actually made a few mistakes in the file that I provided before. However, I think the bug that you identified and corrected is the only major one. The others are a result of my confusion over when to use . vs : when calling methods. I got lucky and the incorrect calling convention doesn't effect the behavior in most of the cases.