There are a number of techniques that you can consider:
a) You can save the name or number of the previous layout in a global field or global variable. Such a field or variable can even store a series of names or numbers in a list as a "trail of bread crumbs" that allow users to retrace their steps through a series of previously visited layouts.
b) you can "preserve" found sets through a number of techniques.
1. You can open a new window when the user needs to see a different "view of the data". When the user closes that window, they are returned back to the previous window and it's found set, current record, scroll position is unchanged.
2. You can "hide" window not currently in use by moving it to a set of negative coordinates to reduce "window clutter".
3. But multiple windows can get pretty ugly on windows systems, you may want to use a different approach
4. You can set up two layouts that are based on two different Tutorial: What are Table Occurrences? that have the same data source table. If you do, the found set, current record and sort order on each layout will be independent of the other.
5. You can "save" a found set by storing a list of the records' primary key values in a field or variable. You can then use a relationship with a field loaded with that list and Go to Related Records to recreate the found set (though you'll then need to sort them.)
6. You can "clone" a found set to another layout and/or window using Go To Related Records. The trick is to specify the current layout's table occurrence as the "table" and specify "show only related records". Your specified layout need only have the same data source table in common with your starting layout for this to work.
7. If you put the primary key of the current record into a global field that you set up as a match field in a self join relationship to another occurrence of the layout's table. You can "save" the current record to it and then Go to Related records with out the "show only related..." option can be used to make that record the current record once again, scrolling the window to bring that record back into view.
8. If you use the scripted find techniques shown here: Scripted Find Examples, your most recent find criteria is already stored in global fields and you can run the script again to recreate a previous found set. You could even copy that criteria into a table as part of a "bread crumbs" set up where you use the global field or variable from a) to get back to the layout and this save criteria to then recreate the found set.
I currently use a "tab" setup that act as buttons that switches layouts between different types of records. However, once you move off of the current layout and found record set, if you go back you are shown all the records of that type again. Could I instead give each of these tabs separate windows that have IDs, and the tab button instead switches between windows and moves windows around using coordinates? I wasn't aware window coordinates could be specified, but that seems like an interesting option. This would be an interesting first step.
However, once you move off of the current layout and found record set, if you go back you are shown all the records of that type again.
This is not necessarily the case. It depends on the design of your layouts and what your users and your scripts do to manipulate the records that make up a found set. In fact, I would not expect to "see all records of that type" like this upon returning to the layout unless some other user action or interface design feature interfered to change the found set.
Phil: What I meant by that is that in my design, each tab button runs a script that filters for a particular type of record and displays it on the appropriate layout. If you hit another tab button it displays a different type of record on the appropriate layout. If the tabs switched between different actual windows, this would retain their states rather than refreshing them every time a tab is clicked.
Yes, or you can use two different layouts, each based on a different occurrence of the same table.
Switching layouts is much less cumbersome and clumsy than switching windows, I have found after some experimenting. However, when I switch between layouts the scroll bar position resets. I'm guessing I can't avoid this, can I?
Unlike changing windows, you can't avoid this, but you might be able to mitigate the result:
If you put the primary key of the current record into a global field that you set up as a match field in a self join relationship to another occurrence of the layout's table. You can "save" the current record to it and then Go to Related records with out the "show only related..." option can be used to make that record the current record once again, scrolling the window to bring that record back into view.