DayBackForFileMaker

Troubleshooting

DayBackForFileMaker.Troubleshooting History

Show minor edits - Show changes to output

May 19, 2023, at 04:47 PM by 192.88.134.15 -
Changed lines 11-12 from:
%center% %newwin width=440px% [[https://www.seedcode.com/rootimages/stikipad/dayback/urlerror1-2.png | https://www.seedcode.com/rootimages/stikipad/dayback/urlerror1-2.png]]
to:
%center% %newwin width=440px% [[https://archive.seedcode.com/rootimages/stikipad/dayback/urlerror1-2.png | https://archive.seedcode.com/rootimages/stikipad/dayback/urlerror1-2.png]]
Changed line 163 from:
%center% %newwin width=440px% [[https://www.seedcode.com/rootimages/stikipad/dayback/launch-ie.png | https://www.seedcode.com/rootimages/stikipad/dayback/launch-ie.png]]
to:
%center% %newwin width=440px% [[https://archive.seedcode.com/rootimages/stikipad/dayback/launch-ie.png | https://archive.seedcode.com/rootimages/stikipad/dayback/launch-ie.png]]
March 02, 2021, at 03:17 PM by KC Embrey - Added FileMaker 19 section
March 02, 2021, at 03:16 PM by KC Embrey - Added FileMaker 19 section
Added lines 1-6:
!! FileMaker 19: Changes Required

Claris changed some things in FileMaker 19 that introduced some new issues with DayBack Classic. If you'd like to use your DayBack Classic calendar in FileMaker 19, you'll need to be running build 10.61 or later.

Instructions on getting your calendar updated here: [[InAppUpdates | In App Updates]]

May 14, 2020, at 02:59 PM by KC Embrey - Added additional cause to #BlankPopover
Added lines 61-62:

This can also happen if your computer goes to sleep or hibernate while the file is open. DayBack exports files to the FileMaker temporary directory that are used for the calendar, and the connection to the temporary directory is broken when the computer sleeps. To prevent this, you can change your computer's settings to not go to sleep or hibernate. As an alternate workaround, you can close and re-open the file or run the "Upon Opening" script to re-establish the files in the temporary directory.
January 27, 2020, at 06:33 PM by KC Embrey - Added section on FileMaker 17+ calendar not loading issue
Added lines 88-89:

If you've embedded the calendar or implemented the script updates for [[https://www.seedcode.com/support/viewtopic.php?f=40&t=4550&p=12987#p12987 | build 10.50]] using a version of FileMaker earlier than 17, and are now having issues opening DayBack in FileMaker 17+, there's likely a script step that needs updating. Using FileMaker 17+, verify that the "Create folders" option of the "Export Field Contents" step on line 18 of the "Set Temp Path Folder" script is toggled "On". Close and re-open the file, or run the "Upon Opening" script for the changes to take effect.
September 06, 2019, at 10:02 PM by KC Embrey - Added note on "Create Folders" issue from 10.50
Added lines 14-16:


If you recently applied the script updates for build 10.50, and you used FileMaker Pro 16 or earlier, you'll see a blank web viewer and receive the FMP URL when opening the file with FileMaker 17+. To fix this, open the file in FileMaker 17+ and change the "Create folders" option to "On" in the Export Field Contents step on line 18 of the "Set Temp Path Folder" script.
August 19, 2019, at 11:35 PM by KC Embrey - Added #MissingTrays
Added lines 58-62:

[[#MissingTrays]]
!! Custom Button Action / Additional Fields buttons are missing

If the buttons to open the custom button action or additional fields trays are missing from your popover, it's likely that you've applied in-app updates to your instance of DayBack, but haven't applied the required script updates (specifically from build 10.44). When applying in-app updates, make sure you apply all of the required script updates, from the build you're on, to the latest, as detailed in the [[VersionHistory | version history page here]].
February 26, 2019, at 09:17 PM by Ana Petrechenko - Added the CSS link to the last part
Changed line 186 from:
-> • You could add the following to your CSS theme to adjust the zoom for Windows devices with high DPI screens:
to:
-> • You could add the following to your [[https://www.seedcode.com/pmwiki/index.php?n=DayBackForFileMaker.CSS|CSS theme]] to adjust the zoom for Windows devices with high DPI screens:
February 26, 2019, at 08:48 PM by Ana Petrechenko - Added Windows and high DPI screens
Added lines 177-202:

[[#DPIScreensWithWindows]]
!! Windows and high DPI screens
On Windows systems with a smaller screen and a high DPI (resolution), the calendar text and objects may display very small and unreadable. There are a couple of options to address this, some of which are easier than others.

-> • Since WebViewers are rendered as a web page, they have a separate zoom mechanism from FileMaker's zoom. This means you can zoom into the calendar using ctrl+scroll (or + and -) and it will not affect the other FileMaker objects. This is probably the easiest way to get the calendar objects to render at a higher scale without making your Event Detail window look too large.

-> • You could try increasing the system-wide Windows DPI scaling, keeping in mind that this will have an effect on all apps. Here's a link to instructions on adjusting the Windows DPI scaling: https://technet.microsoft.com/en-us/library/ff629368.aspx?f=255&MSPPError=-2147217396

-> • You could add the following to your CSS theme to adjust the zoom for Windows devices with high DPI screens:

--> @media only screen and (-webkit-min-device-pixel-ratio: 1.8),
--> only screen and (-o-min-device-pixel-ratio: 18/10),
--> only screen and (min-resolution: 180dpi)
--> {
--> @-ms-viewport{
                  width:960px;
              }
--> }


->  This will only apply to Windows devices with screens showing 180dpi (dots per inch) or higher. You might want to modify the 3 dpi settings (1.8, 18/10, 180dpi) to get the right criteria for when to zoom or not.

->  For example, on a 40" 4k screen, DayBack looks great by default, so you don't want to resize on that screen. The dpi on this screen is 110.

->  An 11" 1080p screen has a dpi of 200, so you probably would want to zoom in, but it's going to take some trial and error to get the right number.
January 21, 2019, at 09:29 PM by KC Embrey - Updated IE Security settings
Changed line 172 from:
-> • '''IE Security Settings''' - Your Internet Explorer security settings may be preventing scripts from running in pages. To fix this, you'll want to open the IE settings, go to the Advanced tab, and check the option for "Allow active content to run in files on My Computer" option. Additionally, you could just click the "Restore advanced settings" button to restore everything to default.
to:
-> • '''IE Security Settings''' - Your Internet Explorer security settings may be preventing scripts from running in pages. To fix this, you'll want to open the IE settings, go to the Advanced tab, and check the option for "Allow active content to run in files on My Computer" option. '''A restart of the computer is required for this change to take effect'''
January 21, 2019, at 06:11 PM by 192.88.134.15 -
Changed lines 172-174 from:
#'''IE Security Settings''' - Your Internet Explorer security settings may be preventing scripts from running in pages. To fix this, you'll want to open the IE settings, go to the Advanced tab, and check the option for "Allow active content to run in files on My Computer" option. Additionally, you could just click the "Restore advanced settings" button to restore everything to default.
#'''FileMaker Trial Version''' - If you're running a trial version of FileMaker, this can sometimes be the cause of this error. If this is the cause of the issue, a licensed version of FileMaker should resolve it. Some users have noted that entering the license info into an already installed trial version does not fix this issue, so you'll need to fully uninstall FileMaker, then re-install FileMaker, entering your license details during setup.
#'''Windows 7 Remote Desktop / Terminal Services users''' - Some users of Windows 7 through Remote Desktop Services have reported this issue and haven't been able to resolve it with the above two solutions. In this case, unfortunately, the only option is to acknowledge the script warning and allow scripts to run when loading the calendar.
to:
-> • '''IE Security Settings''' - Your Internet Explorer security settings may be preventing scripts from running in pages. To fix this, you'll want to open the IE settings, go to the Advanced tab, and check the option for "Allow active content to run in files on My Computer" option. Additionally, you could just click the "Restore advanced settings" button to restore everything to default.

-> • '''FileMaker Trial Version''' - If you're running a trial version of FileMaker, this can sometimes be the cause of this error. If this is the cause of the issue, a licensed version of FileMaker should resolve it. Some users have noted that entering the license info into an already installed trial version does not fix this issue, so you'll need to fully uninstall FileMaker, then re-install FileMaker, entering your license details during setup.

-> • '''Windows 7 Remote Desktop / Terminal Services users''' - Some users of Windows 7 through Remote Desktop Services have reported this issue and haven't been able to resolve it with the above two solutions. In this case, unfortunately, the only option is to acknowledge the script warning and allow scripts to run when loading the calendar.
October 31, 2018, at 10:54 PM by KC Embrey - Added section 15 to #NoEvents for CalendarColor record with no Name value
Added lines 51-52:

-> '''15.''' If you're modifying the CalendarColors table directly in any way, instead of using DayBack's built-in sidebar to manage status colors, verify that each record in this table has a value in the "Name" field. Any blank entries in the "Name" field will result in the calendar not being able to load any events.
September 24, 2018, at 11:59 PM by KC Embrey - Added #IEScriptWarning
Added lines 161-172:

[[#IEScriptWarning]]
!! Yellow script warning when opening calendar in Windows
When opening the calendar layout, you see a yellow bar warning you: ''"To help protect your security, Internet Explorer has restricted this webpage from running scripts..."''

This warning is shown from Internet Explorer to notify you that the page (DayBack) is trying to run scripts (JavaScript) to load the page. You can click this warning and allow scripts to run, but this will only be retained for the current WebViewer session. If the calendar layout is re-loaded, it will again show the warning.

There are 3 possible causes of this warning that we have been able to verify:

#'''IE Security Settings''' - Your Internet Explorer security settings may be preventing scripts from running in pages. To fix this, you'll want to open the IE settings, go to the Advanced tab, and check the option for "Allow active content to run in files on My Computer" option. Additionally, you could just click the "Restore advanced settings" button to restore everything to default.
#'''FileMaker Trial Version''' - If you're running a trial version of FileMaker, this can sometimes be the cause of this error. If this is the cause of the issue, a licensed version of FileMaker should resolve it.
#'''Windows 7 Remote Desktop / Terminal Services users''' - Some users of Windows 7 through Remote Desktop Services have reported this issue and haven't been able to resolve it with the above two solutions. In this case, unfortunately, the only option is to acknowledge the script warning and allow scripts to run when loading the calendar.
August 28, 2018, at 08:49 PM by 192.88.134.15 - Added #Memory
Added lines 153-160:

[[#Memory]]
!! Excessive memory use in FileMaker for Windows 16+
There is a reported issue in FileMaker for Windows 16+ with garbage collection when refreshing/reloading WebViewers. This means that every time a WebViewer is refreshed, additional memory is used for the FileMaker process until the program is closed. This usually is not an issue on most computers, but those with limited memory (RAM) may experience performance drops.

Unfortunately, there isn't a fix for this issue, but rather a workaround of closing FileMaker and re-opening your solution.

If you experience this issue and would like to encourage a fix from FileMaker, we encourage you to %newwin% [[https://www.filemaker.com/company/contact/feature_request.html | Give Feedback]] or view the %newwin% [[https://community.filemaker.com/thread/182091 | reported issue]].
May 24, 2018, at 07:46 PM by KC Embrey - Added section to calendar not loading
Added lines 79-80:
Lists in FileMaker require that you have at least two items to be considered a value list. In older builds of DayBack, in the $$sc_CustomEventActions variable, we leave an empty string ("") as the second list item to account for this. If you've recently made changes to the custom actions of a source and you only have one custom action, make sure you've left the extra empty list item in there so that the list is complete.
Added lines 83-91:
[[#NewSource]]
!! After adding a new source, the calendar won't load

DayBack needs to load sources in numerical order without skipping numbers. So if your "Load Source Settings at Startup" script is set up to only load sources 1 and 3 (for example, you've disabled the sample ToDoList source), then the calendar will not load properly. To resolve this, make sure your active source numbers don't skip numbers. For your new source, you'll likely need to

-> '''1.''' Rename your Source No layout,
-> '''2.''' Change the sc_sourceNumber value in the DBk_WebViewerSource field,
-> '''3.''' And change the $sc_SourceNumber value for this source within the "Load Source Settings at Startup" script.

Deleted lines 115-123:

[[#NewSource]]
!! After adding a new source, the calendar won't load

DayBack needs to load sources in numerical order without skipping numbers. So if your "Load Source Settings at Startup" script is set up to only load sources 1 and 3 (for example, you've disabled the sample ToDoList source), then the calendar will not load properly. To resolve this, make sure your active source numbers don't skip numbers. For your new source, you'll likely need to

-> '''1.''' Rename your Source No layout,
-> '''2.''' Change the sc_sourceNumber value in the DBk_WebViewerSource field,
-> '''3.''' And change the $sc_SourceNumber value for this source within the "Load Source Settings at Startup" script.
March 12, 2018, at 05:22 PM by 192.88.134.15 -
Changed line 24 from:
-> '''2.''' Make sure your filename doesn't include an ampersand (&). We use FMP URLs for querying FileMaker data from the WebViewer and the ampersand character is used for separating parameters. A DayBack filename including an ampersand will result in the error message, 'The file "DayBack.fmp12" could not be opened...' and no events will be loaded.
to:
-> '''2.''' Make sure your filename doesn't include an ampersand (&). DayBack uses FMP URLs for querying FileMaker data from the WebViewer and the ampersand character is used for separating parameters. A DayBack filename including an ampersand will result in the error message, 'The file "DayBack.fmp12" could not be opened...' and no events will be loaded.
March 12, 2018, at 05:16 PM by KC Embrey - Added info on ampersand in the filename
Changed lines 24-41 from:
-> '''2.''' Run the "Upon Opening" script again.

-> '''3.''' Double check the calc fields you added to your events table, especially "DBk_WebViewerSource". If they begin /* then they're "commented out" and you need to remove the leading /* and trailing */ before the fields will work
. If this is the case you'll likely need to replace our "sample" fields with your own once you remove these characters and try to save the field.

-> '''4.''' Check out the Source No 1 layout in browse mode, reviewing every tab: are there any errors shown? Do the timestamp calc fields show a valid number like 63611269200? (If not, skip to number 6 below.)

-> '''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 [[MultipleSources | more than one source]]; if the sources are using different date and time fields they'll need different timestamp calcs.

-> '''7.''' A few things in
the calendar use cookies in order to work properly--things like remembering the sidebar's visibility setting for the current user. You may want to check that cookies aren't disabled in your default browser.

-> '''8.''' Are you filtered and forgot? Click "reset filters" at
the bottom of the Filters tab on the calendar's sidebar.

->
'''9.''' Try changing the BuildNumberCalc field in the CalendarInterface table from a global to an unstored calculation. This can help if you've integrated DayBack into your own file while your file was hosted in FileMaker Server.

->
'''10.''' If your file is set up to auto-enter an account that does not have access to the event data, and it is being hosted in FileMaker Server, and you are using Perform Script on Server ([[PSOS]]), your users might not see any data on the DayBack UI. This is because when scripts run on the server they use the auto-login account to query the events table. The solution is to add a "Re-Login" step in your OnFirstWindowOpen script so PSOS will always use the Admin account. Wrap this in an If[] condition with the following formula:
to:
-> '''2.''' Make sure your filename doesn't include an ampersand (&). We use FMP URLs for querying FileMaker data from the WebViewer and the ampersand character is used for separating parameters. A DayBack filename including an ampersand will result in the error message, 'The file "DayBack.fmp12" could not be opened...' and no events will be loaded.

-> '''3.''' Run the "Upon Opening" script again.

-> '''4.''' Double check the calc fields you added to your events table, especially "DBk_WebViewerSource". If they begin /* then they're "commented out" and you need to remove the leading /* and trailing */ before the fields will work. If this is the case you'll likely need to replace our "sample" fields with your own once
you remove these characters and try to save the field.

-> '''5.''' Check out the Source No 1 layout in browse mode, reviewing every tab: are there any errors shown? Do the timestamp calc fields show a valid number like 63611269200? (If not, skip to number 6 below.)

-> '''6.''' 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.

->
'''7.''' 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 [[MultipleSources | more than one source]]; if the sources are using different date and time fields they'll need different timestamp calcs.

-> '''8.''' A few things in the calendar use cookies in order to work properly--things like remembering the sidebar's visibility setting for the current user. You may want to check that cookies aren
't disabled in your default browser.

-> '''9.''' Are you filtered and forgot? Click "reset filters" at the bottom of the Filters tab on the calendar's sidebar.

-> '''10.''' Try changing the BuildNumberCalc field in the CalendarInterface table from a global to an unstored calculation. This can help if you've integrated DayBack into your own file while your file was hosted in FileMaker Server.

-> '''11
.''' If your file is set up to auto-enter an account that does not have access to the event data, and it is being hosted in FileMaker Server, and you are using Perform Script on Server ([[PSOS]]), your users might not see any data on the DayBack UI. This is because when scripts run on the server they use the auto-login account to query the events table. The solution is to add a "Re-Login" step in your OnFirstWindowOpen script so PSOS will always use the Admin account. Wrap this in an If[] condition with the following formula:
Changed lines 46-50 from:
-> '''11.''' A similar PSOS issue: if you're using Record Level Access and some of your access rules depend on global fields or variables, these are likely not being respected in PSOS sessions. Turn PSOS off (instructions are [[PSOS | here]] to see if your events show up. If they do, you'll need to set these variables as part of your OnFirstWindowOpen script so they're present in the data file when DayBack runs scripts there. Then turn PSOS back on.

-> '''12.''' Rarely, some months may appear to have all events missing, caused by a lone backslash "\" in one of your event records. If an event field ends in or contains only a backslash, removing this character or adding another character after it will correct the issue.

-> '''13.''' A few users have experienced events not loading when running an older version of MacOS Sierra (10.12.5 or below) and FileMaker 16. Upgrading the Operating System should resolve this issue.
to:
-> '''12.''' A similar PSOS issue: if you're using Record Level Access and some of your access rules depend on global fields or variables, these are likely not being respected in PSOS sessions. Turn PSOS off (instructions are [[PSOS | here]] to see if your events show up. If they do, you'll need to set these variables as part of your OnFirstWindowOpen script so they're present in the data file when DayBack runs scripts there. Then turn PSOS back on.

-> '''13.''' Rarely, some months may appear to have all events missing, caused by a lone backslash "\" in one of your event records. If an event field ends in or contains only a backslash, removing this character or adding another character after it will correct the issue.

-> '''14.''' A few users have experienced events not loading when running an older version of MacOS Sierra (10.12.5 or below) and FileMaker 16. Upgrading the Operating System should resolve this issue.
January 25, 2018, at 06:31 PM by KC Embrey - Added #BlankPopover
Added lines 49-53:

[[#BlankPopover]]
!! Event popover blank / contents not loading

Some users of MacOS High Sierra have experienced a completely blank popover in DayBack. This seems to be an issue with earlier builds of High Sierra and can be fixed by making sure you have installed the latest updates to the OS.
November 15, 2017, at 06:13 PM by 192.88.134.15 -
Added lines 140-144:

[[#TouchZoom]]
!! I can't zoom on my Windows touchscreen device

Since DayBack is viewed in a web viewer, Windows touchscreen zoom features do not work on the calendar.  To zoom, use the Ctrl-Scroll on a mouse.
November 13, 2017, at 07:52 PM by 192.88.134.15 -
Changed line 28 from:
-> '''4.''' Check out the Source No 1 layout in browse mode, reviewing every tab: are there any errors shown? Do the timestamp calc fields show a valid number like 63611269200? (If not, skip to no 6 below.)
to:
-> '''4.''' Check out the Source No 1 layout in browse mode, reviewing every tab: are there any errors shown? Do the timestamp calc fields show a valid number like 63611269200? (If not, skip to number 6 below.)
November 13, 2017, at 07:51 PM by 192.88.134.15 -
Changed line 11 from:
The calendar uses the fmp url protocol to call scripts in your file. Some computers can get confused as to which copy of FileMaker to use in responding to these url calls. Symptoms can include the calendar showing now events, or launching another copy of FileMaker on startup.
to:
The calendar uses the fmp url protocol to call scripts in your file. Some computers can get confused as to which copy of FileMaker to use in responding to these url calls. Symptoms can include the calendar showing no events, or launching another copy of FileMaker on startup.
November 13, 2017, at 07:51 PM by 192.88.134.15 -
Changed line 7 from:
...you'll need to a make a simple change in your solution to accommodate a new feature in FileMaker 16. Learn more here: [[FMPURL | FMP URLs in Next]].
to:
...you'll need to a make a simple change in your solution to accommodate a new feature in FileMaker 16. Learn more here: [[FMPURL | FMP URLs]].
September 18, 2017, at 08:45 PM by KC Embrey - Added old Sierra check
Added lines 47-48:

-> '''13.''' A few users have experienced events not loading when running an older version of MacOS Sierra (10.12.5 or below) and FileMaker 16. Upgrading the Operating System should resolve this issue.
May 09, 2017, at 01:15 PM by 192.88.134.15 -
Changed lines 1-4 from:
!! FileMaker "next": Changes Required

If you're seeing this error when you first open DayBack in FileMaker "Next"...
to:
!! FileMaker 16: Changes Required

If you're seeing this error when you first open DayBack in FileMaker 16...
Changed line 7 from:
...you'll need to a make a simple change in your solution to accommodate a new feature in FileMaker Next. Learn more here: [[FMPURL | FMP URLs in Next]].
to:
...you'll need to a make a simple change in your solution to accommodate a new feature in FileMaker 16. Learn more here: [[FMPURL | FMP URLs in Next]].
May 02, 2017, at 03:06 PM by 192.88.134.15 -
Changed line 7 from:
...you'll need to a make a simple change in your solution to accommodate a new feature in FileMaker Next. Learn more here: [[FMPURL | FMP URLs in FM16]].
to:
...you'll need to a make a simple change in your solution to accommodate a new feature in FileMaker Next. Learn more here: [[FMPURL | FMP URLs in Next]].
May 02, 2017, at 03:06 PM by 192.88.134.15 -
Changed lines 3-4 from:
If you're seeing this error when you first open DayBack in FileMaker 16...
to:
If you're seeing this error when you first open DayBack in FileMaker "Next"...
Changed line 7 from:
...you'll need to a make a simple change in your solution to accommodate a new feature in FileMaker 16. Learn more here: [[FMPURL | FMP URLs in FM16]].
to:
...you'll need to a make a simple change in your solution to accommodate a new feature in FileMaker Next. Learn more here: [[FMPURL | FMP URLs in FM16]].
April 24, 2017, at 06:04 PM by 192.88.134.15 -
Changed lines 110-115 from:
!! Setting selections aren't retained when leaving the calendar on Windows"

On
windows FileMaker does not retain cookies or local storage items in the web viewer. This is a limitation that is present when Internet Explorer is not open. If Internet Explorer is open while using DayBack on windows then cookies are available and can be used to store settings for that session.

We have created a simple command for determining if Internet Explorer is not open, if it is then IE will be launched hidden. To add this behavior to your file follow the directions below:
to:
!! Setting selections aren't retained when leaving the calendar on Windows

On
windows FileMaker does not retain cookies or local storage items in the webviewer. This is a limitation that is present when Internet Explorer is not open. If Internet Explorer is open while using DayBack on windows then cookies are available and can be used to store settings for that session.

We have created a simple command for determining if Internet Explorer is not open, if it is not open then IE will be launched hidden. To add this behavior to your file follow the directions below:
Changed lines 120-121 from:
cmd.exe /c tasklist | find "iexplore.exe" || start /B /MIN iexplore.exe
to:
--> cmd.exe /c tasklist | find "iexplore.exe" || start /B /MIN iexplore.exe
Changed lines 125-126 from:
Then you can choose to either run this script at startup or as a script trigger on layout exit. Startup is great is then it only runs once, the issue with relying on that is that if a user closes IE during the use of the calendar saving settings for the session will no longer work. So we recommend a combination. Run the script on startup to make sure IE is open. Then add a script trigger to the "Calendar" layout to run the script for "OnLayoutExit". To ensure IE has time to fully launch please add a "Pause/Resume" script step for 2 seconds at the end of the "Launch IE" script.
to:
Wrap the send event script step in an if statement so we only run this command in Windows. The if statement will evaluate:

--> Abs ( Get ( SystemPlatform ) ) = 2

Then you can choose to either run this script at startup or as a script trigger "OnLayoutExit". Running on startup is great as then it only runs once, be aware that if a user closes IE during the use of the calendar saving settings for
the session will no longer work. So we recommend a combination. Run the script on startup to make sure IE is open. Then add a script trigger to the "Calendar" layout to run the script for "OnLayoutExit". To ensure IE has time to fully launch please add a "Pause/Resume" script step for 2 seconds at the end of the "Launch IE" script inside the if statement as shown in the image above.
April 24, 2017, at 05:49 PM by 192.88.134.15 -
Changed lines 108-126 from:
There is a script step at the beginning of DayBack's "Upon Opening" script (at line 18) that records the current window name being used for the calendar: it sounds like you've renamed the window *after* that script ran. Just return there and use the Upon Opening script to set the window name you want to use (at line 15) and you should be all set.
to:
There is a script step at the beginning of DayBack's "Upon Opening" script (at line 18) that records the current window name being used for the calendar: it sounds like you've renamed the window *after* that script ran. Just return there and use the Upon Opening script to set the window name you want to use (at line 15) and you should be all set.

!! Setting selections aren't retained when leaving the calendar on Windows"

On windows FileMaker does not retain cookies or local storage items in the web viewer. This is a limitation that is present when Internet Explorer is not open. If Internet Explorer is open while using DayBack on windows then cookies are available and can be used to store settings for that session.

We have created a simple command for determining if Internet Explorer is not open, if it is then IE will be launched hidden. To add this behavior to your file follow the directions below:

Create a new script called "Launch IE"

In this new script add a "Send Event" script step, and select the "text" option. Then paste the code below in the text box:

cmd.exe /c tasklist | find "iexplore.exe" || start /B /MIN iexplore.exe

It should look like this:
%center% %newwin width=440px% [[https://www.seedcode.com/rootimages/stikipad/dayback/launch-ie.png | https://www.seedcode.com/rootimages/stikipad/dayback/launch-ie.png]]

Then you can choose to either run this script at startup or as a script trigger on layout exit. Startup is great is then it only runs once, the issue with relying on that is that if a user closes IE during the use of the calendar saving settings for the session will no longer work. So we recommend a combination. Run the script on startup to make sure IE is open. Then add a script trigger to the "Calendar" layout to run the script for "OnLayoutExit". To ensure IE has time to fully launch please add a "Pause/Resume" script step for 2 seconds at the end of the "Launch IE" script.

Changed line 13 from:
Here is a test to make sure the URL protocol is working properly in your version, along with instructions on hot to fox it:  [[FMPURL | FMP URLs]]
to:
Here is a test to make sure the URL protocol is working properly in your version, along with instructions on how to fix it:  [[FMPURL | FMP URLs]]
March 29, 2017, at 12:29 AM by 192.88.134.15 -
Changed line 7 from:
...you'll need to a make a simple change in your solution to accommodate a new feature in FileMaker 16. Learn more here: [[FMPURUL | FMP URLs in FM16]].
to:
...you'll need to a make a simple change in your solution to accommodate a new feature in FileMaker 16. Learn more here: [[FMPURL | FMP URLs in FM16]].
March 22, 2017, at 06:02 PM by 192.88.134.15 -
March 22, 2017, at 06:02 PM by 192.88.134.15 -
Changed lines 1-3 from:
>>comment<<
!! FileMaker 16: Changes Required
to:
!! FileMaker "next": Changes Required
Deleted line 7:
>><<
March 21, 2017, at 01:02 AM by 192.88.134.15 -
Changed line 1 from:
>comment<<
to:
>>comment<<
March 21, 2017, at 01:02 AM by 192.88.134.15 -
Changed line 1 from:
>>comment<<
to:
>comment<<
March 21, 2017, at 01:02 AM by 192.88.134.15 -
March 21, 2017, at 01:02 AM by 192.88.134.15 -
Changed lines 2-8 from:
Test of hiding content
to:
!! FileMaker 16: Changes Required

If you're seeing this error when you first open DayBack in FileMaker 16...

%center% %newwin width=440px% [[https://www.seedcode.com/rootimages/stikipad/dayback/urlerror1-2.png | https://www.seedcode.com/rootimages/stikipad/dayback/urlerror1-2.png]]

...you'll need to a make a simple change in your solution to accommodate a new feature in FileMaker 16. Learn more here: [[FMPURUL | FMP URLs in FM16]].
March 21, 2017, at 12:49 AM by 192.88.134.15 -
Added lines 1-4:
>>comment<<
Test of hiding content
>><<

March 03, 2017, at 03:20 PM by 192.88.134.15 -
Changed lines 32-33 from:
-> '''10.''' If your file is set up to auto-enter an account that does not have access to the event data, and it is being hosted in FileMaker Server, and you are using PSOS, your users might not see any data on the DayBack UI. This is because when scripts run on the server they use the auto-login account to query the events table. The solution is to add a "Re-Login" step in your OnFirstWindowOpen script so PSOS will always use the Admin account. Wrap this in an If[] condition with the following formula:
to:
-> '''10.''' If your file is set up to auto-enter an account that does not have access to the event data, and it is being hosted in FileMaker Server, and you are using Perform Script on Server ([[PSOS]]), your users might not see any data on the DayBack UI. This is because when scripts run on the server they use the auto-login account to query the events table. The solution is to add a "Re-Login" step in your OnFirstWindowOpen script so PSOS will always use the Admin account. Wrap this in an If[] condition with the following formula:
Changed lines 36-38 from:
-> '''11.''' Rarely, some months may appear to have all events missing, caused by a lone backslash "\" in one of your event records. If an event field ends in or contains only a backslash, removing this character or adding another character after it will correct the issue.
to:
-> '''11.''' A similar PSOS issue: if you're using Record Level Access and some of your access rules depend on global fields or variables, these are likely not being respected in PSOS sessions. Turn PSOS off (instructions are [[PSOS | here]] to see if your events show up. If they do, you'll need to set these variables as part of your OnFirstWindowOpen script so they're present in the data file when DayBack runs scripts there. Then turn PSOS back on.

-> '''12
.''' Rarely, some months may appear to have all events missing, caused by a lone backslash "\" in one of your event records. If an event field ends in or contains only a backslash, removing this character or adding another character after it will correct the issue.
January 16, 2017, at 06:12 PM by 192.88.134.15 -
Changed lines 3-29 from:
The calendar uses the fmp url protocol to call scripts in your file. Some computers can get confused as to which copy of FileMaker to use in responding to these url calls.

You can verify that your fmp url calls are working correctly by opening DayBack, then clicking on following link:
[[fmp://$/DayBack.fmp12?script=Unused&param=run]]

->''Note: If you receive the message 'The file "DayBack.fmp12" could not be opened', you likely have renamed your DayBack file or embedded DayBack into your own file. In this case, you will need to copy this link, paste it into your web browser's address bar, replace the "'''DayBack.fmp12'''" portion with the name of your file and press enter/go.''

If you receive a popup in FileMaker with the message "''This button is not yet assigned to anything''", your fmp url calls are working correctly.

If the above test fails to run, or gives you a different error message, your fmp url calls are not functioning properly. Fortunately this is pretty easy to fix...

-> '''Mac.''' Usually the Mac will open the URL in the highest currently open version of FileMaker. So all you may need to do is quit the version of FileMaker you don' want to be using. But you may be able to modify the launch services plist file directly. Open ~/Library/Preferences/com.apple.LaunchServices.plist \\
and you'll find an array called LSHandlers and a sub-array called LSHandlerURLScheme... In some cases you'll see that was pointing to fmp and not fmpa13. This doesn't appear to be in the same place for every version of MacOSX.

-> '''Windows.''' If you've installed multiple instances of FileMaker, URL links will open, by default, in the last version of FileMaker installed. If you'd like to change the default FileMaker version that is used for FMP URL links in Windows, you can modify a registry key, rather than uninstall/re-install that version of FileMaker.
 
-> First, while this change should not affect your system in a devastating way, if you don't implement it correctly or modify/delete the wrong keys, you make render your system unusable. Therefore, a warning from Microsoft: ''Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to re-install Windows to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.''
 
-> There is only one registry key value that must be modified for this solution. If you can't find this key in your registry, it would probably be best to just uninstall/re-install the version of FileMaker you'd like to open FMP URL links by default.
 
# 1. Open Regedit and Backup your registry. (Instructions Here)
# 2. Find the following key:
# @@HKEY_CLASSES_ROOT\FMP\shell\open\command@@
# 3. Modify the "(Default)" value with the path to the version of FileMaker you'd like to use by default with the following added at the end:''' %1'''. for example:
# @@C:\Program Files\FileMaker\FileMaker Pro 15 Advanced\FileMaker Pro Advanced.exe %1@@
-> You may need to restart FileMaker to see the changes take effect. This change should update your system to open FMP URL links with the version of FileMaker you specified in the registry.

to:
The calendar uses the fmp url protocol to call scripts in your file. Some computers can get confused as to which copy of FileMaker to use in responding to these url calls. Symptoms can include the calendar showing now events, or launching another copy of FileMaker on startup.

Here is a test to make sure the URL protocol is working properly in your version, along with instructions on hot to fox it:  [[FMPURL | FMP URLs]]

Changed line 14 from:
-> '''1.''' Do you have any other versions of FileMaker open? The calendar utilizes the FMP url protocol. When multiple versions of FileMaker are open at once this protocol may target the wrong version and scripts will not fire in the version where the DayBack file is open. Just close the other open FileMaker apps and everything should work as expected.
to:
-> '''1.''' Do you have any other versions of FileMaker open? The calendar utilizes the FMP URL protocol. When multiple versions of FileMaker are open at once this protocol may target the wrong version and scripts will not fire in the version where the DayBack file is open. Just close the other open FileMaker apps and everything should work as expected. Or see our article on [[FMPURL | FMP URLs]] to test the they are working
January 06, 2017, at 09:12 PM by 192.88.134.15 -
Changed lines 14-19 from:
-> '''Mac.''' There is a free preference pane you can download that allows you to select which application is associated with a url protocol. In this case we are referring to the  "fmp" protocol. Just download and install %newwin% [[https://www.rubicode.com/Software/RCDefaultApp/ | this preference pane]] (once downloaded just double click to install it). Then navigate to the "URL's" tab and find "fmp" in the list of protocols. From there you can choose the proper version of Filemaker you would like to open when that url protocol is invoked. Please note that this preference pane is not made by us, please use at your own risk. We have tested it on Macos X Yosemite and it worked great for us. If you want to uninstall the preference pane when you are done you can just right click on it and there is an option to uninstall.

%center% %width=440% https://www.seedcode.com/rootimages/stikipad/dayback/fmp-url-pref-pane.png

-> As an alternative you may be able to modify the launch services plist file directly. Open ~/Library/Preferences/com.apple.LaunchServices.plist \\
and you'll find an array called LSHandlers and a sub-array called LSHandlerURLScheme... In some cases you'll see that was pointing to fmp and not fmpa13. This doesn't appear to be in the same place for every version of MacOSX so if you can't locate this file the preference pane mentioned above is the way to go
.
to:
-> '''Mac.''' Usually the Mac will open the URL in the highest currently open version of FileMaker. So all you may need to do is quit the version of FileMaker you don' want to be using. But you may be able to modify the launch services plist file directly. Open ~/Library/Preferences/com.apple.LaunchServices.plist \\
and you'll find an array called LSHandlers
and a sub-array called LSHandlerURLScheme... In some cases you'll see that was pointing to fmp and not fmpa13. This doesn't appear to be in the same place for every version of MacOSX.
January 06, 2017, at 09:05 PM by 192.88.134.15 -
Changed line 14 from:
-> '''Mac.''' There is a free preference pane you can download that allows you to select which application is associated with a url protocol. In this case we are referring to the  "fmp" protocol. Just download and install [[https://www.rubicode.com/Software/RCDefaultApp/ | this preference pane]] (once downloaded just double click to install it). Then navigate to the "URL's" tab and find "fmp" in the list of protocols. From there you can choose the proper version of Filemaker you would like to open when that url protocol is invoked. Please note that this preference pane is not made by us, please use at your own risk. We have tested it on Macos X Yosemite and it worked great for us. If you want to uninstall the preference pane when you are done you can just right click on it and there is an option to uninstall.
to:
-> '''Mac.''' There is a free preference pane you can download that allows you to select which application is associated with a url protocol. In this case we are referring to the  "fmp" protocol. Just download and install %newwin% [[https://www.rubicode.com/Software/RCDefaultApp/ | this preference pane]] (once downloaded just double click to install it). Then navigate to the "URL's" tab and find "fmp" in the list of protocols. From there you can choose the proper version of Filemaker you would like to open when that url protocol is invoked. Please note that this preference pane is not made by us, please use at your own risk. We have tested it on Macos X Yosemite and it worked great for us. If you want to uninstall the preference pane when you are done you can just right click on it and there is an option to uninstall.
January 06, 2017, at 09:03 PM by 192.88.134.15 -
Changed line 12 from:
If the above test fails to run, or gives you a different error message, your fmp url calls are not functioning properly. Fortunately this is pretty easy to fix.
to:
If the above test fails to run, or gives you a different error message, your fmp url calls are not functioning properly. Fortunately this is pretty easy to fix...
January 06, 2017, at 09:03 PM by 192.88.134.15 -
Changed line 3 from:
The calendar uses the fmp url protocol to call scripts in your file. Some folks computers can get confused as to which copy of FileMaker to use in responding to these url calls.
to:
The calendar uses the fmp url protocol to call scripts in your file. Some computers can get confused as to which copy of FileMaker to use in responding to these url calls.
January 06, 2017, at 09:02 PM by 192.88.134.15 -
Changed line 1 from:
!! Url Issues, or the Calendar Seems to be Opening an Older Copy of FileMaker
to:
!! URL Issues, or the Calendar Seems to be Opening an Older Copy of FileMaker
January 06, 2017, at 09:02 PM by 192.88.134.15 -
Changed line 1 from:
!! The Calendar Seems to be Opening an Older Copy of FileMaker
to:
!! Url Issues, or the Calendar Seems to be Opening an Older Copy of FileMaker
January 06, 2017, at 06:55 PM by KC Embrey - FIxed section describing fmp url test
Changed line 8 from:
->''Note: If you receive the message "The file "DayBack.fmp12 could not be opened." you likely have renamed your DayBack file or embedded DayBack into your own file. In this case, you will need to copy this link, paste it into your web browser's address bar, replace the "'''DayBack.fmp12'''" portion with the name of your file and press enter/go.''
to:
->''Note: If you receive the message 'The file "DayBack.fmp12" could not be opened', you likely have renamed your DayBack file or embedded DayBack into your own file. In this case, you will need to copy this link, paste it into your web browser's address bar, replace the "'''DayBack.fmp12'''" portion with the name of your file and press enter/go.''
Changed lines 3-12 from:
The calendar uses the fmp:/url protocol to call scripts in your file. Some folks computers can get confused as to which copy of FileMaker to use in responding to these url calls. Fortunately this is pretty easy to fix.
to:
The calendar uses the fmp url protocol to call scripts in your file. Some folks computers can get confused as to which copy of FileMaker to use in responding to these url calls.

You can verify that your fmp url calls are working correctly by opening DayBack, then clicking on following link:
[[fmp://$/DayBack.fmp12?script=Unused&param=run]]

->''Note: If you receive the message "The file "DayBack.fmp12 could not be opened." you likely have renamed your DayBack file or embedded DayBack into your own file. In this case, you will need to copy this link, paste it into your web browser's address bar, replace the "'''DayBack.fmp12'''" portion with the name of your file and press enter/go.''

If you receive a popup in FileMaker with the message "''This button is not yet assigned to anything''", your fmp url calls are working correctly.

If the above test fails to run, or gives you a different error message, your fmp url calls are not functioning properly
. Fortunately this is pretty easy to fix.
January 06, 2017, at 04:03 PM by 192.88.134.15 -
Changed line 115 from:
There is a script step at the beginning of DayBack's "Upon Opening" script (at line 18) that records the current window name being used for the calendar: it sounds like you've renamed the window *after* that script ran. Just return there and use the Upon Opening script to rename the window (at line 15) and you should be all set.
to:
There is a script step at the beginning of DayBack's "Upon Opening" script (at line 18) that records the current window name being used for the calendar: it sounds like you've renamed the window *after* that script ran. Just return there and use the Upon Opening script to set the window name you want to use (at line 15) and you should be all set.
January 06, 2017, at 04:02 PM by 192.88.134.15 -
Changed lines 109-115 from:
In some versions of Windows, parts of your event detail window (when not using DayBack's event popover) can appear to hang over the calendar after closing it. To resolve this, add two "Move/Resize Window" script steps to the bottom of the "Close Event Window & Refresh Calendar" script. Have the first set the width to Get ( WindowWidth ) + 1, and the second set the width to Get ( WindowWidth ) - 1. Users should not notice these adjustments, but the calendar will redraw so that the event window is fully cleared away!
to:
In some versions of Windows, parts of your event detail window (when not using DayBack's event popover) can appear to hang over the calendar after closing it. To resolve this, add two "Move/Resize Window" script steps to the bottom of the "Close Event Window & Refresh Calendar" script. Have the first set the width to Get ( WindowWidth ) + 1, and the second set the width to Get ( WindowWidth ) - 1. Users should not notice these adjustments, but the calendar will redraw so that the event window is fully cleared away!

!! I'm seeing "The calendar is meant to run in the main solution window only"

This warning is meant to fire if you try to make a second calendar window, but can also come up if you're renaming the calendar window after DayBack's Upon Opening script has run.

There is a script step at the beginning of DayBack's "Upon Opening" script (at line 18) that records the current window name being used for the calendar: it sounds like you've renamed the window *after* that script ran. Just return there and use the Upon Opening script to rename the window (at line 15) and you should be all set.
December 31, 2016, at 06:36 PM by 192.88.134.15 -
Added lines 94-95:

The command is fmsadmin restart fmse -y
November 28, 2016, at 11:12 PM by KC Embrey - Added instructions for updating FMP URL in Windows
Changed lines 12-23 from:
-> '''Windows.''' We're looking for a comparable setting on Windows, but usually the first copy of FileMaker that is opened is the one that will open with an FMP url protocol. Close all copies of FMP and re-open the one you are running the calendar in. If that doesn't work then reinstalling your latest copy of FileMaker should fix the issue.
to:
-> '''Windows.''' If you've installed multiple instances of FileMaker, URL links will open, by default, in the last version of FileMaker installed. If you'd like to change the default FileMaker version that is used for FMP URL links in Windows, you can modify a registry key, rather than uninstall/re-install that version of FileMaker.
 
-> First, while this change
should not affect your system in a devastating way, if you don't implement it correctly or modify/delete the wrong keys, you make render your system unusable. Therefore, a warning from Microsoft: ''Using Registry Editor incorrectly can cause serious, system-wide problems that may require you to re-install Windows to correct them. Microsoft cannot guarantee that any problems resulting from the use of Registry Editor can be solved. Use this tool at your own risk.''
 
-> There is only one registry key value that must be modified for this solution. If you can't find this key in your registry, it would probably be best to just uninstall/re-install the version of FileMaker you'd like to open FMP URL links by default.
 
# 1. Open Regedit and Backup your registry. (Instructions Here)
# 2. Find the following key:
# @@HKEY_CLASSES_ROOT\FMP\shell\open\command@@
# 3. Modify the "(Default)" value with the path to the version of FileMaker you'd like to use by default with the following added at the end:''' %1'''. for example:
# @@C:\Program Files\FileMaker\FileMaker Pro 15 Advanced\FileMaker Pro Advanced.exe %1@@
-> You may need to restart FileMaker to see the changes take effect. This change should update your system to open FMP URL links with the version of FileMaker you specified in the registry
.
November 02, 2016, at 02:59 PM by Dan Wheelon - Combine can't see events sections
Changed lines 14-17 from:
!! What's Wrong?

If you can't see any events in the calendar after your integration, here are a couple
things to check.
to:
!! No events appearing on the calendar?

If you can't see any events in the calendar after your integration, here are a few
things to check.
Added lines 38-43:
-> '''10.''' If your file is set up to auto-enter an account that does not have access to the event data, and it is being hosted in FileMaker Server, and you are using PSOS, your users might not see any data on the DayBack UI. This is because when scripts run on the server they use the auto-login account to query the events table. The solution is to add a "Re-Login" step in your OnFirstWindowOpen script so PSOS will always use the Admin account. Wrap this in an If[] condition with the following formula:

--> PatternCount (Get(ApplicationVersion); "Server")

-> '''11.''' Rarely, some months may appear to have all events missing, caused by a lone backslash "\" in one of your event records. If an event field ends in or contains only a backslash, removing this character or adding another character after it will correct the issue.

Deleted lines 64-71:

!! No events appearing on the calendar

If your file is set up to auto-enter an account that does not have access to the event data, and it is being hosted in FileMaker Server, and you are using PSOS, your users might not see any data on the DayBack UI. This is because when scripts run on the server they use the auto-login account to query the events table. The solution is to add a "Re-Login" step in your OnFirstWindowOpen script so PSOS will always use the Admin account. Wrap this in an If[] condition with the following formula:

-> PatternCount (Get(ApplicationVersion); "Server")

Rarely, some months may appear to have all events missing, caused by a lone backslash "\" in one of your event records. If an event field ends in or contains only a backslash, removing this character or adding another character after it will correct the issue.
October 27, 2016, at 10:51 PM by Dan Wheelon - error 103
Added lines 48-51:
-> '''Error 103'''

--> "Relationship is missing." Double check to make sure the table occurrence name for your calendar source matches the $$sc_SourceTableOccurrenceName variable set within the "Load Calendar Settings at Startup..." script. The value in that variable may be matching a table occurrence on DayBack's relationship graph -- just not the correct one for this source.

Changed line 94 from:
In some versions of Windows, parts of your event detail window (when not using DayBack's event popover) can appear to hang over the calendar after closing it. To resolve this, add two "Move/Resize Window" script steps to the bottom of the "Close Event Window & Refresh Calendar" script. Have the first set the width to Get ( WindowWidth ) + 1, and the second set the width to Get ( WindowWidth ) - 1. Users should not notice these adjustments, but the calendar will redraw so that the event window is fully cleared away!
to:
In some versions of Windows, parts of your event detail window (when not using DayBack's event popover) can appear to hang over the calendar after closing it. To resolve this, add two "Move/Resize Window" script steps to the bottom of the "Close Event Window & Refresh Calendar" script. Have the first set the width to Get ( WindowWidth ) + 1, and the second set the width to Get ( WindowWidth ) - 1. Users should not notice these adjustments, but the calendar will redraw so that the event window is fully cleared away!
September 28, 2016, at 04:39 PM by Dan Wheelon - Adding a new source, calendar won't load
Added lines 80-87:
!! After adding a new source, the calendar won't load

DayBack needs to load sources in numerical order without skipping numbers. So if your "Load Source Settings at Startup" script is set up to only load sources 1 and 3 (for example, you've disabled the sample ToDoList source), then the calendar will not load properly. To resolve this, make sure your active source numbers don't skip numbers. For your new source, you'll likely need to

-> '''1.''' Rename your Source No layout,
-> '''2.''' Change the sc_sourceNumber value in the DBk_WebViewerSource field,
-> '''3.''' And change the $sc_SourceNumber value for this source within the "Load Source Settings at Startup" script.

Deleted line 90:
July 15, 2016, at 02:27 AM by Dan Wheelon -
Changed lines 78-83 from:
If you see a FileMaker warning that the "Host Capacity is Exceeded" when loading the calendar, and DayBack is hosted on a FileMaker Server, it's possible your Server's scripting engine has stopped. To quickly get past this issue, you can disable DayBack's use of PSOS by editing the first Set Variable step in the "Load Calendar Settings - On Startup..." script. You can also restart your server's "fmse" component using the command line on the host machine to get the scripting engine running again and continue taking advantage of PSOS in DayBack.
to:
If you see a FileMaker warning that the "Host Capacity is Exceeded" when loading the calendar, and DayBack is hosted on a FileMaker Server, it's possible your Server's scripting engine has stopped. To quickly get past this issue, you can disable DayBack's use of PSOS by editing the first Set Variable step in the "Load Calendar Settings - On Startup..." script. You can also restart your server's "fmse" component using the command line on the host machine to get the scripting engine running again and continue taking advantage of PSOS in DayBack.

!! The Event Detail window hangs after it's closed

In some versions of Windows, parts of your event detail window (when not using DayBack's event popover) can appear to hang over the calendar after closing it. To resolve it, add two "Move/Resize Window" script steps to the bottom of the "Close Event Window & Refresh Calendar" script. Have the first set the width to Get ( WindowWidth ) + 1, and the second set the width to Get ( WindowWidth ) - 1. The user should not notice these adjustments, but the calendar should redraw so that the event window is fully cleared away.

May 05, 2016, at 07:46 PM by Dan Wheelon - Added note about Host capacity exceeded warnings
Changed lines 74-78 from:
If you see "Summarizing Field "DBk_WebViewerEventData" it could be because you're returning a TON of data from FileMaker. You'll find more about this and strategies to slim down your event payload as the last section on the page here: [[Speed]].
to:
If you see "Summarizing Field "DBk_WebViewerEventData" it could be because you're returning a TON of data from FileMaker. You'll find more about this and strategies to slim down your event payload as the last section on the page here: [[Speed]].

!! I'm seeing "Host Capacity is Exceeded" warnings

If you see a FileMaker warning that the "Host Capacity is Exceeded" when loading the calendar, and DayBack is hosted on a FileMaker Server, it's possible your Server's scripting engine has stopped. To quickly get past this issue, you can disable DayBack's use of PSOS by editing the first Set Variable step in the "Load Calendar Settings - On Startup..." script. You can also restart your server's "fmse" component using the command line on the host machine to get the scripting engine running again and continue taking advantage of PSOS in DayBack
.
April 26, 2016, at 05:07 PM by 192.88.134.15 -
Changed line 74 from:
If you see "Summarizing Field "DBk_WebViewerEventData" it could be because you're returning a TON of data from FileMaker. You'll find more about the and strategies to slim down your event payload as the last section on the page here: [[Speed]].
to:
If you see "Summarizing Field "DBk_WebViewerEventData" it could be because you're returning a TON of data from FileMaker. You'll find more about this and strategies to slim down your event payload as the last section on the page here: [[Speed]].
April 26, 2016, at 05:07 PM by 192.88.134.15 -
Changed lines 70-74 from:
Your custom themes and translations can be overwritten if a "Restore" button is pressed from the "Under the Hood" layout, or if the CalendarInterface record is deleted. Because of this, you can add a custom menu set with the "Records" menu removed, and apply it to the layouts based on the CalendarInterface table occurrence. This should prevent the CalendarInterface record from being unintentionally deleted. Also, save the text of your modified theme or translations in a text file outside of FileMaker for backup. That way, you can quickly restore your custom themes or translations in case they are overwritten by pasting them back into DayBack.
to:
Your custom themes and translations can be overwritten if a "Restore" button is pressed from the "Under the Hood" layout, or if the CalendarInterface record is deleted. Because of this, you can add a custom menu set with the "Records" menu removed, and apply it to the layouts based on the CalendarInterface table occurrence. This should prevent the CalendarInterface record from being unintentionally deleted. Also, save the text of your modified theme or translations in a text file outside of FileMaker for backup. That way, you can quickly restore your custom themes or translations in case they are overwritten by pasting them back into DayBack.

!! I'm seeing "Summarizing..." when the calendar loads

If you see "Summarizing Field "DBk_WebViewerEventData" it could be because you're returning a TON of data from FileMaker. You'll find more about the and strategies to slim down your event payload as the last section on the page here: [[Speed]]
.
March 21, 2016, at 08:02 PM by Dan Wheelon -
Changed line 70 from:
Your custom themes and translations can be overwritten if a "Restore" button is pressed from the "Under the Hood" layout, or if the CalendarInterface record is deleted. Because of this, you can add a custom menu with the "Records" menu removed, and apply it to the layouts based on the CalendarInterface table occurrence. This should prevent the CalendarInterface record from being unintentionally deleted. Also, save the text of your modified theme or translations in a text file outside of FileMaker for backup. That way, you can quickly restore your custom themes or translations in case they are overwritten by pasting them back into DayBack.
to:
Your custom themes and translations can be overwritten if a "Restore" button is pressed from the "Under the Hood" layout, or if the CalendarInterface record is deleted. Because of this, you can add a custom menu set with the "Records" menu removed, and apply it to the layouts based on the CalendarInterface table occurrence. This should prevent the CalendarInterface record from being unintentionally deleted. Also, save the text of your modified theme or translations in a text file outside of FileMaker for backup. That way, you can quickly restore your custom themes or translations in case they are overwritten by pasting them back into DayBack.
March 21, 2016, at 08:01 PM by Dan Wheelon -
Changed line 68 from:
!! I seem to be losing my custom translations or CSS themes!
to:
!! Losing custom translations or CSS themes
March 21, 2016, at 08:01 PM by Dan Wheelon - Losing custom translations and themes
Changed lines 66-70 from:
There are a couple of fields you need to add to your contact and project tables and it can be easy to overlook these--or the fields may be there but be commented out (that is, they may begin with /* and end with */). The fields are described [[LinkedContactsAndProjects | here]], please take a moment to make sure they're in your contact or project table and that they're returning data (ie add the fields to a layout and look at the fields in browse mode). If they're not returning data it's likely that the calcs are commented out: uncomment them and follow the instructions inside each calc to point it at the correct fields in your contact or project.
to:
There are a couple of fields you need to add to your contact and project tables and it can be easy to overlook these--or the fields may be there but be commented out (that is, they may begin with /* and end with */). The fields are described [[LinkedContactsAndProjects | here]], please take a moment to make sure they're in your contact or project table and that they're returning data (ie add the fields to a layout and look at the fields in browse mode). If they're not returning data it's likely that the calcs are commented out: uncomment them and follow the instructions inside each calc to point it at the correct fields in your contact or project.

!! I seem to be losing my custom translations or CSS themes!

Your custom themes and translations can be overwritten if a "Restore" button is pressed from the "Under the Hood" layout, or if the CalendarInterface record is deleted. Because of this, you can add a custom menu with the "Records" menu removed, and apply it to the layouts based on the CalendarInterface table occurrence. This should prevent the CalendarInterface record from being unintentionally deleted. Also, save the text of your modified theme or translations in a text file outside of FileMaker for backup. That way, you can quickly restore your custom themes or translations in case they are overwritten by pasting them back into DayBack
.
January 25, 2016, at 03:32 AM by 192.88.134.15 -
Changed line 12 from:
-> '''Windows.''' We're looking for a comparable setting on Windows, but usually the first copy of FileMaker that is opened is the one that will open with an FMP url protocol. Close all copies of FMP and re-open the one you are running the calendar in. If that doesn't work then reinstalling FileMaker 13 should fix the issue.
to:
-> '''Windows.''' We're looking for a comparable setting on Windows, but usually the first copy of FileMaker that is opened is the one that will open with an FMP url protocol. Close all copies of FMP and re-open the one you are running the calendar in. If that doesn't work then reinstalling your latest copy of FileMaker should fix the issue.
January 11, 2016, at 05:05 PM by 192.88.134.15 -
Changed line 24 from:
-> '''3.''' Double check the calc fields you added to your events table, especially "DBk_WebViewerSource". If they begin /* then they're "commented out" and you need to remove the leading /* and trailing */ before the fields will work. If this is the case you'll likely need to replace our "sample" fields with your own once you remove these characters and try to save the field. If you're embedding the calendar, check the auto enter calc definitions as well, such as those for DateRangeStartAutoGlob and DateRangeEndAutoGlob.
to:
-> '''3.''' Double check the calc fields you added to your events table, especially "DBk_WebViewerSource". If they begin /* then they're "commented out" and you need to remove the leading /* and trailing */ before the fields will work. If this is the case you'll likely need to replace our "sample" fields with your own once you remove these characters and try to save the field.
Changed line 62 from:
Rarely, some months may appear to have all events missing, caused by a lone backslash "\" in one of your event records. If an event field ends in or contains only a backslash, remove this character or add another character after it.
to:
Rarely, some months may appear to have all events missing, caused by a lone backslash "\" in one of your event records. If an event field ends in or contains only a backslash, removing this character or adding another character after it will correct the issue.
December 27, 2015, at 03:49 PM by 192.88.134.15 -
Changed lines 60-64 from:
PatternCount (Get(ApplicationVersion); "Server")
to:
-> PatternCount (Get(ApplicationVersion); "Server")

!! Can't link contacts or projects

There are a couple of fields you need to add to your contact and project tables and it can be easy to overlook these--or the fields may be there but be commented out (that is, they may begin with /* and end with */). The fields are described [[LinkedContactsAndProjects | here]], please take a moment to make sure they're in your contact or project table and that they're returning data (ie add the fields to a layout and look at the fields in browse mode). If they're not returning data it's likely that the calcs are commented out: uncomment them and follow the instructions inside each calc to point it at the correct fields in your contact or project.
Changed line 12 from:
-> '''Windows.''' We're looking for a comparable setting on Windows, but reinstalling FileMaker 13 works.
to:
-> '''Windows.''' We're looking for a comparable setting on Windows, but usually the first copy of FileMaker that is opened is the one that will open with an FMP url protocol. Close all copies of FMP and re-open the one you are running the calendar in. If that doesn't work then reinstalling FileMaker 13 should fix the issue.
Changed line 7 from:
%center, width=300% https://www.seedcode.com/rootimages/stikipad/dayback/fmp-url-pref-pane.png
to:
%center% %width=440% https://www.seedcode.com/rootimages/stikipad/dayback/fmp-url-pref-pane.png
Changed lines 7-8 from:
%width=300%
https://www.seedcode.com/rootimages/stikipad/dayback/fmp-url-pref-pane.png
to:
%center, width=300% https://www.seedcode.com/rootimages/stikipad/dayback/fmp-url-pref-pane.png
Changed line 7 from:
%center, width=300%
to:
%width=300%
Changed line 7 from:
%center, width=400%
to:
%center, width=300%
Changed line 7 from:
%center width=400%
to:
%center, width=400%
Changed line 7 from:
%center% %width=500%
to:
%center width=400%
Changed line 7 from:
%center%
to:
%center% %width=500%
Changed line 51 from:
--> "Field Can't Be Modified." Make sure that all of the fields you mapped on the "Source No 1" layout are writable; that is, not calculation fields. If you are using a calc field for any of those fields, try changing it to a Text field, then set it up to auto-enter a calculated value instead.
to:
--> "Field Can't Be Modified." Make sure that all of the fields you mapped on the "Source No 1" layout are writable; that is, not calculation fields. If you are using a calc field for any of those fields, try changing it to a Text field, then set it up to auto-enter a calculated value instead. (The most common cause of 201 errors is mapping a calculated field to the event Summary. You'll want to make sure the field mapped there is editable.)
July 01, 2015, at 09:32 PM by 142.4.217.187 -
Changed lines 55-61 from:
If you've integrated DayBack 9.42 or earlier into your hosted solution, the problem may be due to the "global" storage setting on the "BuildNumberCalc" calculation field in the CalendarInterface table. Fortunately the fix is easy; simply remove the global storage option on that field.
to:
If you've integrated DayBack 9.42 or earlier into your hosted solution, the problem may be due to the "global" storage setting on the "BuildNumberCalc" calculation field in the CalendarInterface table. Fortunately the fix is easy; simply remove the global storage option on that field.

!! No events appearing on the calendar

If your file is set up to auto-enter an account that does not have access to the event data, and it is being hosted in FileMaker Server, and you are using PSOS, your users might not see any data on the DayBack UI. This is because when scripts run on the server they use the auto-login account to query the events table. The solution is to add a "Re-Login" step in your OnFirstWindowOpen script so PSOS will always use the Admin account. Wrap this in an If[] condition with the following formula:

PatternCount (Get(ApplicationVersion); "Server")
May 05, 2015, at 12:44 PM by 142.4.217.188 -
Changed line 55 from:
If you've integrated DayBack 9.42 or earlier into your hosted solution, the problem may be due to the "global" storage setting on the "BuildNumberCalc" calculation field in the CalendarInterface table. That causes a problem when DayBack is deployed within a hosted solution. Remove the global storage option on that field to fix the problem.
to:
If you've integrated DayBack 9.42 or earlier into your hosted solution, the problem may be due to the "global" storage setting on the "BuildNumberCalc" calculation field in the CalendarInterface table. Fortunately the fix is easy; simply remove the global storage option on that field.
May 05, 2015, at 12:26 PM by 142.4.217.188 -
Changed lines 51-55 from:
--> "Field Can't Be Modified." Make sure that all of the fields you mapped on the "Source No 1" layout are writable; that is, not calculation fields. If you are using a calc field for any of those fields, try changing it to a Text field, then set it up to auto-enter a calculated value instead.
to:
--> "Field Can't Be Modified." Make sure that all of the fields you mapped on the "Source No 1" layout are writable; that is, not calculation fields. If you are using a calc field for any of those fields, try changing it to a Text field, then set it up to auto-enter a calculated value instead.

!! Calendar not loading

If you've integrated DayBack 9.42 or earlier into your hosted solution, the problem may be due to the "global" storage setting on the "BuildNumberCalc" calculation field in the CalendarInterface table. That causes a problem when DayBack is deployed within a hosted solution. Remove the global storage option on that field to fix the problem
.
April 15, 2015, at 02:53 PM by 142.4.217.187 -
Changed line 37 from:
--> '''9.''' Try changing the BuildNumberCalc field in the CalendarInterface table from a global to an unstored calculation. This can help if you've integrated DayBack into your own file while your file was hosted in FileMaker Server.
to:
-> '''9.''' Try changing the BuildNumberCalc field in the CalendarInterface table from a global to an unstored calculation. This can help if you've integrated DayBack into your own file while your file was hosted in FileMaker Server.
April 15, 2015, at 02:53 PM by 142.4.217.187 -
Added lines 36-37:

--> '''9.''' Try changing the BuildNumberCalc field in the CalendarInterface table from a global to an unstored calculation. This can help if you've integrated DayBack into your own file while your file was hosted in FileMaker Server.
April 15, 2015, at 02:52 PM by 142.4.217.187 -
March 20, 2015, at 04:36 PM by 142.4.217.187 -
Changed line 5 from:
-> '''Mac.''' There is a free preference pane you can download that allows you to select which application is associated with a url protocol. In this case we are referring to the  "fmp" protocol. Just download and install [[https://www.rubicode.com/Software/RCDefaultApp/ | this preference pane]]. Then navigate to the "URL's" tab and find "fmp" in the list of protocols. From there you can choose the proper version of Filemaker you would like to open when that url protocol is invoked. Please note that this preference pane is not made by us, please use at your own risk. We have tested it on Macos X Yosemite and it worked great for us.
to:
-> '''Mac.''' There is a free preference pane you can download that allows you to select which application is associated with a url protocol. In this case we are referring to the  "fmp" protocol. Just download and install [[https://www.rubicode.com/Software/RCDefaultApp/ | this preference pane]] (once downloaded just double click to install it). Then navigate to the "URL's" tab and find "fmp" in the list of protocols. From there you can choose the proper version of Filemaker you would like to open when that url protocol is invoked. Please note that this preference pane is not made by us, please use at your own risk. We have tested it on Macos X Yosemite and it worked great for us. If you want to uninstall the preference pane when you are done you can just right click on it and there is an option to uninstall.
March 20, 2015, at 04:33 PM by 142.4.217.188 -
Changed lines 5-6 from:
-> '''Mac.''' There is a preference pane that allows you to select which application is associated with a url protocol. In this case we are referring to the  "fmp" protocol. Just download and install [[https://www.rubicode.com/Software/RCDefaultApp/ | this preference pane]]. Then navigate to the "URL's" tab and find "fmp" in the list of protocols. From there you can choose the proper version of Filemaker you would like to open when that url protocol is invoked. Please note that this preference pane is not made by us, please use at your own risk. We have tested it on Macos X Yosemite and it worked great for us.
to:
-> '''Mac.''' There is a free preference pane you can download that allows you to select which application is associated with a url protocol. In this case we are referring to the  "fmp" protocol. Just download and install [[https://www.rubicode.com/Software/RCDefaultApp/ | this preference pane]]. Then navigate to the "URL's" tab and find "fmp" in the list of protocols. From there you can choose the proper version of Filemaker you would like to open when that url protocol is invoked. Please note that this preference pane is not made by us, please use at your own risk. We have tested it on Macos X Yosemite and it worked great for us.
Changed line 11 from:
and you'll find an array called LSHandlers and a sub-array called LSHandlerURLScheme... In some cases you'll see that was pointing to fmp and not fmpa13. This doesn't appear to be in the same place for every version of MacOSX so if you can locate this file the preference pane mentioned above is the way to go.
to:
and you'll find an array called LSHandlers and a sub-array called LSHandlerURLScheme... In some cases you'll see that was pointing to fmp and not fmpa13. This doesn't appear to be in the same place for every version of MacOSX so if you can't locate this file the preference pane mentioned above is the way to go.
March 20, 2015, at 04:28 PM by 142.4.217.187 -
Changed lines 7-8 from:
%thumb%[[Attach:rootimages/stikipad/dayback/fmp-url-pref-pane.png | Attach:rootimages/stikipad/dayback/fmp-url-pref-pane.png"URL Protocol Preference Pane"]]
to:
%center% 
https
://www.seedcode.com/rootimages/stikipad/dayback/fmp-url-pref-pane.png
March 20, 2015, at 04:27 PM by 142.4.217.187 -
Changed lines 5-10 from:
[[https://www.rubicode.com/Software/RCDefaultApp/ | link]]

-> '''Mac.''' There is a preference pane that allows you to select which application is associated with a url protocol. In this case we are referring to the  "fmp" protocol. Just download and install
this preference pane. Then navigate to the "URL's" tab and find "fmp" in the list of protocols. From there you can choose the proper version of Filemaker you would like to open when that url protocol is invoked. Please note that this preference pane is not made by us, please use at your own risk. We have tested it on Macos X Yosemite and it worked great for us.

Open ~/Library/Preferences/com.apple.LaunchServices.plist \\
and you'll find an array called LSHandlers and a sub-array called LSHandlerURLScheme... In some cases you'll see that was pointing to fmp
and not fmpa13
to:
-> '''Mac.''' There is a preference pane that allows you to select which application is associated with a url protocol. In this case we are referring to the  "fmp" protocol. Just download and install [[https://www.rubicode.com/Software/RCDefaultApp/ | this preference pane]]. Then navigate to the "URL's" tab and find "fmp" in the list of protocols. From there you can choose the proper version of Filemaker you would like to open when that url protocol is invoked. Please note that this preference pane is not made by us, please use at your own risk. We have tested it on Macos X Yosemite and it worked great for us.

%thumb%[[Attach:rootimages/stikipad/dayback/fmp-url-pref-pane.png | Attach:rootimages/stikipad/dayback/fmp-url-pref-pane.png"URL Protocol Preference Pane"]]

-> As an alternative you may be able to modify the launch services plist file directly. Open ~/Library/Preferences/com.apple.LaunchServices.plist \\

and you'll find an array called LSHandlers and a sub-array called LSHandlerURLScheme... In some cases you'll see that was pointing to fmp and not fmpa13. This doesn't appear to be in the same place for every version of MacOSX so if you can locate this file the preference pane mentioned above is the way to go.
March 20, 2015, at 04:21 PM by 142.4.217.187 -
Changed lines 5-9 from:
-> '''Mac.''' Open ~/Library/Preferences/com.apple.LaunchServices.plist \\
to:
[[https://www.rubicode.com/Software/RCDefaultApp/ | link]]

-> '''Mac.''' There is a preference pane that allows you to select which application is associated with a url protocol. In this case we are referring to the  "fmp" protocol. Just download and install this preference pane. Then navigate to the "URL's" tab and find "fmp" in the list of protocols. From there you can choose the proper version of Filemaker you would like to open when that url protocol is invoked. Please note that this preference pane is not made by us, please use at your own risk. We have tested it on Macos X Yosemite and it worked great for us.

Open ~/Library/Preferences/com.apple.LaunchServices.plist \\
March 02, 2015, at 08:24 PM by 142.4.217.188 -
Changed line 20 from:
-> '''3.''' Double check the calc fields you added to your events table. If they begin /* then they're "commented out" and you need to remove the leading /* and trailing */ before the fields will work. If this is the case you'll likely need to replace our "sample" fields with your own once you remove these characters and try to save the field. If you're embedding the calendar, check the auto enter calc definitions as well, such as those for DateRangeStartAutoGlob and DateRangeEndAutoGlob.
to:
-> '''3.''' Double check the calc fields you added to your events table, especially "DBk_WebViewerSource". If they begin /* then they're "commented out" and you need to remove the leading /* and trailing */ before the fields will work. If this is the case you'll likely need to replace our "sample" fields with your own once you remove these characters and try to save the field. If you're embedding the calendar, check the auto enter calc definitions as well, such as those for DateRangeStartAutoGlob and DateRangeEndAutoGlob.
Changed lines 30-44 from:
-> '''8.''' Are you filtered and forgot? Click "reset filters" at the bottom of the Filters tab on the calendar's sidebar.
to:
-> '''8.''' Are you filtered and forgot? Click "reset filters" at the bottom of the Filters tab on the calendar's sidebar.

!! Errors when Editing Events

Some tips for errors you might see when dragging events around or editing them...

-> '''Error 102'''

-->102 means a "field is missing" so it sounds like DayBack is trying to write your event back to FileMaker but can't find one of the fields it needs. This is probably because one of the fields on the Source No X mapping layout got skipped or deleted.

--> I'd revisit that "Source No..." layout (probably "Source No 1" unless you're integrating additional sources) and check each tab to make sure the fields are mapped to fields in your table. If everything looks good you might then compare this layout with that in a fresh download of DayBack to make sure none of the fields were deleted from the layout. If they were, copy and paste the field from the clean copy and then point it at the relevant field in your table.

-> '''Error 201'''

--> "Field Can't Be Modified." Make sure that all of the fields you mapped on the "Source No 1" layout are writable; that is, not calculation fields. If you are using a calc field for any of those fields, try changing it to a Text field, then set it up to auto-enter a calculated value instead
.
December 17, 2014, at 12:16 AM by 98.203.211.206 -
Changed lines 16-28 from:
-> '''1.''' Run the "Upon Opening" script again.

-> '''2.''' Double check the calc fields you added to your events table. If they begin /* then they're "commented out" and you need to remove the leading /* and trailing */ before
the fields will work. If this is the case you'll likely need to replace our "sample" fields with your own once you remove these characters and try to save the field. If you're embedding the calendar, check the auto enter calc definitions as well, such as those for DateRangeStartAutoGlob and DateRangeEndAutoGlob.

-> '''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
.''' 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.

->
'''5.''' 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 [[MultipleSources | more than one source]]; if the sources are using different date and time fields they'll need different timestamp calcs.

-> '''6.''' A few things in
the calendar use cookies in order to work properly--things like remembering the sidebar's visibility setting for the current user. You may want to check that cookies aren't disabled in your default browser.

-> '''7.'''
Are you filtered and forgot? Click "reset filters" at the bottom of the Filters tab on the calendar's sidebar.
to:
-> '''1.''' Do you have any other versions of FileMaker open? The calendar utilizes the FMP url protocol. When multiple versions of FileMaker are open at once this protocol may target the wrong version and scripts will not fire in the version where the DayBack file is open. Just close the other open FileMaker apps and everything should work as expected.

-> '''2.''' Run the "Upon Opening" script again
.

->
'''3.''' Double check the calc fields you added to your events table. If they begin /* then they're "commented out" and you need to remove the leading /* and trailing */ before the fields will work. If this is the case you'll likely need to replace our "sample" fields with your own once you remove these characters and try to save the field. If you're embedding the calendar, check the auto enter calc definitions as well, such as those for DateRangeStartAutoGlob and DateRangeEndAutoGlob.

-> '''4.''' 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.)

->
'''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 [[MultipleSources | more than one source]]; if the sources are using different date and time fields they'll need different timestamp calcs.

-> '''7.''' A few things in the calendar use cookies in order to work properly--things like remembering the sidebar's visibility setting for the current user. You may want to check that cookies aren't disabled in your default browser.

-> '''8
.''' Are you filtered and forgot? Click "reset filters" at the bottom of the Filters tab on the calendar's sidebar.
Added lines 27-28:

-> '''7.''' Are you filtered and forgot? Click "reset filters" at the bottom of the Filters tab on the calendar's sidebar.
Changed line 1 from:
!! The Calendar Seems to be Opening an Old Copy of FileMaker
to:
!! The Calendar Seems to be Opening an Older Copy of FileMaker
Added lines 25-26:

-> '''6.''' A few things in the calendar use cookies in order to work properly--things like remembering the sidebar's visibility setting for the current user. You may want to check that cookies aren't disabled in your default browser.
Changed lines 10-11 from:
!! What's wrong?
to:
!! What's Wrong?
Changed lines 18-45 from:
-> '''2.''' 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". Also make sure the name of your file doesn't contain a period in the last 4 characters. More on these two issues here: [[YourFile | changes to your file]].

->''' 3.''' 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.

-> '''4.''' 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.)

-> '''5.''' 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.

-> '''6.''' 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.

-> '''7.''' 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 [[MultipleSources | more than one source]]; if the sources are using different date and time fields they'll need different timestamp calcs.

-> '''8.''' 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.


!! 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.

!! Events are appearing in the wrong place

This is usually caused by carriage returns or other uncommon characters in your data. The most common cause is a trailing carriage return in one of the fields used in your zscEventSummaryCalc field (most likely the Summary or Description field), or ANY carriage return in your Status field (the calendar does not support multiple values in the Status field).
to:
-> '''2.''' Double check the calc fields you added to your events table. If they begin /* then they're "commented out" and you need to remove the leading /* and trailing */ before the fields will work. If this is the case you'll likely need to replace our "sample" fields with your own once you remove these characters and try to save the field. If you're embedding the calendar, check the auto enter calc definitions as well, such as those for DateRangeStartAutoGlob and DateRangeEndAutoGlob.

-> '''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.''' 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.

-> '''5.''' 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 [[MultipleSources | more than one source]]; if the sources are using different date and time fields they'll need different timestamp calcs.
Changed line 6 from:
and you'll find an array called LSHandlers and a sub-array LSHandlerURLScheme... In some cases you'll see that was pointing to fmp and not fmpa13
to:
and you'll find an array called LSHandlers and a sub-array called LSHandlerURLScheme... In some cases you'll see that was pointing to fmp and not fmpa13
Changed line 5 from:
-> '''Mac.''' Open ~/Library/Preferences/com.apple.LaunchServices.plist
to:
-> '''Mac.''' Open ~/Library/Preferences/com.apple.LaunchServices.plist \\
Added lines 1-9:
!! The Calendar Seems to be Opening an Old Copy of FileMaker

The calendar uses the fmp:/url protocol to call scripts in your file. Some folks computers can get confused as to which copy of FileMaker to use in responding to these url calls. Fortunately this is pretty easy to fix.

-> '''Mac.''' Open ~/Library/Preferences/com.apple.LaunchServices.plist
and you'll find an array called LSHandlers and a sub-array LSHandlerURLScheme... In some cases you'll see that was pointing to fmp and not fmpa13

-> '''Windows.''' We're looking for a comparable setting on Windows, but reinstalling FileMaker 13 works.

March 06, 2014, at 08:21 PM by 75.70.205.184 -
Changed lines 32-36 from:
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.
to:
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.

!! Events are appearing in the wrong place

This is usually caused by carriage returns or other uncommon characters in your data. The most common cause is a trailing carriage return in one of the fields used in your zscEventSummaryCalc field (most likely the Summary or Description field), or ANY carriage return in your Status field (the calendar does not support multiple values in the Status field)
.
(855) SEEDCODE
[email protected]
Follow us: