I am trying to create a scripted find process, so that I can keep the Status Area hidden, but the omit checkbox is tricky. What's a technique for offering the same functionality?
Most of the Status Area functions are
straightforward to reproduce:
record, previous record, switch mode, displays for record X of Y, sorting state, and so on. There's one that's not so obvious, though: the Omit check box in Find mode.
A scripted Find mode often takes users into Find mode and pauses the script in question (disallowing abort). The system then waits in a
state for the
to click a button (often labeled something like Find, Continue, or Search). After the button is clicked, the script continues by
script step. (An alternative to this is to have users enter find criteria into global fields and to manage populating find
It'd be a no-brainer to add a check box to a layout, call it "omit_flag," and test for a value in it when you've scripted a find routine. But here's the rub: If you're actually in Find mode, in a paused state as just described, what happens to that flag if you perform a find?
That's right ”it'll be included in the find request itself.
way to deal with this is to simply make the checkbox a Boolean calculation with an
of "yes" or "1" (whatever the value list controlling your check box is set to.) In data terms, it serves as a constant, but in Find mode it does not affect the outcome of a Find request; it is always valid for all records. As such, you can use it as a variable against which to check in your
steps without having to worry about clearing it from your Find requests. You still need to manage the process of what to do with the flag if your users enable it, but at least the
works as they (and you) would expect.
Multi-User Back Button Functionality
How do I manage a back button in a multi-user environment where I want to trace backward through the layouts only I have visited?
When designing a system for use by multiple users, to get a Back button to
only the history one user creates, rather than all the history from all navigation in the system, simply use the
information already stored in the NavHistory table you created. You need to modify the
relationship to include a second match condition between a global field holding the current user's account
stored in NavHistory. Your target rows will then point only to those that apply to your current user. This assumes that one person has access to one account.
Modal Dialog Dangers
What are the downfalls to using the Modal Dialog technique to control what data gets posted to my solution?
Using the modal dialog technique described in this chapter isn't a foolproof way to address atomicity in FileMaker Pro.
Atomicity specifies that a transaction needs to either be completed in its entirety or not at all. For more information on atomicity and multi-user development,
Chapter 11, "Developing for Multi-User Deployment,"
Users can close FileMaker Pro
they wish. Depending on what assumptions you've made in your development and the scripts leading to opening such a dialog, your system might be left in a
-optimal state. We
you to create flags for when pop-up
are opened and then confirm that they're then closed. In cases when such doesn't occur, you might create an error message or some other
form of alerting you to the fact.