ON LayoutKeystroke will work in your modal window. See layout setup...|Script Triggers
Excellent! Thanks, Phil!
Here's the code I came up with to run:
If [ Exact (Code (Get (TriggerKeystroke) );13) or Exact (Code (Get (TriggerKeystroke));10)]
#ENTER = 10, RETURN = 13
Perform Script [ “Filter Window Close”; Parameter: "OK" ]
Else If [ Exact ( Code ( Get ( TriggerKeystroke ) ) ; 27 ) ]
#ESC = 27
Perform Script [ “Filter Window Close”; Parameter: "Cancel" ]
Exit Script [ Result: 0 ]
One last little aspect, though: how can I handle the CLOSE window widget? Putting a trigger on modeexit or layoutexit wouldn't know HOW it was exited. Unless there is some way of polling for the OS UI's widgets...
Yeah, I suppose that we could just remove that functionality all together, and force them to use the buttons (or the new keystroke checks).
There's no need for using the Exact function here.
Code (Get (TriggerKeystroke) ) = 13
will give you the same results as Exact (Code (Get (TriggerKeystroke) );13)
If you have FileMaker Advanced, you can install a custom menu for you window's layout that replaces the standard close window with a call to the close window script and you can specify a parameter to be passed to it.
If you have Filemaker Pro 12, you can also set up a trigger in File Options that is performed each time a window is closed. That script can check to see if the closing window's name is the name for this window and if so, do what you need to close the window with either an "Ok" or "Cancel" result.
Actually, I ran into problems if I didn't use Exact (or something equivalent). Other key presses (such as "e" = 102) would trigger this script (matched on "10"), and fall through to the OK section, without using Exact. Maybe that was because of something else I was doing? The Exact() wrapper was the only thing I did differently.
Thanks for the pointers on windowing options. I will look into those.
That should not be the case. Code returns a number and pressing "e" will not make
Code (Get (TriggerKeystroke) ) = 10
a true statement. 103 will not equal 10 nor 13.
And I've used this code extensively on a layout where I wanted to have a 'smart tab' where pressing enter or tab jumps the focus to a different field than the default order when the user context can benefit from such a "jump".
Hmmmm...it is as you say. I retested and things worked without the Exact() code. I swear that I had tested and stepped through the script and saw the odd behavior before. Oh well.
Mind you that there's nothing incorrect about using Exact, it's just not needed in this situation and when I see something like that, I comment on it in case there's an underlying issue that might be keeping things from working for you.