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

 

“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.

Updated 2/24/2014

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.

Workaround. 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.

Subscribe to Blog via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

Tagged with →  

28 Responses to FileMaker 13 Popover Bugs & Interesting Behaviors

  1. 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

    Regards,
    Dan

    • seedcode says:

      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.

      • 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!

      • Tim Anderson says:

        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.

  2. Mark Scott says:

    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!

    Mark

  3. Oreste says:

    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.

  4. 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

  5. Oreste says:

    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.

  6. Dylan says:

    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.

    • seedcode says:

      We’re having success using an OnObjectEnter trigger on the popover panel itself (not on the popover button). Hope that helps, Dylan.

      • John Weinshel says:

        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.

  7. John Weinshel says:

    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:
    If[test]
    Close Popover
    Show Explanatory Message
    End If
    …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:
    If[Test]
    Exit Script[“sucks”]
    Else
    Go to Field [field inside the PO]
    End If

    …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.

    • jason says:

      Hey John,
      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.
      hth,
      Jason

  8. Barbara Cooney says:

    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.

    Best,
    Barbara

  9. Mike Ryan says:

    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.

  10. S. says:

    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?

  11. Cailen W. says:

    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

  12. Damien Kelly says:

    Great article!

    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.

    Thanks,
    Damien

  13. Mike says:

    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?

  14. George says:

    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?

    Thanks,
    George

    • seedcode says:

      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.

Leave a Reply

Your email address will not be published. Required fields are marked *

Share →
DOWNLOAD
DayBack Calendar
DayBack's 30-day trial is unlocked so you can customize it and integrate it with your files.
Download DayBack and we'll send you a couple short emails with tips on how to modify it and use some of the coolest features.
Thank you! Please download: DayBack Calendar
Need More?
SeedCode tips & example files in your inbox
Need More?
SeedCode tips & example files in your inbox
Want More?
Be the first to see articles and tips like these
DOWNLOAD
TimeZync
Download TimeZync and we'll send you a couple short emails with tips syncing your FileMaker Go files.
Thank you! Please download: TimeZync
Want More?
Be the first to see articles and tips like these