10 Replies Latest reply on Mar 7, 2013 6:22 AM by Matt_Klein

    Scripted Close Window Bug?


      Hi all!


      Admittedly, I am just now starting to work more fervently with FileMaker 12. I was doing just that yesterday when I ran into an odd behavior that may or may not be a bug, but I wanted to get some feedback from the forum members on. ie, has anyone else seen it and how did you deal with it.


      The scenario:


      FileMaker Pro 12 Advanced.


      I used custom menus to script the Close menu item. For the sake of testing, I made the script that the Close menu item calls a single step: Close Window[Current Window].


      Two windows open and visible by the user, Window A and Window B.



      The symptom:


      If the active window is Window A and the user clicks on the "X" in the upper right corner of Window B to close it, the script fires off but closes Window A. Not quite what a user would expect to happen.



      Here's something else that is very strange. I added a step to the Close script that sets a variable to Get(WindowName) just before the Close Window[Current Window] step. I then added Get(WindowName) to the "Watch" tab in the Data Viewer and started the debugger.


      I then reproduced the scenario above and stepped through the steps. After setting the variable, I checked the Data Viewer. The variable held the name of Window A and the Get(WindowName) function in the "Watch" tab of the Data Viewer showed the name of Window B.


      This problem does not exist in any .fp7 version of FileMaker.


      Obviously, selecting Window B first and then clicking it's close button works to close Window B. User could be trained to do that, but it's not intuitive and will lead to windows being closed unintentionally.


      So, what do you think? Is this a bug in FileMaker 12 or intended behavior? Has anyone out there dealt with this?

        • 1. Re: Scripted Close Window Bug?

          "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.       



          • 2. Re: Scripted Close Window Bug?

            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?

            • 3. Re: Scripted Close Window Bug?

              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.



              • 4. Re: Scripted Close Window Bug?

                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.

                • 5. Re: Scripted Close Window Bug?

                  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.

                  • 6. Re: Scripted Close Window Bug?

                    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.







                    • 7. Re: Scripted Close Window Bug?

                      Hi Matt


                      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.



                      Alan Stirling Technology Ltd, 135 Lisson Grove, London NW1 6UP

                      +44 (0) 20 7724 2456 - alan@ast.fm - www.ast.fm.

                      FileMaker Certified Developer for versions 7, 8, 9, 10, 11 and 12.

                      • 8. Re: Scripted Close Window Bug?

                        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.

                        • 9. Re: Scripted Close Window Bug?

                          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.

                          • 10. Re: Scripted Close Window Bug?

                            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!