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