That is the question! If you are designing a FileMaker Pro database, do you show the status toolbar?

In versions when it was the status area on the left of screen (prior to the radical new design in FileMaker Pro 10), "YES" was a common answer. Even stronger were answers like "yes, hide it and LOCK it".

But now that the functionality of the (new) status toolbar in FileMaker Pro 10 has been introduced, do we need to re-evaluate? I would think so. The status toolbar has some useful tools that can save us a lot of time in development. Why re-invent the wheel? And some features like the Exit Preview button cannot be reproduced in the design. In combination with the new script triggers, we now have far more control when the status toolbar shows, is hidden or gets locked.

FileMaker Pro 10 has a layout trigger called OnModeEnter. This will trigger a script after a mode (not Layout mode) has been entered. We can therefore trigger a script for any layout when the user switches to Browse, Find or Preview mode. This script can be used to control the state of the status toolbar.

So what would this script look like?

The script will control the status toolbar in each of the three modes - Browse, Layout and Preview. The function Get (WindowMode) returns 0 for Browse, 1 for Find and 2 for Preview mode.

The status toolbar has three states that we would like to be able to use - Show, Hide, Hide and Lock (you can also "show and lock" but we will not be using that state). We will use the letters S, H and L to represent each of the three states.

The script will require a three letter parameter which is one code letter for each mode in order - Browse, Find and Preview. So if the parameter was "LHS", this would lock the status toolbar in Browse mode, hide (but not lock) in Find and show in Preview.

The first step of the script will determine the action to be taken according to the current window mode. It sets this action as a script variable using:

Set Variable [$action;
Value:Middle(Get(ScriptParameter); Get(WindowMode)+1; 1)]

The value is calculated from the script parameter. The expression extracts the nth character of script parameter by (mode + 1). For example, for Find mode, (mode + 1) = 2, and we extract the second character from the script parameter.

The next part of the script sets the status toolbar state according to the value of $action.

If [$action = "S"]
  Show/Hide Status Area [Show]
ElseIf [$action = "H"]
  Show/Hide Status Area [Hide]
ElseIf [$action = "L"]
  Show/Hide Status Area [Lock; Hide]
Else
  Custom Dialog ["Error"; "Invalid script parameter or action"]
EndIf

Note the last Else step. This is used to trap errors where an invalid script parameter or $action result is found. This would be discovered during testing and is not something a normal user would see.

So now we have a script. All we have to do is to attach it to a layout using an OnModeEnter trigger and specify a three-letter code for the script parameter. And then you have control over the state of the status toolbar in three modes for that layout.

If you implement this technique, be careful to consider what happens in conjunction with other scripting. For example, when you script a move to a layout what would your script expect the state of the status toolbar to be? It may have been changed by the OnModeEnter script. Just make sure you test!