...Send as Snapshot Link script step...
The problem I'm running into is with the Status Bar. When non-full-access users log into the solution, the Status Bar is locked off. All navigation, etc is done through scripted buttons. So I get an error when testing the opening of the Snapshot Link which says I have to have at least one window with the status bar unlocked.
How do I avoid this?
I have used Snapshot links, but not encountered the error you have. I am guessing a bit here, but it is my understanding that these links store all info such as layout, found record(s) and so on. What if you go to the desired layout with the menu bar not showing, locked, etc., and then generate the link? My thought is that the link will have these attributes and therefore not generate an error when the restricted staff use it.
Doug de Stwolinska
Thanks, Doug. I have tried to do that - tried to replicate the exact scenario. So when a record is "approved" and needs "special approval", the link is generated right there by the user. So that user has status bar hidden and locked, which is exactly how it would be when the approver logs in.
I get the impression by the context that the SnapShot link needs access to the status area for one of the features there - record navigation or something similar.
OR - could it have to do with the fact that I use Custom Menus? The same custom menu would be there before and after the snapshot link is created, so there are no differences - but I wonder if Snapshot Link needs our regular menu?
In a related issue, another FileMaker Developer in the company used a Snapshot Link to our Main Menu as the "shortcut" on XenWeb (used for remote access). The same error (need access to Status Toolbar) has been reported here. The issue occurs on Macs and Windows (it's a cross-platform environment).
The database opens as it usually would, doing opening routines, lands on the Main Menu as the user normally would, then the snapshot attempts to initiate. That's when THIS exact error occurs: "Cannot restore the snapshot llink file "file.fpsl". Make sure that the status toolbar is accessible in at least one window of the referenced database."
At worst, I may do this: I'll set the status toolbar to unlocked upon open, but hidden. And since they have to access the Main Menu to do anything else, I'll make that script lock the toolbar. That way this snapshot link can at least "get in the door".
Sounds logical to me. After I posted, I looked at the instance where I was using the Snapshot link and was mistaken in that the menu bar is actually showing. As to why Snapshot wants an unlocked menu bar, sounds like something best answered by FMI. I may have a similar use to yours for Snapshot in the near future, and would definitely want the menu bar closed. Your discovery will save me some aggravation for sure.
1 of 1 people found this helpful
UPDATE: As a work-around, I've hidden the status toolbar upon open, but didn't LOCK it. I then added script steps to the scripts that are accessible from the Main Menu, and removed access to any layouts via the Status area. I then didn't even have to resend the snapshot link - simply opened the one I had created earlier and it worked fine. I'll use this unless somebody knows of a way that I can leave the status toolbar locked in the hidden mode.
can you explain your workaround a little more to me? I definitely do not want users having access to staus area. I have found locking is the only way to keep them out. Thanks!
I then added script steps to the scripts that are accessible from the Main Menu,
I believe (though I could well be wrong) that you get this message only if your snapshot link was created with an unlocked status area. Since one of the things the snapshot holds is the status toolbar status, it's going to try to restore that unlocked status area. If the user opening doesn't have any windows with an unlocked status area, the snapshot won't open, since that would expose the status area to someone who's apparently not supposed to have it.
Is this what's happening? If you open your snapshot link in a browser, you should be able to pretty easily see the toolbar status that's being saved.
I actually may have something to add to this conversation.
It has helped me a bunch to read through this, having never actually done much with snapshot links until now, and now I have an interesting (to me) tidbit:
If you use PSoS to generate your link, and all your users have their status toolbar locked out it will fail for them. BUT, the Hide Toolbars command is actually server compatible (who'd have ever thought that?) and can enable you to create snapshot links that work for those locked out users.
I have now come across this issue for an app where toolbars are hidden/locked. I hid/locked them for myself, saved a snapshot link and can't even open the snapshot I created. Major bummer. I love the concept of sending snapshot links to users, but I don't want to unlock the toolbar!
Having the same problem. Here is my work-around.
My original start-up script had the Hide/Lock step, hence the error with the snapshot link.
So, I added some new script steps as part of the start-up. Basically, open a new window to a blank layout, set that Window's Status Area to Show and hide this new Window, then select the Window that you want your users to land on (you will need to have named this Window). The start up script still contains the Hide/Lock step and the Status Area is locked in all the layouts exactly as previously, but as I now have one window open with the Status Area showing, the Snapshot Link now works
As a bit of a bonus, I am using Custom Menus that do not allow the 'Show Window' option, so they cannot accidently view the hidden Window.
Not sure it will be right for everyone but works for me. See below.