Today I want to talk about a potential problem lurking in a small percentage of FileMaker solutions, and discuss various options for mitigating it.
As you may know, there are three ways to display a new window…
- Via the New Window script step
- Via the Go To Related Record script step
- Manually via Window > New Window
…and it’s this last option that can, depending on circumstances, be problematical.
I say “depending on circumstances” because typically it’s okay for a user to spawn a new window, which is to say that doing so doesn’t pose any challenges beyond those the developer already faces when building a multi-user system, which presumably the developer has considered and has intelligently dealt with.
So most of the time a user manually spawning a new window is not a problem, but here is a situation where it could cause difficulties: when the interface is tightly controlled, as in a dashboard environment, where users are allowed to navigate among certain layouts, but the business logic dictates that only one of these layouts be visible at any one time.
In other words, the system is designed with the expectation that these layouts may be accessed sequentially but never simultaneously… perhaps because these layouts share a common set of re-usable fields, relationships, portals (filtered or unfiltered) and/or global variables, and data entered via one layout may be utterly inappropriate if viewed on another.
Of course you can clear or re-set those values scriptomatically as the user navigates from one layout to another, but that brings us back to the assumption that the user will visit the layouts sequentially rather than simultaneously. If they begin on Dashboard A, spawn a new window, navigate to Dashboard B, enter data there (perhaps via a series of cascading value lists w/ entries appropriate to Dashboard B), then click back to the Dashboard A window, they will now see data from Dashboard B on the Dashboard A layout. This may be confusing at best; at worst it could lead to unpleasant consequences.
Incidentally, a concrete example of where the user manually spawning a new window is undesirable is within Seedcode’s DayBack for FileMaker as per this tech note.
Okay, so sometimes we don’t want users spawning new windows. Can’t we simply suppress “New Window” via a custom menu? Nope. The Window menu is not modifiable via custom menus.
What about removing the entire Window menu via custom menus? Well we could do that, but that seems pretty heavy handed, and power users might object, especially if they tend to have multiple FileMaker files/windows open simultaneously and are accustomed to using the Window menu to navigate between them.
What about removing the entire Window menu and then painstakingly recreating it as nearly as possible with a custom menu? There are a several problems with this approach, including…
- not all the widgets on the real Window menu are available
- as windows open and close, your ersatz Window menu (unlike the real Window menu) won’t refresh in real time
Hmmm… what about using a plug-in such as MonkeyBread (MBS) to remove New Window? I played around with these two functions…
…and found that the second one did the job perfectly, but, unfortunately, a little too perfectly. I was able to eliminate New Window from FileMaker’s Window menu like so:
MBS ( “Menubar.SetMenuCommandVisible” ; 57648 ; 0 )
…the menu id # having previously been determined via…
MBS ( “Menubar.ListMenuCommands” )
…but then realized that the change was application-wide, rather than file-specific. Yes, you could attempt to run a script in each file to toggle New Window on/off (assuming you have permission — your users may be running FM files you don’t have developer-level access to), but even then you don’t have a programmatic way to determine when a window loses or gains focus.
Given that our users may be running other developers’ FileMaker solutions, as opposed to just the ones we’ve built, in my opinion disabling New Window across the board in all files, i.e., at the application level, is unacceptable.
Okay, I’ve spent the last few minutes going over what won’t work. All this negativity is depressing (and may be illegal in California). Is there a viable work around? I believe there is. Define the following script…
…and invoke it any time a new window is spawned by attaching it to OnWindowOpen.
(You could instead map the above script to an OnLayoutEnter trigger, but then you would need to assign it on a layout by layout basis, which could easily turn into a maintenance headache. By using OnWindowOpen, you only need to set it once.)
Now, any time the New Window command is executed, whether via script or manually, the trigger will run. If the window name ends in ” – ” followed by any number, that window will immediately close… unless you are logged in with [Full Access] privileges, in which case you presumably know what you’re doing and are permitted to spawn new windows with impunity.
Note 1: for scripted New Window steps, you must specify a window title, otherwise the window title will have the auto-appended ” – n” (where n represents some number, most likely 2) and the trigger will immediately close it.
Note 2: as Paul Jansen mentioned in his guest article last month, Go To Related Record (w/ New Window) is exempt from OnWindowOpen as per this Claris help entry: Go to Related Record.