Here is small development gotcha regarding FileMaker 12 advanced window styles. If you create modal dialog window, and then execute a Go To Related Record (GTRR), creating a new window from the modal dialog, the window style of the new window must also have an advanced style set to modal dialog.
You might want to do something like this if you present a modal dialog to the user and then need perform some off-screen processing in a new window after the user performs an action in the dialog. If the new window is not set properly as a modal dialog, the GTRR script step returns an error 1 (User Canceled Action) and the GTRR does not occur. Seems to me this error message does not clearly lead to an understanding of the actual cause of the error, hence the gotcha.
Step-by-Step
Here are a few screen shots to explain. This first image demonstrates the error that occurs when the GTRR new window is not specified as a dialog:
Now, let’s modify the script and specify a modal dialog for the new window in the GTRR script step:
And when we run the script again the GTRR step can successfully execute:
Documentation
Although the error code is perhaps misleading, this scripting behavior is not undocumented. In the FileMaker’s online documentation of the advanced window style feature does offer an explanation (see second to last bullet point):
Any operations that attempt to open a non-dialog window will fail when a dialog window is open (for example, using a script trigger to run a script from another file). OnTimer scripts do not execute when a dialog window is open unless the script launches from the dialog window itself.
While not totally related to this, I also hit a gotcha with the new modal window style. You can’t put a modal window on top of a floating window. So while the modal window takes over focus from all other windows it will be covered by the floating window. One other thing to keep in mind when playing with the window styles.
Jared, thanks for stopping by and contributing to the conversation. Sounds like your floating window was up first, then the modal. Best practice might need to be to script the placement of the modal, maybe first using Select Window to get the Floater first, recording its position in variables. Then create the modal outside the bounds of the floating window.
I just wanted to add that this is true of any window action you attempt before closing that modal dialog window. So, if you’ve got that modal dialog up for user input on record creation/edit, you cannot select an offscreen worker window that is not also modal, or create a new offscreen worker window that is not modal.
When attempting those actions, you’ll get error code 3, which reads: “Command is unavailable (for example, wrong operating system, wrong mode, etc.)”.
A little more helpful than error 1, but it would be nice if “wrong window style” was in that list. (As this was a couple of subscripts down looking for the offscreen worker window, I spent a bit of time ensuring I was still in browse mode.)
And, while you can change much about a window (name, size, position), you cannot change it’s style. Maybe a feature request?
Hi Lisette. Thanks for stopping by. I would think error 3 would be more appropriate for the scenario I describe. Would be nice to change the style of a window. Hopefully we will get some improvements to this feature in the next version.
This article just saved me an hour – at least. Thank you.
Hi Meg,
That is excellent! Thanks for sharing the feedback. Maybe find a way to pay forward that hour saved 😉
Hi all,
This gotcha, currently gots me. I’m working with multiple files. My script can’t call a script from file 2 because my script opens dialog windows in file 1. Is there a way to accomplish this without closing the dialog windows open in file 1? I put a TO from 2 into 1 and attempted opening a new dialog window and going to that TO, but FM knows I’m still in file 1 and won’t let me run a script from file 2..
Thanks!
Ryan: Oops…I created a new post (below) instead of replying. Didn’t want you to miss it.
Hmmm… I think that FileMaker does not support what you are trying to do:
http://www.filemaker.com/help/12/fmp/html/non_toc.46.53.html
Scroll down to the Script Steps chart down at the bottom. You will see that Perform Script on an external file will fail.
Can you use older techniques such as pausing your script to simulate a modal window?
Thanks Darren. I have slowly accepted what you’re saying is true. I was an early fan of the dialog windows but this is a major drawback (also have to use global variables, which I would then like to clear)! The script in question is meant to be high fan out, and I still want to use the dialog windows when possible, so I think I’m going to attempt to write the script so it uses dialog windows when called from file1 and uses pauses/resumes (floating document windows) when called from other files (haven’t thought this all the way through yet). Does anyone else do this? Or is it too much work with too little reward? Too hacky? Thanks
Edit: I think I meant High Fan In.
Sounds like what you are suggesting is a wrapper script that opens your dialogs based on script parameter. Seems reasonable solution to me. Just try to make it abstract enough that it can be scaled and reused. Like a window management module. Then the extra effort is not just for the one project.
And what does “High Fan In” mean?!?!?
Very nice suggestion, thanks much! I thought I was taught, while learning C, that High Fan out basically means that many other components use a module and low fan in meant that a module used few other components. But I did some reading and perhaps my memory is off. Looks like High Fan In means a module should be highly reusable.. I really like the ‘window management module’ approach, thanks again!
happy to help and thanks for contributing with your questions!
@Ryan Thompson: Open URL allows you to execute code in another file when you have a modal window open. It’s a bit of a kludge and may have compatibility issues with pre 13.0v1.
fmp://*/filename.fmp12?script=scriptName¶m=” & GetAsURLEncoded ( parameterString )
Thanks for this. Really useful to know when using off screen utility windows.