Popover is excellent, just need to incorporate the possibility of modal display.
(block presentation background)
Be sure to add a feature request here...
You can use a script trigger that fires when the user tries to close the popover and disallow the close until the user satisfies whatever conditions you like and you then close the popover via script step.
This will simulate a modal behavior. We use this appproach regularly ...
Agree with the popover love!
And I'll +1 the suggestion for a modal option. iOS Human Interface Guidelines do allow the use of modal behavior on a popover (with "Done" and/or "Cancel" buttons, or similar), and that approach is occasionally seen in native iPad apps. Also, for an even more "native" iOS feel, it would be nice to be able to specify that when the popover is open, the rest of the window should be slightly darkened. I tried adding a box shadow with a large spread to accomplish this, but the maximum spread allowed in the Inspector is 100pt.
Sounds like a trip to FileMaker's feature-suggestion page is in order*. (*EDIT: …as Steve Romig chimed in to suggest, just as I typed the above)
having the ability to show the content of other layouts in a popover would make them much more versatile. Then you could provide input helpers like calendars, clocks, calculators etc. in a popover and maintain them centralized. Just a dream.
If you put an 'OnObjectExit' trigger on the actual Popover panel, you can prevent closing the popover or interaction with the rest of the layout by using the script step
Exit Script[Result: False]
I just tested this and it works perfectly
I agree that it works perfectly to keep the popover open, but by exiting the script you're stuck in the popover if there was a Resume Script button in the popover
An untested method:
use a $$var as flag for Exit Script . OnEnter, set it to False; set it to True before leaving the popup with a legal method (e.g. Cancel, Search). All the illegal methods of leaving the popover (tap, click outside) would be captured.
I think you missunderstand me. When the popover is open no script is running. When you try and click elsewhere on the layout the 'OnObjectExit' trigger script runs and if the required criteria are not met the script exits with false which prevents the popover from closing.
You're right - when the popover is open and no script is running, this idea works if you want the popover to behave in a way that it can't be dismissed unless some other condition is satisfied. But in my case, I have a script running and completing the script also closes the popover in the expected way, so I can't have the Exit Script step killing the script that should continue.
I'll re-write it so that the script exists in two parts. thanks for helping.
I've solved this problem, but in the course of doing it, I found something very unexpected: if a popover is open when in Find Mode and a button in the popover is pressed to Perform Find with no scripted find parameters, just the value entered in the field(s) in the popover … the popover is closed by the Perform Find command and the window changes to Browse Mode before the Find occurs, however, Perform Find still works.
In other words, FileMaker is "remembering" the field value entered into a popover in Find Mode and using it for a Perform Find command that's executed from Browse Mode,
In case this is not easy to follow, try this:
On any table with more than 1 record, make a popover open in Find Mode. Put a searchable field in the popover, and a button whose only task is to Perform Find with no find parameters. Attach a script to the button so that there is at least one script step prior to the Perform Find step; it can be anything simple like Allow User Abort or Set Error Capture. Or set a variable. It doesn't matter; the purpose is to allow you to use the debugger to step through the script and observe what happens when the popover closes.
Important: make sure that immediately before the Perform Find step, you insert Close Popover.
Next, put a Script Trigger on the popover to run the same script that is run by the button in the popover, in Find Mode, OnExitObject. The purpose of this is to allow the user to abandon the popover-find and return to Browse mode. In the popover definition, put a script parameter on that triggered script so that when this script is run from the button in the popover, it runs without a script parameter, but when it runs OnObjectExit, it runs with the script parameter.
Next, in Browse Mode, activate the popover button. When the popover opens you can confirm you are Find mode with the Find indicator at the lower left side of the window's bottom border. At this point, open the debugger.
When you click away from the popover to dismiss it, the triggered script will fire because you're in Find Mode and it will have a script parameter. A script step that detects the existence of the script parameter, will Enter Browse mode and be done. That part is fine.
But if you enter a value in the field in the popover and press the button to run the same script, it runs without a script parameter and you'll see that before you get to the Perform Find step, the popover closes and you're in Browse Mode. Even though the popover is no longer visible, it must still be holding the search value in the designated field, because Perform Find works from the Browse mode.
Now, if you remove the Close Popover script step, the popover closes and the window remains in Find Mode. But the curious thing is that the use of the Close Popover step changes the window from Find Mode to Browse mode, but the Find still works even though the popover is gone.
I'm pleased with the result, but it seems very unusual.
Mark, one way that should work for the "dimmed background" effect would be to make a transparent black box behind your popup and then use the new "Hide Object When" feature. Just set it the formula to something like "not $$pop" - and have your script triggers on the PopOver set $$pop to 1 when it opens and 0 when it closes.
Anchor your dim box to all 4 sides.