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

Selecting a customer in a popover. From the “invoices” starter solution.

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 “Ivoices” 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 in a v-rev fairly soon. 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.

“Interesting Behaviors”

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.

The post FileMaker 13 Popover Bugs & Interesting Behaviors appeared first on SeedCode.