QUE CORPORATION - Using Filemaker pro X
| < Day Day Up > |
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.
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 build a modal dialog, follow these steps:
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.
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.
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:
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:
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. |
| < Day Day Up > |