Multi-Window Interfaces

Opening a new window for your navigation elements is only the tip of the iceberg when it comes to working with multiple windows . It is now possible in FileMaker Pro 7 to strictly control multiple windows ”their position, size , and title ”and to present entirely new experiences for your users than in past versions of FileMaker Pro.

The simple nuts and bolts of these features can be found in the Window script step options. With them you can create new windows, close windows, select (bring to front) a specific window by name , adjust and resize windows, tile and cascade multiple windows at once, and control the availability of the Status Area as well.

Figure 13.9 shows a simple example of the script options for the New Window script step.

Figure 13.9. This square 500px by 500px window opens with a title of MyWindow and is positioned in the upper left of the screen.

The possible uses for multiple windows are quite varied.

• View as many layouts at once as your screen real estate allows.

• Create multiple list view windows of the same table, with different found sets, at once.

• Use a form for editing a single record while still viewing multiple records via either list or table view.

Tool and Function Palettes

As discussed previously, it's possible to build a palette for navigation, functions, or any number of options for buttons in your solution. For example, you might want to present your users with a new window containing a portal of all the possible reports in their database solutions ”that also open in their own individual windows. Another idea might be to have a central "control panel" that allows you as a developer to unlock certain layouts, run test scripts, re-log in, view internal field data, and so on.

The only drawback to this approach is that users need to click twice to perform button actions: once to bring the window forward, into an active state, and a second time on the button of their choosing.

Rich Dialog Windows

Modal dialogs ”windows that stay open in the foreground while waiting for some action to be performed by the user ”are a common user interface standard that users will find familiar. Certainly the Show Custom Dialog script step will take care of some of your basic needs, but in cases where you'd like to control the look and feel of a dialog or need more than three simple text entry fields, you will need to turn to crafting your window dialogs.

This technique is entirely driven by scripts. You are free to build whatever type of layout and window you wish. The only stipulation here is that you give users a means of "continuing" with the process after you've brought them to a modal dialog. Your database will be in a paused state, waiting for user input. More often than not, resuming from this state is accomplished with a Continue button, or, with a bit more scripting, Submit and Cancel buttons.

Cancel buttons imply that whatever action the user has taken in the modal dialog window can be undone. One technique for managing the undo process is to use global fields for data entry and to populate "true" fields only when the user clicks Submit. Other techniques involve record-level rollbacks . (A rollback essentially undoes a transaction in a database, returning it to a prior state.)

To learn more about rollbacks and undo operations, see Chapter 11, "Developing for Multi-User Deployment," p. 297 .

To build a modal dialog, follow these steps:

1. Build a layout intended to act as your pop-up dialog, called Pop Up. Size it in such a way that it is smaller than a "main" layout that is to remain behind it. You can add whatever functions and layout objects onto it that you wish. The layout can be as simple as a single field, or it can be as complex as on that displays a subsummary report in preview mode.
   
   
2. Add a Done button to your Pop Up layout. For now, attach it to its own placeholder script with just a comment. You will return to it later.
   
   
3. Now place a button on your "main" layout. For now, create a label for it: Open . Attach it to the following script:
   
   

   
   

    Allow User Abort [ Off ] New Window [ Name: "Pop Up"; Height: 300; Width: 500; Top: 100; Left: 100 ] Go to Layout [ "Pop Up" (MyTable) ] Show/Hide Status Area [ Hide, Lock ] Pause/Resume Script [ Indefinitely ] 

   
   

It's important to disallow user abort; otherwise users can close your window without performing the action you're attempting to require. It's also a good idea to lock the Status Area. Finally, you need to hold FileMaker in a paused state so that users can't perform any other action while attending to the dialog. Generally it's a bad idea to leave a script paused ”users can get stuck in limbo ”but in this case it is exactly the behavior you want. The script ends, leaving the user in a paused state. You need to remember this when performing any additional scripts or when providing other functions in your Pop Up window.

For details on the caveats and pitfalls of using this technique, refer to "Modal Dialog Dangers," in the Troubleshooting section at the end of this chapter.

