SeedCode Support Forum

Hi,

We recently upgraded all our Macs to FileMaker Pro 16 in order to resolve an esoteric portal bug. Since then, DayBack has been inconsistently loading the wrong number of resource columns, even though the $$sc_ResourceColumns global is set correctly.

The background is that we have 1 DayBack file with 4 sources. When users enter DayBack, they select a location and based on that, the correct Resource list is loaded, the appropriate # of ResourceColumns are set and DayBack loads in ResourceSchedVert mode, 1 day only.

The problem is that, since upgrading to FMP16, when users switch to a different location, even though $$sc_ResourceColumns loads the correct # of columns, they only see the # from before they switched, and the # of resources in the Resources pulldown menu shows the old number.

In the attached image, this location has 23 columns, and $$sc_ResourceColumns value is indeed 23, but '6' shows up in the pulldown menu, and indeed only 6 columns are shown - that was the #of columns from before they switched. Users either have to page through 4 pages of resources, or manually-select '23'.

Was there an easier way to describe this issue? Probably, but I haven't had much sleep. Sorry.

Eugene

Thanks for the screenshot, Eugene! I like that mod of changing the # of resources based on location; nice one.

I'm not completely sure what's going on with the number of resources lagging behind your change; can you let me know which version of DayBack you're on?

- John

Hey John,

On 10.54 right now. BTW, when I run it on FMS18 using FMP18, I get the FMPURL error dialog, nothing loads, despite playing around with the Check FMP URL scripting interval timing. Right now, it only works on FMP16.

Even then, when the 'Town' location loads (23 columns) I can only see events if I manually click the 'Refresh' button in the header...

Tragic.

If you're curious, this is how we interactively determine the column count:



...the value lists represent the therapists who are flagged as 'on the calendar' in their respective locations. This way, they can add or remove therapists from the schedule without having to reconfigure the calendar. the '$$jvd_CalendarSelection' global variable is what we set when they enter the calendar, or switch to a different location.

Hi Eugene,

As far as the FMP Protocol error goes, you'll need to either manually assign the FMP URL protocol to FileMaker 18 on your machine, or update your calendar to 10.55 and make sure you've applied all of the required script updates to take advantage of the version-specific FMP URL protocol feature added in FileMaker 18. One important thing noted in the 10.50 script updates is that you need to use FileMaker 17+ to copy over the "Set Temp Path Folder" script or it will break the calendar for FileMaker 18+. This is because the "Create folders" option of the "Export Field Contents" script step doesn't exist in earlier versions of FileMaker. To see if this is the issue with FMP18 and fix it, open the "Set Temp Path Folder" script in FileMaker 18 and verify that the "Create folders" option on line 18 is toggled to "On".

As far as the resource columns refreshing goes, changing the "$$sc_ResourceColumns" variable only has an effect when the calendar is first loaded using the "Upon Opening" script. To change the resource columns after the calendar is loaded, you'll need to perform the "Refresh Calendar" script and pass the parameter "sc_resourceColumns" as the number of columns you'd like to change to. You can see all the optional parameters and an example of how to refresh the calendar this way in our docs here: https://www.seedcode.com/pmwiki/index.p ... shCalendar

Let me know if that helps!

KC

Thanks KC,

I did as you suggested, but am still having inconsistent columns # mismatch, mostly when switching from a location with fewer columns than the one switching into. The switch script I've created calls 'Upon Opening' at the end but I put the 'Refresh Calendar' script afterward - even though this seems redundant - and passed the parameters as suggested. I think there's something else going on, but it's hard to track. Would it be possible to schedule a screen share so I can show you?

Eugene

Hi Eugene,

If you are running the "Upon Opening" script everytime, then you shouldn't need to run the "Refresh Calendar" script. In fact, running two scripts that refresh the calendar one after another can make the calendar behave weird.

I'll reach out to you by email so we can set up some time to dive into your file.

Regards,

KC