Before to start

As emerged by discussing this topic, the best practice about offscreen windows is to simply avoid them if you can. So this page attempts to list the best practices to use when you just have to use offscreen windows. Following there is a list of pros and cons of offscreen windows as emerged in the discussion:


  • Performance: Freezing the window and switching layouts is faster than opening a new window
  • Method not compatible with FileMaker Go
  • For Windows users with the window maximized, opening a new off-screen window will un-maximize the previous window
  • You have to remember closing them at every script's exit point


  • It's an easy method to preserve the application state (current layout, found record set, etc.)
  • Makes scripts more context free

Offscreen Windows

Every time a script is supposed to do something more than just update a couple of fields in the current record, I like to make it work in its own window (often off-screen to improve the user experience). One problem with the windows is that you have to remember to close them at every exit point of your script, otherwise your solution will accumulate tens (at best) of off-screen windows. I'm using a couple of practices that I found helpful in the everyday work:

  • Set the title of the window to the name of the script that is creating it. This helps in the debug process when you find one (or many) offscreen windows left open by scripts; moreover it makes very easy to close the right window at the end of the script (by specifying the script name as the title of the window for the close command), this greatly reduces the risk of conflicts in the window usage because every script, also if it is called as a subscript, will always open and close its personalized window. The only case in which this method needs additional precautions is the event of recursive script calls, in this case the script should be able to reuse an open window (for resource usage efficiency) or open a specific window for every running instance of the script (for example by appending a random number at the end of the window title to uniquely identify it).

  • I created a script called "Create offscreen window ( title )" which I call in my scripts when I need a working window for them. In this script I create an offscreen window with the specified title; if the current user is a developer the window is not placed offscreen for debug purposes. This script gives me a cleaner perception of the solution because I have this explicative script called instead of hundreds of Create new window commands around in my scripts. As far as you avoid or manage recursive calls, this script can be modified to recycle existing windows when the specified title matches an existing window's title.

These are practices that I'm constantly using but they are far from refined; for instance I was thinking about a custom function to generate a unique script instance identifier (something like script name & timestamp & random number) that could be useful for debug/log purposes (with recursive script calls too) and also usable as a title for their working windows, but at the moment the techniques I described above are enough for me.

  • No labels


  1. These are good practices when we have to create an offscreen window, but I try to avoid off-screen windows when I can help it for 2 reasons:

    1. Performance. Freezing the window and switching layouts is faster than opening a new window in every test I have ever run.
    2. There's no such thing as an off-screen window in FileMaker Go. I know we can use different scripting practices between desktop and other versions of FileMaker, but the more we do that, the less portable our scripts are.
    1. I think I have to clarify one thing: I work full-time on a really big FileMaker solution (the production database of a factory) but I'm not a real FileMaker professional because the solution I'm managing was started years ago without much database knowledge and I learned FileMaker the hard way by working on this bad example (or good example of what FileMaker can tolerate).

      I agree with your point about performance, but usually I need to preserve the application status at the moment the script was launched (current layout, current tabs, found set, etc.) and I think the more easy and flexible way to do that is to make every script "context independent" by working on its own window and so preventing it from altering the application state.

      Also your point about FileMaker Go and portability is right of course, because of my work I simply never had to develop with FileMaker Go so in writing my post I simply forgot about its existence, I apologize.

  2. Another aspect to consider is Windows users with the window maximized; opening a new off-screen window will un-maximize the previous window.

  3. In light of the proposal, I have to agree with the identified downsides to offscreen windows. I've stopped using them myself as much as possible. I would say we should put a disclaimer on the topic which suggests attempting to not use offscreen windows.

    However, we will almost always have situations where that one use case may dictate that we do use an offscreen window.

    I would suggest we rename the title to "Offscreen Windows" and refine the hit list of what to do.

    For example, I have seen a lot of people use something like the following for the top and left values.

    Get ( WindowTop ) + 2000 and Get ( WindowLeft ) + 2000.

    This just doesn't make sense when we have Get ( WindowDesktopHeight ) and Get ( WindowDesktopWidth ) which will put the window just outside of the right and bottom most edges of all attached monitors.

    I really like your suggestion of making the Window Name use the name of the Script. I would just want to ensure illegal chars didn't have a chance to creep in. Applying a Filter() of some sort to ensure consistent operation would be good.

    1. I updated the proposal text as you suggested.

      About the Get ( WindowDesktopHeight ) and Get ( WindowDesktopWidth ) suggestion, I think it is a good idea and I already used it at work. I will insert it in the proposal, but I have to verify one thing before: One day I think I saw "offscreen" windows created in this way flashing in the second monitor of a colleague. She has a Mac with OS X 10.8 and FileMaker 11, the second monitor was at the right of the main monitor, and the windows was flashing in its lower left corner, as if the WindowDesktopHeight/Width returned the size of just the main monitor.

      No problem with the Filter() suggestion, but just to understand, what makes you think that some chars can be legal in script names while illegal in window titles?

  4. I understand the downsides of offscreen windows, but reading this discussion I'm beginning to think that the target of our work can make a difference in the best practices that are more suitable. Tell me if I'm wrong, I think many people here is developing FileMaker solutions that are like a product: you create it and deliver it to the customer, so your solution has to work beautifully like a well refined application. Then the customer asks you new features, so you take your solution, add the features in a beautiful and user friendly way, call it "2.0" and deliver it to the customer.

    I work on the production database of a factory, something like 120 FileMaker databases (many of them poorly designed in the past years and now conditioning the development) hosted on 6 servers, mixed with MySQL data sources and some access by WAN; every single day there is something to change or feature to add. The goal is to make things work the correct way, efficient and easy to use for the 250 users across the factory. I started using offscreen windows instead of blocking the current layout because for my work I found this method more flexible also if a little slower; but also if windows were flashing right in the middle of the screen (this happened to be in the past) almost no one would complain about them.

    This to say that best practices may vary depending on the task to be accomplished, maybe this is just a wrong impression due to my lack of experience with good designed solutions, but in the situation I just described I use offscreen windows as a valuable method that makes my work easier because script and calls to them are more flexible and I have not to worry about changes that they could make to the remaining of the application state.