Popovers are one of my favorite things in FileMaker 13. Like tab panels and slide controls they’re a region within a layout, but unlike our other enclosures they don’t take up any space when they’re not in use. We love them. But they have a couple of unexpected behaviors you’ll want to be aware of as you start putting popovers to work.
FileMaker 13 Popover Bugs
Issue in Web Direct: Portal buttons fail in all but the first row. The only real show stopper with popovers is when a portal is used inside a popover in Web Direct. In such portals, buttons within the portal row will always act as if they are on the first portal row. This means that if you have a portal based selector inside a popover, users on Web Direct will only be to select items in the first row. You can see this in action in FileMaker’s own “Invoices” starter solution. Popover base selectors like the one adding a company or an item to an invoice always select the first row’s item in Web Direct. Thank you, Jason Young, for catching this!
Work around. I can’t imagine FileMaker won’t fix this soon in a v-rev. Until then, you can fake a button by using a field in the portal row and adding an OnObjectEnter script trigger to act as the button. Because you’re “in” the row’s record when the script fires, these fields-as-buttons work in the correct row, not just the first row.
Update: fixed in 13v2
Issue: Objects prohibited in portals are prohibited in popovers placed inside of portals. This isn’t a bug, but just isn’t obvious at first and caught us off guard when we first starting using popovers in earnest. If you place a popover inside a portal row, the objects in the popover have to obey the same rules as any objects inside a portal row. This means that since you can’t put tabs inside a portal row… you can’t put them in a popover that itself is inside a portal row. The reason this catches people is that FileMaker won’t bark at you when you try to do this. Depending on the object you try to add to a portal-enclosed popover, the action in layout mode will either look like it succeeds or the added object will “fall through” the popover to the layout below.
Work around. None. This is just a fact of life. Just as you can’t include a portal inside another portal, you can’t include a portal in a popover that’s inside another portal.
Issue: Expanding popovers won’t cover webviewers. Nothing can really cover a webviewer and that goes for the expanded contents of a popover as well. The popover will try to expand elsewhere on the screen but if there is nowhere else to go you may find part of it underneath your webviewer. Kind of hard to use that way. =)
Work around. Fortunately, you can use FileMaker 13’s new “hide object when” attribute to hide the webviewer as the popover opens. Attach a script trigger to the popover upon OnObjectEnter (setting a variable like $$Hide_Webviewer to 1) and OnObjectExit (clearing $$Hide_Webviewer). Then use the “hide object when” attribute to hide the webviewer in question when $$Hide_Webviewer is set to 1. Note that you’ll need to refresh the window, or refresh the webviewer object, as soon as you edit the $$Hide… variable to see the change take effect. This work around will let the popover appear without going beneath the webviewer (which is now hidden) but since the webviewer was on screen when the popover began to draw, the popover will still render in a different place on the screen if that is what the webviewer’s presence caused it to do. So think of this work around as getting the webviewer to stop appearing infront of the popover, not as preventing the webviewer from effecting the popover at all.
Issue: It can be hard to make a popover open only in some cases. The triggers you’d think work for this (OnObjectEnter / Modify) don’t fire until the popover is already open. So while these can then close the popover, they can’t prevent it from opening. (And while this close can happen very fast in Pro–maybe unnoticeably fast–that is not the case in Web Direct.)
Workaround: Use FM13’s new “hide object when” on the entire popover (not the popover button) instead. Works great in both Pro and Web Direct. As an added bonus, the OnObjectEnter script trigger still fires if the pop-over is hidden, so you can run a script as an alternative to launching the pop-over all from the same button without having to name any objects.
Issue: There is no native function to tell if a popover is currently showing. If your scripts want to know if a user currently has a popover on screen, things like IsFrontTabPanel don’t apply.
Test any object (by object name) within the popover for the value of it’s top: GetLayoutObjectAttribute(“YourObjectName”,”top”) That will only have a value if the popover is visible. Wish that worked; the “top” value actually persists once the popover has been shown once, regardless of it being visible currently.