SeedCode Support Forum

Please back up your file before making any changes.

If you haven't already, navigate to the "Settings" tab in the calendar sidebar and click "Account Settings". Click "Check For Updates". This button should change to "Install Update" and inform you that version 10.20 is available. Click "Install Update".

To update the necessary scripts, begin by downloading the latest version of DayBack here:

You should follow these instructions if you have done the embedded integration or the linking integration and you don't want to perform the integration all over again.

The Changes

Update the following script in your current DayBack File (Your file if you have done an embedded integration), but don't delete the script itself. Rather, use the "Select All" command to select and delete the entire contents of each script, then copy/paste the updated contents of the script from the new version of DayBack into the corresponding script in your DayBack file. You may get an error when opening both files at the same time. This is expected and you can just say "OK" to those errors before continuing. Here is the script that needs to be updated this way:

"Refresh Calendar"

Finishing Up:
Close the new DayBack file you used to copy the script contents from.
Change the build number recorded in the database. Navigate to "File -> Manage -> Database" then go to the "CalendarInterface" table. Change the "BuildNumberCalc" calculation to read "10.20". Click "OK" to save those changes.

Then please run the "Upon Opening" script in your file. This will ensure all of the new settings load properly and the calendar loads with the correct data.

That's it, enjoy DayBack 10.20.

Hi,

Thanks for the ability to set the number of columns and days in the resource view, as it was one of our requested enhancements.

Currently the implementation to change the settings is by calling the "Refresh Calendar" script where there is now support for setting sc_ResourceColumns and sc_ResourceDays.

I'm wondering if there should also be support for these new settings in the "Set Webviewer ({Message})" script as well since they both previously supported the same settings, but now only Refresh Calendar supports sc_ResourceColumns and sc_ResourceDays.

Thanks!
Trevor

Hi Trevor,

The "Set Webviewer ({Message})" script only accepts a $sc_Message parameter and is meant to load the calendar to the default view. It wasn't really intended to be used much as a user-facing script. The "Refresh Calendar" script actually sets the WebViewer and queries the data again, but without the steps that are only necessary when first navigating to the Calendar layout.

Is there a specific reason you're needing to use the "Set Webviewer ({Message})" script instead?

Thanks,

KC

Hi KC,

In our implementation, we have many cases where we wish to navigate to specific views / dates. Our calendar is typically already open (we implemented it in a separate window from the main app). Therefore, per the documentation (https://www.seedcode.com/pmwiki/index.php?n=DayBackForFileMaker.Navigation) we set the global variables and call the set webviewer script.

Since we use that method throughout, it makes sense that there should also be support for $$sc_ResourceColumns and $$sc_ResourceDays global variables in the set webviewer script.

Hi Trevor,

Thanks for the info and pointing out the reference in the documentation.

Since the "Refresh Calendar" script accepts all those variables as parameters, the best way to navigate the calendar with a script would be to use a Perform Script step running "Refresh Calendar" with something like this in the optional script parameter:

#("sc_Mode" ; "Resource Vert") & #("sc_FocusDate" ; Get ( CurrentDate ) - 30 ) & #("sc_ResourceDays" ; 7) & #("sc_ResourceColumns" ; 2 )

That will refresh the calendar in the Resource List view, set the date to 30 days in the past, the resource days to 7, and the resource columns to 2. This will also be a bit quicker than running the "Set Webviewer ({Message})" script.

I'll get the documentation updated to reflect this. Let me know if that helps!

Thanks,

KC

Thanks KC. That works perfectly. It's also cleaner to pass the parameters directly to the Refresh Calendar script rather than setting global vars and calling the Set Webviewer script which will then use those globals vars.

All good. Thanks again!

Thanks for the confirmation, Trevor.

Great to hear that worked for you! I've updated the docs as, you're right, this is a much quicker and cleaner way to navigate the calendar.

Regards,

KC

trevor.gildersleeve wrote:Hi KC,

In our implementation, we have many cases where we wish to navigate to specific views / dates. Our calendar is typically already open (we implemented it in a separate window from the main app). Therefore, per the documentation (https://www.seedcode.com/pmwiki/index.php?n=DayBackForFileMaker.Navigation) we set the global variables and call the set webviewer script.

Since we use that method throughout, it makes sense that there should also be support for $$sc_ResourceColumns and $$sc_ResourceDays global variables in the set webviewer script.

Trevor would you share a bit about how are you dealing with a constantly open calendar and refreshing a calendar data?
I have developed auto refresh feature ( available somewhere here on this forum ). However it is still not perfect for us.
The screen will still flash when the refresh is required and the whole filemaker is affected. It gets annoying to a point when people are complaining and trying to tell me google calendar ( the free version ) was much better because it does not flash on refresh and has a feature to invite and receive back the meeting auto confirmation from invitees.
Any advice?

We'd love to hear more about it too!!

Hi!

I'll have to get back to you both on our implementation details to support a smooth working calendar in a separate window. It is possible and works great now. Our customer loves it!

Hi boore and Jason,

This isn't going to be an exhaustive write up of how we're dealing with the calendar in a separate window, but hopefully is detailed enough to get the gist. If not, please let me know and I'll dig deeper into details.

Before discussing changes, let me preface this post by saying that we modified the Seedcode scripts at will. We knew we were introducing work to ourselves when a DayBack update comes out that requires script changes, but we decided we're okay with that and will deal with them as they come. So far nothing big has come along to cause us to rethink that decision.

One of the first things we did was to create a script that manages the separate calendar window. Basically, it's called ahead of any script that needs access to the calendar. That script either creates the calendar window if it's not open already, or simply selects it/makes it active.

We call that script in

Code: Select all

Go To Event Record From WebViewer

and

Code: Select all

Go To Related Record From WebViewer

and anywhere else that we perform actions on the calendar directly.

Then we also have a script that works the other direction in that anytime the calendar is navigating to an application record, we then select the application window first and then navigate/find, etc.. so the calendar doesn't get disturbed.

As for flashing on refresh, one thing we do is to essentially defer the refresh at the very end of all processing using an OnTimer script. It doesn't "flash" persay, but it does reload the events. We initially had bad performance when we display a lot of events, but found we actually had the wrong context in a find buried in one of our customizations and it was killing performance. Once that was found and fixed all the events (we have 5 tables of different types of events) load quick.

Other than that... we're not really doing anything super fancy. We do try to use the "Refresh Calendar Event" script if we're just operating on 1 event and don't need to refresh the entire calendar. That works well because the entire calendar does not need to redraw.

Not sure if that helps much, but it has taken us quite a bit of time to get it working smoothly. The time spent comes from trying to be smart about when and how we refresh or modify events, putting .2-.5 second pauses at times to make sure the calendar is "ready" to do what we're asking it.

I'd be happy to answer specific questions.

Jason, we'd love to demo our solution to the team. We're pretty proud of it. You should see our implementation of calculating travel time to/from service locations and how travel is represented on the calendar. The coolest thing of all is that it's all dynamic when events get dragged around.

Thanks for the details, Trevor. Jason's out at a conference this week but we'd love to set up a screenshare / demo when he's back. I'll reach out next week and see if we can set something up. Thanks again!