I locked the sidebar and hide it from my client. He sent me a screen shot of the sidebar open. I had him quit and open it again. Same issue. I had him reboot his computer and again same issue. I have same OS and FM version as him (High Sierra and FM 18.3 - Dayback 10.60) and I can't repeat what he's seeing. The sidebar is locked and the script looks fine. It's like his Settings script isn't changing any variables.

Also I just noticed that his CSS file that I customized has vanished and the .js translator file was set back to default. I have no idea how he did this since he is not setup as [Full Access].

Any ideas?

Hi Jim,

Thanks for the details on what you're seeing. As far as the sidebar goes, it's likely that the $$sc_ClearUserSettings variable near line 79 in the "Load Calendar Settings - On Startup..." script is set to False. If this is set to False, then the user's settings will be restored from the browser cookies, rather than overwritten by this script. Changing it to True should fix the issue. If it's already set to True, let me know and we can troubleshoot further.

As to how the sidebar was opened in the first place, as well as the CSS and translations being reset, this likely happened because the "Calendar Interface" record was accidentally deleted. Details on why this happens and how to prevent it using a custom menu set can be found in the docs here: https://www.seedcode.com/pmwiki/index.p ... ooting#CSS

Let me know if that helps!

KC

Hi KC, Yes it was set to False and I sent it again to True but I guess the cache is still causing this issue. So I guess the solution would be to clear the safari cache?

One other thing (may or may not relate but happened at the same time) is that I have several scripts that call a new window on top of the calendar with a specified layout (very simple layout with just fields on it. It seems that the Calendar layout just appears in this window (for some reason) and the rest of the script stops working. This is under FM18 and Mojave. I've been trying to reproduce this but since I have nothing here with Mojave on it, it's a bit of a challenge. I've attached a picture so you can see what I mean.

I think you are correct in that the Calendar Interface record got deleted. I set their login account to be unable to delete records in this file. Hopefully that will stop it. I will get them to clear their safari caches and start dayback again.

Hi Jim,

Thank you for the details. With FileMaker 18 you can specify the layout the new window should land on, by default, it will be the current layout that will attempt to launch DayBack's opening routine, so specifying the specific layout in the new window script step should fix that issue.

You can get some hinky behavior with no record or changing records with the web viewer, so preventing deletion and creation of that interface record is a good idea.

Let me know if that helps,
-Jason

I did set the "new window" to have a specific layout, but it seems to be ignored. I will let you know if I can work out what's going on with my client. They are on Mojave apparently but I don't see how that would be an issue with FM18.

Hmm. I haven't seen that fail before, maybe some kind of trigger (on window open) that's redirecting it back to the DayBack layout? The debugger should show that. As I mentioned in the other thread, we may have to have a look at the file directly to see if we can tell what's going on. Drop a note to [email protected] and KC will make arrangements.

My best,
Jason

I prevented my client from deleting the CalendarInterface record but today he reports that the sidebar is open again and no amount of cache clearing and restarts will close it again. I logged in and checked that the customized css and .js files were still in place in the "Under the Hood" layout. All seems fine and I don't see how this sidebar could have slid open. I've triple-checked the startup script. I wonder if dayback is calling up old exported files from the temp folder. So far no one else has reported this issue in his office.

Hi Jim,

10.60 uses the new version-specific FMP URL protocol. But, if the 10.50 updates were applied to the file using a version of FileMaker earlier than 16, the "Create Folders" option on line 18 of the "Set Temp Path Folder" script will be set to Off. If that's the case, then yes, a cached version of the exported temporary files in the root directory would be used. You can fix this by opening the script in FileMaker 17+ and toggling that option to On.

If that's not what you're seeing, and the "$$sc_ClearUserSettings" option is set to True in the load calendar settings script, then we'll need to dive in a bit more to troubleshoot. I'd be happy to take a look at a copy of the files if you can reach out directly to [email protected]

Regards,

KC

Thanks KC. It turns out that he was running an older version of dayback earlier today (in order to take some screenshots) and that version may have caused this issues (I guess).

I checked the scripts you mentioned and they all look correct.