Scripted Close Window Bug?

[Matt Klein]

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?

 

 

 

 

[dansmith65]

I would suggest reporting it as a bug.<br /><br />I forget the exact scenario now, but I remember experiencing something similar to this; clicking a control for a non-active window performs the operation on the current window.<br /><br />If you do the same basic test with new/delete records buttons - which window is the record created/deleted in?

[Sydney Shackelford]

I ran into the same issue. I do think it's a bug, but have not heard the official reasoning on this. This happens on both OSX and Windows. I did figure out a workaround. In my close window script trigger I put the following in the beginning of the script

 

If [Get ( WindowName ) ≠ GetValue ( WindowNames ; 1 ) /* If active windows not top window, then abort */]
    Halt Script
End If

 

 

Fortunately "WindowNames" is a design function that displays the windows in FileMaker in the order of how they are layered in a value list. The first item will always be the window on Top. The "Get (WindowName)" returns the window name the user clicked the "X" on. The result is if the user selects the "X" on the back window to close, the halt command will prevent the script from continuing, and will bring the clicked window forward. If the clicks the "X" to close on the front window the "If" condition fails and the script continues as intended. Although it's not the exact expect function, I actually prefere this as this also prevents the user from accidentally closing the back window. I've done than many times with multiple windows in Firefox.

 

-Scott

[Matt Klein]

Thanks Scott!

 

I should have posted an update on this forum.    I found the WindowNames workaround as well.  Strange that it works but Get(WindowName) doesn't in this scenario.  

 

You stated that it happens on both OSX and Windows.   I ended up testing it on OSX to see if it would do the same thing before I submitted it to a FileMaker Engineer.   The results of my tests on OSX showed that it behaved differently on OSX.  In fact,  the script never runs when clicking on the close button on a non-active window, aka Window B in my example.    That is far more disturbing to me than having to work around the Get(WindowName) issue.

 

Anyway,  I'm looking for a workaround for OSX right now.   I may play around with the OnWindowClose script trigger.    I will post my findings back here if I do.

 

Thanks again!

[Sydney Shackelford]

I do use this on the OnWindowClose script trigger, hence the reason for the "Halt Script" command instead of the "Exit Script". The "Halt Script" keeps the window from closing and just puts it in the foreground.

[Matt Klein]

Thanks, Scott.   Much appreciated.  Using the OnWindowClose trigger with your script is a decent solution to making sure the window that the user is trying to close is the active window.  It should also take care of the issue on the Mac where the script assigned to the Close menu item doesn't even run when trying to close a non-active window.

 

They'll have to double click essentially, but it's better than the window closing without the checks and balances or closing the wrong window.