8 Replies Latest reply on Mar 18, 2015 3:40 PM by BruceHerbach

    Sorted portal with popover and changing related record


      I've been using popovers extensively and have just used one for the first time with a sorted portal. The popover contains related fields from the portal's records. The user opens the popover for a portal row, changes the value of a field used in sorting the portal and then commits the record by clicking on the open popover. The popover remains visible and the related data displayed in the popover could potentially change to show a different record's data. The user decides to delete the related record using a 'Delete' button in the popover and they haven't noticed the data is displaying a different record they will delete the wrong record.


      I've attached a demo file.


      Open it and click on the date field in the second portal row. Change the date to the 15th March and then click the popover's background. You'll see the data change to show the record that is now sorted in row two.


      I understand why FileMaker does this and this serves as a warning for novice developers to be careful using popovers.


      I searched to see if other people have discussed this and I didn't find any threads for 'sorted portal popover'.


      If you have used popovers in a similar manner, how have you dealt with this?


      One method would be to capture the related ID, store it in a global and use the global in a relationship to the child table to display in a popover with a hidden popover button.

        • 1. Re: Sorted portal with popover and changing related record



          The issue appears to be that clicking outside of the date field in the popover commits the record and changes the sort order.  Unfortunately the user is still on the same portal row so is now on a different record.


          Attached is a slightly updated version.  This has an on exit script trigger attached to the date field.  It closes the popover and commits the record.  Forcing the user to re-select the record.


          You could do something a bit more user friendly,  say capture the record ID,  commit the find the correct record and use gotoobject to re-open the popover on the correct record. Unfortunately there will probably be a bit of screen flash or shift when the popover opens on a different portal row.


          A completely different approach would be to use a button and script in the portal row and move the popover out of the portal.  Make it hidden so the user can't see or click on it.  The script puts the record ID into a global field and uses Go To Object to open the popover. 


          See the attached examples.

          • 2. Re: Sorted portal with popover and changing related record

            Hello Bruce,


            Thanks for your reply.


            Yes, the popover is displayed for a particular portal row, not attached to the record on that row. Like I said, I understand why FileMaker is doing this and it's as much a warning for people using popovers as it is for me to find a different method.


            My example in the last paragraph of my original post is the same as your 'completely different approach'. I think this is most likely the best option as it avoids any complicated workarounds, screen flashing etc.


            Another potential option would be to have a global field for every data entry field and load the data into those fields for editing and then use a 'Save' button to set the data fields with any changes made in the global fields. It would potentially come up against record locking issues when setting the data fields though.


            Best regards,



            • 3. Re: Sorted portal with popover and changing related record

              Sorry Damon, but for me allowing the change of a field's content in a portal, when the field itself is a criteria for the portal's sort, is a design flaw.


              (I could say "why change the date in the popover when you can directly change it in the portal" but that's not the point. )


              I just would not like to see a portal row jumping in the portal at a different place after a change I've done to its contents (except when deleting it, but that's a different problem). It has to do with user's short memory and overall consistency. In other words, users should be able to predict the result of their actions, launch the action and see what they predicted, given a stable interaction flow and model. Not to mention that with 50 children and a portal height of 15 rows your just-edited row could land completely out of the viewed rows list and would trigger a desperate portal scrolling in order to find it again, just because users need confirmation and usually don't trust the "system", so the first thing that occurs is this scrolling "just to make sure it really happened"...

              • 4. Re: Sorted portal with popover and changing related record



                I think it works best to take the popover out of the portal. By doing so a change in the sort order or something else will leave the user on the same record. Things like delete record should close the popover. The second demo does this.




                Sent from my mobile device... Please excuse typos.

                • 5. Re: Sorted portal with popover and changing related record



                  While I understand what you're saying, it's not possible in this particular use case.


                  Customers have orders and the users want the portal of orders sorted in descending date order. The user creates an order and realises they've entered the wrong date. They click on the portal row, activating the popover where they change the order date. The order is now potentially positioned on a different portal row.

                  • 6. Re: Sorted portal with popover and changing related record

                    Thanks Bruce, I agree. The solution's popover does close when deleting the record, I didn't have time to include that in my demo.

                    • 7. Re: Sorted portal with popover and changing related record

                      OK, but at least a visual clue, like this (modified Bruce's version)

                      • 8. Re: Sorted portal with popover and changing related record



                        You original post shows a definite programming gotcha.  siplus has a valid point,  you should never set up a situation were the user can (and probably will ) end up working with the wrong record.  The V2 demo I put up will let the user change the date field but won't change records until the user closes the popover and selects another record from the portal.  When the popover closes,  the portal sort takes over and the records are in the order the user wants to see. 


                        The other advantage is they are not working in the portal so the records won't move until they finish and close the popover.  So no flicker or other screen annoyances.


                        The popover button should be hidden so the user can't click on it accidentally.  When I say hidden I'm talking about the "HIde Object When"  item on the Data tab of the Inspector.  Set it to 1 so the button is always hidden.  Attached is an updated V2 demo with this setup. 


                        One last thought,  you can make a popover modal,  ie can't be closed until the user clicks a done button.  If that would be helpful,  here is a link to a demo I put up a while back that does this.  Modal Popover Demo