Disabling New Window

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…

  1. Via the New Window script step
  2. Via the Go To Related Record script step
  3. Manually via Window > New Window

…and it’s this last option that can, depending on circumstances, be problematical.

2019-02-23_13-06-51.png

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…

trigger-close-new-window.png

…and invoke it any time a new window is spawned by attaching it to OnWindowOpen.

2019-02-24_14-03-15

(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: I didn’t realize, until Paul Jansen mentioned it in his guest article last month, that Go To Related Record (w/ New Window) was exempt from OnWindowOpen… but it is, so the above warning about making sure to proactively assign a window title when you run the New Window script step does not apply to Go To Related Record.

8 thoughts on “Disabling New Window

  1. Jonathan Fletcher

    I’m confused, Kevin. Why not simply this:

    If [ GetAsNumber ( Right ( Get ( WindowName ) ; 4 ) ) < 0 ]
    Close Window [ Current Window ]
    End If
    Exit Script

    What am I missing?

    Reply
    1. Kevin Frank Post author

      Hi Jonathan, not sure if I understand your question correctly. I could have of course written the test in any number of ways, but the main idea is to allow the developer to spawn a new window, but disallow it for regular users, hence the first If branch.

      Reply
    2. Nicholas Orr

      Jonathan,

      The bit you’re missing is that in your example, if you’re logged in with full access, the window will close ( as it meets your If criteria ), and Kevin didn’t want it to close. The only way to get what you’re expecting would be to do, in a single If step would be to do :

      If [ ( GetAsNumber ( Right ( Get ( WindowName ) ; 4 ) ) < 0 ) and ( not AccountIsFullAccess ) ]

      which I'd say isn't as clear as the original example Kevin has.

      Cheers,
      Nick

      PS substituted in my favourite custom function there too.

      Reply
  2. Jonathan Fletcher

    My point is that having the first branch is not needed. The only thing you want to catch is the one condition where there is a duplicate window. All other conditions will result in allowing the window to exist.

    Unless you were going to do something special for the Full Access users, it’s not necessary to have that branch.

    I was curious why you thought it was necessary to test for Full Access and then do the same thing that will happen if NEITHER criteria is met.

    Not trying to be obtuse here (not workin’, huh?) but it seems to be extra typing that does nothing.

    Reply
    1. Kevin Frank Post author

      Well one of us is certainly not catching the meaning of the other.

      > Unless you were going to do something special for the Full Access users, it’s not necessary to have that branch.

      I am doing something special for [Full Access] users… I am allowing them to manually create new windows.

      The example you posted doesn’t accommodate that. What am I missing?

      Reply
      1. Kevin Frank Post author

        Bear in mind that when a script spawns a new window the trigger is going to run — hence my admonition in Note 1 near the end of the article to make sure to assign a window title, so that the trigger script won’t see ” – 2″ and therefore will not close the window.

        Reply
  3. Darren Terry

    This is a really cool technique, Kevin. Thanks for putting it together, and thanks for considering how to let a Full Access user spawn a new window manually with impunity. I can assure you that I would have locked myself out of manually creating new windows and then kicked myself for doing so (and then going back into the script to add the Full Access test you included with prescience). Good job!

    Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.