Keep in mind that your users will still be able to run scripts that are visible in the Scripts menu. In solutions that use this technique, developers often opt to not set scripts to display in the Scripts menu, or write their scripts such that all that are visible take into account this paused state (by either refusing to run or ending gracefully so that the user's state in the modal dialog window is not disrupted).

Now return to ScriptMaker and create the Done script. You need to write whatever application logic your solution requires (for example, committing data to fields from globals , performing an evaluate function, running a report, and so on) and end your script with

 Close Window [ Name: "Pop Up" ] 

One final element is critical. You'll notice we haven't yet dealt with the pause state. If you add a Pause/Resume script step to the Done script, FileMaker won't know that you want it to resume a currently paused script. The behavior it respects is to overlay a new pause state on top of the earlier pause state. This is entirely as it should be: This allows you to build routines with multi-tiered pause states.

Multi-Tiered Pause State

A multi-tiered pause state can occur when you have one routine running, paused, while another runs and then hits a pause state of its own. For example, you might be running a report that pauses for a user to enter some find criteria. In performing the find sub-script, your process might turn up zero records and pause again to have the user respond to some options on what do to about the situation. These multi-layered pause routines fold into each other like Russian dolls : Each pause needs its respective resume script step performed before the outer pause state can be itself resumed.

The solution to dealing with your pause state lies with the button options attached to each button object. Select your Done button object and either right-click or navigate to the F o rmat menu (in Layout mode) and choose the Button option. Another technique is to simply double-click on the button object in Layout mode. Refer to the Current Script options shown in Figure 13.10.

Figure 13.10. Notice the rarely used Current Script option.

The Current Script option for the Perform Script button behavior is almost never changed. Most often its default state of pausing a currently running script while performing whatever new script is necessary will meet your needs. In this case, however, you need it to resume the current script (which will simply continue from the pause state, effectively ending it) before proceeding through the Done script and closing the pop-up window.

This then closes the pause state without creating a nested second one and allows the user back into the state of using the database solution normally. Combined with the Close Window script step, the user's experience will be that of clicking Done and seeing the window close. Clicking your Open button sends users back to the layout from which they began .

Special Effects

Other window techniques don't seem to add much more functionality to your solution, but can certainly be fun to include for more polish (or to just show off). Calling these techniques "special effects" is probably a stretch ”we hope those of you who are Flash developers will just let this section roll by for what it's worth ”but we've had some fun coming up with a few tricks that you can pull off with window script steps.

Marquee Titles

Using a simple loop, you can rename the title of a window with progressively scrolling text. Use a Set Window Title script step inside a loop. Use a number increment (stored in a global field) and apply it to a Right or Left function with the text you want to display. The script looks like this:

 New Window [ Height: 500; Width: 500; Top: 20; Left: 20 ] Set Field [ myTable::loopIncrement; 1 ] Loop     Exit Loop If [ myTable::loopIncrement = Length (myTable::windowTitleText) ]     Set Window Title [ Of Window: Current Window; New Title: Middle ( myTable:  :windowTitleText; myTable::loopIncrement; myTable::     loopIncrement) ]     Set Field [ myTable::loopIncrement; myTable::loopIncrement + 1 ]     Commit Records/Requests [ No dialog ]     Pause/Resume Script [ Duration (seconds): .1 ] End Loop 

Not the greatest use of computer technology ever made, but you can certainly draw attention to a warning message or alert of some kind.

Expanding Windows

By using a similar looping technique you can alter the horizontal and vertical dimensions of a window so that it appears to "grow" or expand onto the screen:

 New Window [ Height: 500; Width: 500; Top: 20; Left: 20 ] Set Field [ myTable::loopIncrement; 1 ] Loop     Exit Loop If [ myTable::loopIncrement = 500 ]     Move/Resize Window [ Current Window; Height: myTable::loopIncrement; Width: 500; Top:  40; Left: 40 ]     Set Field [ myTable::loopIncrement; myTable::loopIncrement + 1 ]     Commit Records/Requests [ No dialog ] End Loop 

This particular example is somewhat slow because it needs to loop 500 times to draw the window in question. Play with the increments in your Set Field [ myTable:: loopIncrement] script step to make your window draw more quickly. You could just as easily set the width in a similar manner.

Hiding Windows

You can use starting coordinates for a window of 9000, 9000, or negative numbers to "hide" windows off screen. On the Mac this works beautifully ”users will have no idea they're there ”but on Windows no matter what you do you are presented with scroll bars in the FileMaker application window.