These are the docs for our FM10/11 version of the Pro Calendar. Docs for the newer, FM12 version of our calendar can be found here.
What's wrong?
If you can't see any events in the calendar after your integration, here are a couple things to check.
Note that Event Colors have their own trouble shooting section here.
1. Run the "Upon Opening" script again.
2. Click on the filters tab: if "Clear" is showing up in red, click "clear" to empty the filters. You may have been "searching" for events that don't have any matches. If you have multiple sources, visit the sources tab and select them one at a time to see if one source is the problem.
3. Check out the Source No 1 layout in browse mode, reviewing every tab: are there any errors shown? Do the timestamp fields show the same date / time as the date / time fields? (If not, skip to no 6 below.)
4. Take a look at the calc fields in CalendarRows and make sure nothing has been commented out (commented calcs begin with /* and end with */). You may be able to just remove the comments from the calcs and they'll work. Check the auto enter calc definitions as well, such as those for DateRangeStartAutoGlob and DateRangeEndAutoGlob.
5. Check your system's date formats. If you're using a customized date format switch to one of the standard formats like United Kingdom and then close and re-open FileMaker. It is unusual, but stray characters in the date format can screw up the calendar. If switching formats repairs it, slowly add your customizations again checking that the calendar continues to recognize them.
6. Take a look at the date and time fields you're using in the timestamp fields you pasted into your events table: are these defined as date and time respectively, or are they text. (Text will not work.) Also, make sure these timestamp calcs reference the same date and time fields you've mapped to on your Source No X layout. So if you're using a field called "Start Date" on Source No 1, make sure the time stamp calc uses "Start Date" and not something else like "Order Date". (Later, you can make a different source for Order Date.) This is especially something to look at if you have
more than one source; if the sources are using different date and time fields they'll need different timestamp calcs.
7. If you're having display issues, make sure the calendar layouts only have a body part; there should be no header or footer parts on the 4 main calendar layouts.
8. Make sure you don't have any folders with the same names as your layouts: notably that you don't have a folder named "calendar".
My startup script keeps deleting and re-creating the calendar interface records, is this normal?
No. But it isn't lethal either. Here is how to fix it.
As you probably know, the calendar requires some dummy records in a table called CalendarRows. Our script " Load Calendar Settings - On Startup --- Edit Configuration Here ---" tries to make sure that users haven't deleted, duplicated, or created new records in this table.
I imagine the reason it is deleting and creating them each time you launch is that the script is no longer running from a layout were it can evaluate "CalendarRows::RowNumber". If you change the beginning of the script to go to a layout based on CalendarInterface (where our home layout is / used to be) the script should only reset the CalendarRows table if there is a problem.
Just don't go to one of the actual calendar layouts just to get to a layout based on CalendarInterface, since those layout are script triggered and could delay / loop your startup.
