Working with Table View

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 check box is found only in the Status Area. What's a technique for offering the same functionality from a script?

Most of the Status Area functions are fairly straightforward to reproduce in a script: 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 would 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 rightit will be included in the find request itself and FileMaker will look for records in which the omit flag equals 1.

The easiest way to deal with this is to simply make the check box a Boolean calculation with an auto-entry setting 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 to check against 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.

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 be completed either in its entirety or not at all. For more information on atomicity and multiuser development, see Chapter 11, "Developing for Multiuser Deployment," p. 307.

Users can close FileMaker Pro anytime they want. 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 this doesn't occur, you might create an error message or some other graceful way to alert you to this fact.