13 Replies Latest reply on Jan 27, 2012 2:42 PM by Vaughan

    Trapping User Window switching?


      Hi Folks:


      Has anyone come up with a good way to keep tabs on what Window a user has come from as they click on another window in the scope of Filemaker?


      I.e. the user is on Window A, and clicks on Window B (maybe in a field on window B, maybe just anywhere on the window). Can I tell somehow that the user just "came from" Window A when they click into Window B?




        • 1. Re: Trapping User Window switching?
          Stephen Huston

          Hi Lee,


          You pretty much need a script running at the moment they change windows (before they click) to capture this info.


          I have heard from  developers who have kept a looping script running to feed back such info in tightly-controlled navigation systems, but I've never tackled locking down a system that thoroughly.


          If your concern is that someone may change windows during a paused-script period, you could test and refocus the script on the correct window so that when the Resume/Continue kicks in they are returned to the correct window by name.


          If it's more general than that, or you're trying to build a "back-button" system, that's a major can of worms. There have been threads on back-buttons before which would be worth reading.

          • 2. Re: Trapping User Window switching?

            Hi Stephen:


            I'm trying to tackle something more general.  I know how to lock down a window while a script is running, but that's not my goal.  I've been asked to make our system essentially a "Two-Window" system to allow users to use two 17" monitors to view and manipulate their data at the same time.  As you alluded to, this is a bit of a challenge in the scope of how Filemaker works.  The biggest problem is that each window behaves more or less like a separate user from a record locking perspective. What I am trying to do is to insure that any edits are saved on one window, should the user switch to the other window and vice versa.




            • 3. Re: Trapping User Window switching?

              Lee -


              Butting in a bit ...


              What about saving the current window name in a variable, then checking the current window name in a trigger when a sensitive operation is performed? (I'm assuming both these windows are created from the same file; otherwise, the variable idea doesn't work.)



              • 4. Re: Trapping User Window switching?

                Hey Mike:


                Butting in is what we're all about here. lol.


                The problem is I need to make sure that the Window that is being left is left in a "Saved" state, BEFORE the user gets to start interacting with the other window.  I may have to put the window into a modal format to accomplish this, but I'd prefer not to do that, as it makes for a "icky" interface in this day and age.



                • 5. Re: Trapping User Window switching?



                  Okay, what about checking for record lock and, if present, switching to the other window, committing, then going back?


                  Kludgy, but ...



                  • 6. Re: Trapping User Window switching?

                    Has potential, the trick is where/when I could check for the lock.


                    The lock is the reason I have to go through this.  Filemaker generates the lock warning as soon as the user tries to edit in the second window, but I'm not sure where in the event loop, I can "grab" that event.  I'll have to go experiment a bit.

                    • 7. Re: Trapping User Window switching?

                      Hey good call Mike:


                      You didn't get the exact answer, but it got me looking in the right direction.  Here's what I've got so far.


                      I can use the OnLayoutKeystroke trigger to trap the user going into a field.  In the script trigger, I'm doing this:


                      Set variable $$new_window = Get(WindowName)

                      If $$old_window<>$$new_window then

                           We have an attempt to edit on a new window.

                           Do what we need to do on the old window.

                           Set variable $$old_window=$$new_window

                      End if


                      Now I have to see if doing "something" is possible without buggering things up and getting the user back to where they were aiming to go.  But it's a start!

                      • 8. Re: Trapping User Window switching?

                        Well, it was looking good until I started testing Pop-up menus.  The keystroke trigger doesn't fire on those.  I tried setting an individual field level trigger, but none of them fire before the Record Lock message.  It's close, but not quite. 

                        • 9. Re: Trapping User Window switching?



                          You might try an onobject enter trigger.  If the window names are fixed you script can select the other window, commit the record then switch back to the active window.


                          Bruce Herbach

                          • 10. Re: Trapping User Window switching?

                            Hi Bruce:


                            I'm experimenting with that, but getting somewhat inconsistent results.  Sometimes, I seem to get the Record Lock dialog first, and other times, it seems to work.  Trying to pin down where it's falling through the cracks.

                            • 11. Re: Trapping User Window switching?



                              Another approach,  might be to use an ontimer script in each window.  The script would check the global variable to see which window is active,  if it is the other window,  do a committ the inactive window and set a variable to show that the committ has been done.  It should do a check to see if a committ has been done,  if so just exit.


                              If the current window is active,  the script should clear the variable that shows a committ for the window has been done and then  exit.


                              You will have to experiment to see how often these scripts should run,  As an initial thought try 2 or 3 seconds.  Once the committ has been done in the other window or if the current window is active,  the script esentially starts and exits,  so load should be light. 


                              You may still get the dialog that a record is in use,  if the user starts a change and then moves to the other window, jumping into a field before the ontimer script in the other window activates again.


                              I know this is getting to be a bit complex...  So a simpler approach might be to add a script/button to each window that switches to the other window and train the users to click the button when changing window.  The script would committ the record and make the other window active.  


                              Hope this is helpfil


                              • 12. Re: Trapping User Window switching?
                                Stephen Huston

                                What Bruce suggested of placing a button in each window to go to the other window can actually be pretty simple.


                                In each file it can call a script to commit the current window and then that local script calls a script (if these are separate files, call a script in the other file's window) to focus in the new window and close the previous window by name, if you want them to see only one window at a time. Don't close it if they are supposed to see both, but then you cann't really control the navigation to the buttons.

                                • 13. Re: Trapping User Window switching?

                                  After opening the window, trap the Open Record script step to determine whether the record is locked (an onRecord or onLayout trigger might be good to automate this). Then either issue an alert (or close the window and issue and alert) if the record cannot be opened.