Window management in a cross-platform environment using Filemaker can be a bother. Through no fault of Filemaker’s, OS X and Windows just handle windows differently. Developers have a decision to make about how to make their Filemaker app consistent for all users.
First, a couple of generalizations:
- Most users on Windows that I know, run their applications maximized.
- OS X users tend to have their windows open as large as they need to be to see the content, but no larger.
OS X is the more forgiving of the two for a Filemaker developer. Usually you just open the window and adjust to fit the content, and you’re done. You’re not likely to need to adjust the window again (unless you have large differences in layout content size).
If you don’t maximize, Windows users aren’t likely to enjoy or understand the extra grey space in the gap between the Filemaker application window and the database document. When the user decides to maximize on their own it causes problems. If you haven’t accounted for this possibility when building your app, the user is going to become annoyed when new windows are launched and undo their maximization over and over.
The alternative is to maximize the window and assume they will always be maximized. When opening new windows that are not maximized, the main interface window is restored to whatever size it was before being maximized. When closing your pop-up window you (the developer) have to re-maximize or restore the previous window size. Even though it’s the logical way to deal with the problem, it looks sloppy. Especially when compared to the way things work on OS X, where there is no layout adjustment needed for a pop-up window.
There’s another option that you may not have thought of. I didn’t think of it either until recently. I had the need to run an install on timer script to open a window and grab some data periodically in the background. As soon as I opened the solution in Windows the problem became very apparent. Whenever the script runs, the window un-maximized. I could always add a step to re-maximize, but again; inelegant. What I decided to do was to fake maximize the window when the file opened. I’d keep the window un-maximised , but fill as much of the Filemaker application window as possible, using the Get ( WindowDesktopHeight ) and Get ( WindowDesktopWidth ) functions. This will tell you how big to make the window. I’ve found that subtracting 4 pixels on each dimension will make the window size just right.
Now, no matter whether the user has the Filemaker application maximized, or only taking up part of the screen, the internal document window will be adjusted to fit just within the bounds. This makes the windowing more consistent cross platform. Users who habitually maximize probably won’t feel the need to since the window will be taking up all available screen real estate (less the extra space needed for the document title bar). Enjoy. WindowsMaximizeFakeout Demo
Always a challenge no doubt. The only thing I would disagree with is this line:
“Through no fault of Filemaker’s, OS X and Windows just handle windows differently.”
Windows is capable of both SDI (Single Document Interface) and MDI (Multi-Document Interface). It is all about how the developer builds the app. For example, Microsoft Excel encloses all open file within a single application window (MDI)…but Microsoft Word has individual windows for each file (SDI).
FileMaker has never made the change. It is probably the only thing I don’t like about FileMaker. Rock on FM.