Troubleshooting

Omit Re-created

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 fairly straightforward to reproduce: next 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 paused state for the user to click a button (often labeled something like Find, Continue, or Search). After the button is clicked, the script continues by utilizing the Perform Find script step. (An alternative to this is to have users enter find criteria into global fields and to manage populating find requests programmatically.)

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.

The easiest way to deal with this is to simply make the checkbox a Boolean calculation with an auto-entry 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 Perform Find 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 user-interface 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 honor only the history one user creates, rather than all the history from all navigation in the system, simply use the AccountName information already stored in the NavHistory table you created. You need to modify the NavBackTarget relationship to include a second match condition between a global field holding the current user's account name and the AccountName 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, see Chapter 11, "Developing for Multi-User Deployment," p. 297 .

Users can close FileMaker Pro anytime 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 less-than -optimal state. We encourage you to create flags for when pop-up windows 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 graceful form of alerting you to the fact.