Windowing in FM 16: First Impressions

9 May 2017: Today’s release of FileMaker 16 introduces new windowing options, and changes to existing windowing behavior… some of these are cross-platform, and some are specific to FileMaker for Windows.

Demo file: FM-16-Windowing.zip (requires FM 16 or later)

Cross-Platform Changes

Change #1. Redesigned “New Window” dialog

• Note the new “Card” window style — I’ll have more to say about this below
• You can now specify the target layout for a new window — this means if you have an OnLayoutEnter trigger on your source layout, it will no longer fire when you invoke the “New Window” script step (provided, of course, that the step specifies a different layout)
• This dialog will also appear when you check “Show in new window” in the Go To Related Record script step.

Change #2. New “Card” window style

This brand new type of window is an overlay that displays modally on top of an existing document window, and you can see two versions in today’s demo (note: Card windows are not compatible with WebDirect).

The “basic card” example has “Close” enabled…

…and looks like this (note the “x” at the top left):

(In FM Go 16 the “x” does not display — instead you dismiss the Card by clicking on the background window.)

If on the other hand…

…you choose to display a card with “Close” disabled..

…then you will need to give your user a way to close the window.

Note that the height and width of the card…

…will be inherited automatically by the New Window dialog. And if you then leave top and left empty…

…the Card window will auto-center in front of its parent window.

What do I mean when I say (in a couple of the screen shots above) that “Card windows are modal relative to their background window”? To find out, click the “new window” button…

…display a card in one of the windows…

…and note that you can bring the other window to the foreground and use it as you wish.

For comparison’s sake, today’s demo also includes a “Dialog” window:

It’s a bit more work to get it to center properly in front of its parent window…

…and you will not be able to interact in any meaningful way with any other FileMaker window while the modal Dialog window is open.

Reminder: Dialog windows are modal with respect to the entire application, but Card windows are modal to their parent windows only.

Note: a new Card window cannot be displayed on top of an existing Card window.

Change #3. Scroll bars now only display when necessary

Here is the same layout in FM 16 and in FM 15, after “Adjust Window (Resize to Fit)” steps have been performed in each. Notice any difference?

Goal: size a FileMaker window optimally in a cross-platform-friendly manner.

Method: use Adjust Window (resize to fit), henceforth referred to as AW/RTF.

This works well when the user is on a form view. However, AW/RTF is not viable when you wish to start your user out on a list view, because it will cause the window to resize vertically to fill the screen top to bottom. Whoops!

The standard work around, historically, has been at startup to go to a “sizer” form view layout with optimal content width and height, do the AW/RTF there, then navigate to the list layout.

Here’s an example in FM 15… the startup script first goes here and performs the AW/RTF…

…then navigates to the list view layout, with everything sized optimally.

In FM 16 however, since scroll bars now appear only when necessary, after the AW/RTF, the “sizer” window is 20 pts narrower than in 15…

…so the trick no longer works. Note: the discrepancy is 20 points in this particular example where I’m using the Windows Classic theme… if I were using a different theme (or if I’d customized certain UI settings) the discrepancy could be greater or smaller.

But did you notice that today’s demo sizes (reasonably) nicely at startup, regardless of platform, theme or chrome tweaks? E.g., here it is with the Aero theme:

Here’s what’s going on behind the scenes…

Explanation:

• subtract window “content” width from overall window width to determine $theGap
• pad window width by this amount

(This is a preliminary stab at working around the problem — I am open to suggestions re: improvements.)

FM/Win-Specific Change: SDI (single-document interface)

At long last, FileMaker Pro’s MDI (“multiple document interface”) on the Windows platform has been put out to pasture in favor of the industry standard SDI (“single document interface”) — SDI, of course, has been standard on the Macintosh from day 1. For many FM/Windows developers, this change will be greeted with joy, despair, or some combination of the two.

Practically speaking, the move to SDI means that FM16/Win no longer has an “application” window, and unlike the Macintosh, the Windows platform does not have a universal menu bar embedded into the OS. So where will menus display in FM16/Win? At the top of each document window, that’s where.

Initially I was worried that the menu bar would be visible on every document window, that it would not be hide-able, and that even if we went to heroic lengths with custom menus, we would not be able to regain the lost vertical real estate. Well it turns out my concern was unfounded…

…because “Show/Hide Menubar” does exactly what its name implies…

…on Windows and in FM/Go at any rate, but not on the Mac where there is simply no need for it. (The FM 16 Help page says “Show/Hide Menubar” is partially compatible with Web Direct — I have not yet figured out what this means.)

A drawback of no longer having an application window: when you close the last document window, FM/Win 16 will exit. This is a very different behavior than on FM/Mac (and versions of FM/Win prior to 16) where you can close all document windows, but the application remains loaded.

Conversely, a nice benefit of the move to SDI is that document windows can now be displayed in front of the Script Workspace. This is something FM/Mac developers have always been able to take for granted, but an extremely welcome turn of events for those of us who toil in the FM/Windows vineyard.

In closing, I want to end by saying thank you to Joel Shapiro, whose “How to deactivate a FileMaker Button Bar” technique was put to good use in today’s demo file.