"Current Window" means "active window". If window A is active, then window A will be closed. It's doing what you told it to. Probably not what you wanted it to, but we've all had that happen.
Hi Mike -
Thanks for the reply!
In .fp7, clicking on the close window button of a given window makes that window the current window if it is not already the current window.
In .fmp12, clicking on the close window button of a given window does not make that window the current window if it is not already the current window.
The behavior I would expect intuitively, and because it was so in .fp7, would be for the window that you click in to become the current window regardless of where you click in that window.
I'm OK with this not being a bug if that is the case. I too am a developer and understand that what one person sees as a bug is actually an intended behavior. Does anyone have any suggestions as to how to handle this when there are multiple windows open and you want to script the Closing of windows?
I'd suggest using the WindowNames function (which lists the windows in order of their stacking order). That, in combination with Get ( WindowName ) ought to allow you to parse out which window the user is working in. As you noted, Get ( WindowName ) returns the name of the window the user attempted to close; perhaps explicitly closing that window instead of Current Window might work better.
Never had to do it myself, so those are just some ideas off the top of my head. Probably have to play with it.
The problem with Get(WindowName) is that it only returns the name of the window the user attempted to close when viewed in the "Watch" list in the Data Viewer. If you call Get(WindowName) from inside the script it returns the name of the last active window which is NOT the window the user is trying to close in the example.
Get(WindowName) literally returns different values at the same time depending on where it is called from.
Then I suggest you change strategies. Instead of trying to trap a closing window using a custom menu, use the OnLayoutExit Script Trigger. This occurs before the event and you can run your script at that time.
Adding to Mike’s suggestion, ALWAYS name your windows. If you do, then you can deal with them by name, which I find much easier. Use the WindowNames function to get a list of windows. That way you can control the closing of the main window.
There is a difference between the functions Get(WindowName) and WindowNames.
Look at these two functions in the FileMaker Help file to understand the difference.
Best wishes - Alan Stirling, London UK.
+44 (0) 20 7724 2456 - firstname.lastname@example.org - www.ast.fm.
FileMaker Certified Developer for versions 7, 8, 9, 10, 11 and 12.
I think there may also be an OS issue here, not just an FM12 one. In the most recent couple of versions of Mac OSX (not sure when it began) it has been possible to close a window other than the active one by clicking the red "close" button in the top left corner, even if that window belongs to another application (eg. I am looking at a Safari window as I type this, but am able to close an Acrobat window partially visible behind this one). Since you mention clicking on the X in the top right corner, I assume you are working on a Windows machine, but maybe the same functionality exists in the latest iterations of Windows.
If I am right, then your use of a script on closing a window will cause a conflict between OS behaviour and FMP behaviour; the OS will be trying to close a window WITHOUT making it active, but as it closes your script will fire and try to close the ACTIVE window. You could test this theory by disabling your script and see if the problem goes away. If it does, then a change of strategy, as suggested by Mike, should put you right.
Hi Tim -
I agree 100% about the naming of windows. I always do name windows and almost never use the Close Window script step with "Current Window". I just felt it would be easier to make it simple, for the sake of the post, to use Current Window.
You are correct. I am primarily Windows since most of my clients Windows users.
I would agree with you about the possibility of an OS issue except that FileMaker 11 on the same computer, running the same script, performs differently in that it actually does close Window B as one would expect it to.
WindowNames was brought up several times in this thread so I ran some more tests to see what WindowNames returns by setting a variable to WindowNames in the same step that sets the other variable to Get(WindowName). This returned another peculiar thing.....
WindowNames, as you know, returns the list of open windows in the order in which they are stacked. So, the current window would be at the top of the list of names returned. I expected that since Get(WindowName) was returning Window A when setting the original variable, that WindowNames would return the list of windows with Window A at the top. Not so.....WindowNames actually returns, what I would consider, the correct order of the windows in the scenario above and has Window B at the top.
So, it seems that I can use GetValue(WindowNames; 1) in lieu of Get(WindowName) to get the name of the window that is being closed by the user.
I may also play with the OnWindowClose script trigger a little bit to see if that works out too. The only problem I see with using the script trigger is that the script in my actual solution does things before AND after the window is closed. The script trigger runs BEFORE the window is closed only.
Thanks all for the replies!