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.
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.
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.)
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.
Okay, what about checking for record lock and, if present, switching to the other window, committing, then going back?
Kludgy, but ...
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.
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
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!
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.
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.
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.
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
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.
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.