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.
[ba-box background=”#778899″ border=”#708090″ textcolor=”#F7F7F7″][jetpack_subscription_form][/ba-box]
Hi, I have grouped a set of records into a portal, each row has a pop-over button put it is too slow when i try to open it, does anyone know the reason of this behavior? how can i solve it?
Hey George, The slowness is probably just because the popover contents are “heavy”, so I’d try removing unstored fields, big graphics, etc to thin it down. There are, however, two interesting behaviors about popovers in portals that may make you want to move this to a card window instead (the following applies to FM16+):
– A popover called from a portal row is “drawn” twice. That is, its contents are evaluated twice, whereas a popover on a body part has its contents evaluated just once. To see this in action, add a new object to your popover with the following conditional formatting: Let ( [
$$x = $$x + 1 ] ; “nothing” ) In the data viewer you’ll see that $$x gets incremented twice each time you click on the popover. So a heavy popover may feel twice as heavy when called from a portal row. (A card window will just evaluate its contents once.)
– Values revealed in popovers-from-portal-rows aren’t cached the same way that they are when the popover is on a body part. To see this in action, take this same popover off your portal row and place it on the body. Now click on the popover from the body and you’ll see $$x increment just once: and it will increment just once no matter how many times you click on it until you change records. When it’s in the portal row it increments every time, as if FileMaker doesn’t know you’re clicking on the same record. (Card windows are the same, btw, they evaluate afresh each time they’re called, even if its the same record.)
Hope that helps.
Has anyone seen an issue in IE 11 where the Pop over is transparent? Showing the layout under it, witht he fields stacked on top?
I have a work around for obtaining a popovers status (ON or OFF).
Set up script PopOver which sets the variable [ $$PopOverState ; Value:Get(ScriptParameter)]
The below 2 set up on the actual popover window itself.
Set up script trigger OnObjectEnter with script PopOver, and scrip parameter ON.
Set up script trigger OnObjectExit with script PopOver, and scrip parameter OFF.
Not sure if this is a bug or expected behavior… but I have a pop over used to preview a web link…. so webviewer in a pop over. If that web page has video content (for example a youtube link), collapsing the popover does not stop the playback of the popover content.
The work around is to add a second weblink field that the web viewer renders from, and populate it with your link when you open the popover, and then clear it when you close the popover, forcing the webviewer to reload a blank page…. PITA but it work
Great post, but I am rather taken aback with the unsquashed bugs here. Filemaker should step it up, it’s been a few months since 13 is out.
Anyway. I might be wrong because I have not fully tested/debugged this behaviour but it seems I can’t put a pop over inside a pop over and have it work (as in a submenu). Can someone else verify this pleas?
I reported a WebDirect Popover bug that may be related in some way to those described here, but I haven’t seen it discussed specifically. The report is at: http://forums.filemaker.com/posts/14456804df. And, on TechNet at: https://fmdev.filemaker.com/message/140639#140639
From the issue report:
On Client #1 (WebDirect):
Starting from a list layout run a script to GTRR, Show only related records, Current record only.
Land on a layout showing a list of several related records. Show some fields for one of the records on a Popover. (I have a button in the list that loads detail fields.)
Now, on Client #2 (any type):
Make any change, by any means, on any layout to the record showing in the Popover on WebDirect Client #1.
Back to Client #1:
The record in the popover will update, showing data from the wrong record. It will be data from the last record of the found set.
Issue occurs only if Client #1 is a WebDirect client.
Initially, I thought this issue occurred only when Client #1 uses GTRR to get to the list. After attempting to workaround by scripting a Find and Go to Layout, discovered that the issue is not specific to the GTRR – it occurs in both cases.
Many thanks for posting this, as you saved me hours of aggravation yesterday. I created a popover button in a portal row, and wanted to put a slide panel on the popover. I intended to conditionally show a specific panel based on portal row data (a project phase type). Well, despite grouping, manic arranging…the slide panel “dropped through” the popover. And then…the light bulb went off and I remembered this blog post.
My workaround may be putting the popover outside the portal. Not sure yet.
Barbara, move the popover button outside of the portal. Then add the slide control to the popover. When you move it back to the portal, the slide control should work.
After testing this a little more, it works but only for the first row in the portal. The other portal rows do not show the popover button.
Same here, as Roy Gordon’s saying. For some reason the pop over doesn’t carry on to the rest of the portal rows other than the first one, which is the standard behaviour. This is a bug that has to be fixed.
Yes, great article and I stumbled on this like many others. Before I realized I could ‘create’ the popover inside a portal, I thought it didn’t work no matter what. After I learned it could, I immediately went for my initial feature of having a portal inside the popover – per parent portal row… my workaround was this. works great, but requires user to select the portal they wish to edit… https://twitter.com/gearboxatl/status/469500279118135296
Oh well. Thanks for testing. I’ll find a place for the popover.
It is also not possible to add or modify a portal row using po in Web direct. Field entries are reverted on leaving the field. I have reported it as a bug here http://forums.filemaker.com/posts/5b5fecbbf7?commentId=270197#270197
I’m really hoping for a fix since I am working on a solution entirely based on webdirect. Or maybe someone knows a workaround?
Posted incorrect URL. Bug reported here : http://forums.filemaker.com/posts/6953ee93be
Perhaps someone has the answer to another PO problem that feels like a bug: trying to intercept a PO before it displays. In a list view, if I attach an OnEnter script to a PO, where the script reads:
Show Explanatory Message
…the PO still renders on the desktop as a brief flash in the background. On WD, however, it opens and stays open. The button inside it, whose script step is Close Popover, fails (and it’s tough troubleshooting a WD-only failure where no script is running). The only way to close the hung PO is to open one on a row where the test fails.
Kludgy workaround: reduce PO to 1 point and put a real button next to it. The script on that button:
Go to Field [field inside the PO]
…which is a drag because GoToField does not take indirection, so you have to build a separate script for every single popover. It also feels like a Filemaker 5 solution.
We did find a solution for this. You can actually hide the pop-over object itself based on some condition and it basically just looks like it didn’t fire. The bonus is, that the OnObjectEnter script trigger does fire, so you can then run your explanatory message.
Did anyone manage to succesfully set a script trigger on a popover? I want a script to be triggered when the popover opens, but whatever event i try, nothing triggers my script.
We’re having success using an OnObjectEnter trigger on the popover panel itself (not on the popover button). Hope that helps, Dylan.
Putting the trigger on the panel itself still doesn’t seem to solve the problem I describe elsewhere– intercepting the PO opening. If the test within the script branches to closing the PO, that works nicely on the desktop, but in WD the PO just hangs, with no way to close it other than opening another, valid, PO.
You can make scrollable checkboxes. Make a pop over 100 by 100. Then put your checkboxes in side. Make it fit in the popover. Then AFTER stretch it out to a large size.
When you open in browse mode is should scroll.
Thanks for this list. Working with a new version is always a bit tricky, trying to find out what doesn’t work but is expected behavior and what doesn’t work because it might be a bug.
Regarding the portal inside a portal, I’ve created a workaround that may be of interest: http://youtu.be/R68-iFy1g-o
Hi, I found a slight work around. You can show a portal in a portal if you place the send portal in a pop over that is not connected to a row. You will need to use a script trigger to set a global of some type to show the related portal. So clicking a button in a portal row selected the portal row, sets a global and then opens a popover and shows the related data thru the Global relationship. Visually it sort of works since the popovers may not be over the row any way.
Thanks, John. Great article! I’ve been playing with popovers and slide controls quite a bit in the preview release, and looking at the way these can be combined for interesting UIs.
Early on, I came across the limitation you mention that you can’t place a portal in a popover whose button is itself in a portal, nor can you nest a popover in another popover. In that former case, that would violate the long-standing inability to nest portals within portals, which is probably a deep-seated technical limitation, dating, as it does, back to the earliest days of portals in FileMaker. It was worth trying, but the result (in retrospect) was inevitable.
On the subject of popovers, Apple’s iOS Human Interface Guidelines document (https://developer.apple.com/library/ios/documentation/userexperience/conceptual/mobilehig/ContentViews.html) has some great “dos and don’ts” tips for using popovers.
OTOH, you can nest panel controls (including the new slide-panel control) inside popovers, and inside each other arbitrarily deep. You can also nest portals inside popovers or inside panel controls of either type. Slide controls are going to prove particularly powereful! For example, by removing the navigation dots and using script triggers to navigate between panels, you could show/hide entierly different sets of fields and controls depending on, say, a particular field’s value, much more easily and elegantly than the pre-13-think “hidden tab panel” tricks.
Putting it all together . . . you could, for example, use a slide-panel control in just that manner, place a popover button (or any number of them, independently) on any panel, put another slide-panel control on the popover, and then a different filtered portal on each of the panels in that control, etc. Lots of possibilities here!
Now, just because you can, doesn’t (necessarily) mean you should. It all needs to make sense to the user, of course. And if the layout is going to have to transit over the WAN, in WebDirect, for example, then keeping it lean may be a higher priority.
Keep the great articles coming!
I haven’t tested Web Direct yet, but in FMP13 I’ve found that popovers don’t work in portals after the first row.
I’d hoped to use popovers to create a “Quick View” type UI for the related data, that a user would use before doing a Go To Related Record, but popover buttons don’t appear in subsequent portal rows. I’m going to test further and blog about it later – http://stuchburyconsulting.com/blog
Hi Dan, In my experience they work just fine in portal rows. I believe what you’re seeing is FileMaker treating the popover as if it’s outside the portal. When I’ve had trouble getting them in there it’s because FMP is now very picky about what constitutes “enclosure”. In FM11 an object was enclosed in a portal row if the upper left px of the object was inside the first row. In 12 and 13 it’s not enough for an object’s pixels to be in the portal row, and the most reliable way to make sure an object is enclosed is to *create* it enclosed rather than to create it elsewhere and move it o reduce it into an enclosed position. Try creating a new small popover by drawing it in your portal row: I think you’ll find it works in all rows, not just the first. HTH.
I concur, initially I had a problem with a popover in a portal, and used a script to set a global variable to the UID of the portal row and have the popover show the selection. I found that merge fields didn’t display but fields did (index missing!).
Thought I had remembered in a demo seeing popups working in a portal so created a new button in the rowans it worked in the context of that row.
That’s interesting, maybe I’m not being careful enough with positioning.
I’ll have another look – I hope I’m wrong with this as popovers are cool!