Obscure Multiple Window Issue

Note: Thank you to Colleen Hammersley for bringing this issue to my attention, and to Howard Schlossberg for proposing a clever and elegant work around that addresses the issue on the Windows platform. (We’ll also look at another fix that works cross-platform.)

Today we’re going to explore a windowing behavior change that was introduced in FileMaker 12. If your solutions display multiple on-screen windows, then you may at some point find yourself facing this issue.

• Window Focus, v1 – FMP 12/13/14 demo file showing problem
• Window Focus, v2 – FMP 12/13/14 demo file with work around for FMP/Win
• Window Focus, v3 – FMP 12/13/14 demo file with cross-platform work around
• Window Focus – FMP 11 demo file, blissfully problem-free

The problem manifests in different ways on the Windows vs. Mac platforms; we’re going to start out by looking at what happens in FMP/Win via the Window Focus, v1 demo.

Imagine you have salespeople processing multiple orders simultaneously, with each order in its own window. When an order window is closed you want certain scripted actions to occur, so you have installed a custom menu set with a special “close window” script to replace the standard “File > Close” menu item.

Reminder: this menu item also governs the behavior of the the close widget (i.e., the “x” at the top right of the window).

Here’s the custom menu item…

…which invokes this script:

So, assuming there are five open “order” windows, with window #5 frontmost, what happens if the user clicks the close box on window #3?

BEFORE CLICK

AFTER CLICK

What the heck? The “close window” script executed in the original foreground window (#5), rather than the intended window (#3). Even though window #3 moved to the foreground, it did not become “active” until after window #5 had closed.

By contrast, if we conduct the same experiment in FM 10 or 11 (i.e., in the Window Focus.fp7 demo), we will see the expected result (window #3 closes). And incidentally, this pre-FM12 behavior is identical on the Macintosh platform.

Returning to the FMP 12/13/14 demo, what can be done? Well the obvious idea of adding a “Select Window [current window]” step, like so…

…doesn’t help at all, unfortunately. Nor does “Select Window [Get (WindowName)]” since window #5 is the active window as far as FileMaker is concerned.

Surely there must be some way to convince FileMaker to run the “close window” script in the desired window? Fortunately there is, and you can see it in action in Window Focus, v2. One simple change to the close window script is all it takes.

Howard Schlossberg’s insight was that the WindowNames function a ) updates whenever the window stack order changes, and b ) lists the windows in z-axis order with the frontmost at the top of the list. So in Window Focus, v2, if you click window #3’s close box with the debugger running…

…and view WindowNames in the Data Viewer, here’s what you will see:

[At this point a less perceptive author might refer to Howard as a genius, but I suspect he wouldn’t appreciate that, so I won’t.]

Okay, we’ve looked at the behavior on the Windows side… what about on the Mac?

On the Macintosh, when you click the close widget of the foreground window (window #5) in either of the first two demos, as expected, the “close window” script runs and all is well.

But when you click the close widget on any background window… the custom menu is ignored and the window simply closes without the “close window” script executing. (!!!!)

[If you have a copy of FM 10 or 11 handy, you can open Window Focus.fp7 and confirm that this was not the case prior to FM 12.]

The work around, as you can see in the Window Focus, v3 demo, is to not rely on a custom menu at all, but instead go the script trigger route, like so.

Since OnWindowClose is a file-level trigger, it will run any time any window is closed, so you’ll want to branch your “close window” script accordingly, e.g.,

Does it work? Indeed it does, and no need to invoke “Select Window”.

[For the sake of simplicity, I used Get(LayoutName) in the above script, but of course layout names can easily be changed and one might forget to correspondingly update the script. In reality I would instead target the internal layout id using the technique discussed here: Avoiding Brittleness.]