Not sure I understand, but I think I understand enough of what you're trying to do.
With a click on "Cancel", you run a script you refer to as a "Halt Script"
You want something new to happen if you hit OK...Have the OK button run the new script to commit records, close the window, gotolayout (based on calculation).
It seems that your new window with the buttons is a two-choice path with both triggers sitting there ready for use...just use them.
If this is your hold-up...check out the Get (LastMessageChoice) script function to discern between the two buttons.
Also, do you need to carry over any information from one window to the next? (variables are awesome)
I mean sounds like you just need a couple of properly placed close window and open window scripts is all. However, the order of firing the scripts and where they fire is what will make it all work for you. Just a little tricky to think it out, but not hard at all to do. If you want I can take a quick look at what you have.
To halt the infinite loop, you can just make Halt Script the final script step in whatever scripts you connect to the buttons in your floating window.
Thanks for all the suggestions, but perhaps I wasn't being clear. I can easily have two buttons in the floating window, one to discard entries and one to commit them. In the former case, I can just Halt Script at the end to close the floating window, halt the infinite loop in the invoking script, and return the user to the original layout. In the latter case, I would like to commit records, close the floating window, but return to the user on a different layout.
The method is the same. Put your script together to select the original window, go to the different layout, then select the floating window and use the same steps that close the window for the other button to close the window and conclude with a halt script step to end the infinite loop.
Thanks again all. Things seem rather simple after the fact here. In the script that saves the record, I have it
Go to Layout
all is well.
Not exactly sure the purpose of the infinite loop
The infinite loop is a trick for making a new window simulate a modal dialog. With the paused infinite loop, the new window cannot be lost behind the original window should the user try clicking on that windows or otherwise interacting with it.
You can find some examples of this techniqe with code to handle cross platform differences in my Known Bugs List database.
I'm beginning to get a sense of the power of this. Any script can open up one or more windows, each with their own window name.
And any script can close a given window, if it knows the correct name.
But is there only one background window with an infinite loop? Does the "halt script" command halt only the one allowed script,
or is there a way to have more than one window with a paused script?
From a design point of view, it seems that it might not be useful to have many windows, particularly if you are
planning on serving a wider network community with potentially small screens.
Actually, as designer and user I prefer not to see "too many" windows open at once. It can get confusing to manage from a user interface point of view and in FileMaker it is especially awkward on Windows systems due to all your windows being displayed from within an Application window that can produce a confusing extra set of scroll bars.
Modal dialogs limit the user to just one active window at a time. You can't interact with other windows without first closing the modal dialog. This method simulates that interface. Thus, you can have multiple windows open but you can't interact with any but the once simulating a modal dialog until you close it.