FileMaker can seek to a record by its number (using the Go to Record script step), but the problem is how to calculate this number for a known record. I can think of two options:
Can the search you perform be replaced with a Go to Related Record step? Can you, say, make a bunch of global fields and make a relationship from these fields to another TO of the same table, so when enter your search criteria in the fields, the found set you want will appear in a portal? If yes, then you can use these fields to enter the search criteria, then use the List() function to get a list of all matching record IDs, and check if the current ID is in the list and if yes, what is its position. Then you can go to related records and seek to this position to stay on the current record.
Another method would be to add an unstored calculation like that:
ID ≠ $$id
Before entering find mode remember the current record id in the $$id variable. Perform search and sort the records by this calculated field. If the current record is in the found set, this will make it the first record. Go to the first record and unsort the found set; it will restore the ‘raw’ order, but won't change the current record.
I use a variation of Mikhail's approach for this.
Make sure every record has unique serial number field via an auto-entered serial number field.
Before changing the found set, store the serial number of the current record in a global field.
Define a self join relationship that links the current layout's table to a different table occurrence of the same data source table with the global field as the key field for the layout's table occurrence and the serial number field as the match field in the second table occurrence.
Then a GTRR without the "show only related records" option selected will pop you instantly to the same current record as before and your found set will be unchanged--provided the record is still part of the found set. If it isn't, GTRR does the equivalent of a Show All Records before making the related record current.
Phil's technique is better, because it doesn't require sorting by an unstored field, the only downside is that if the target record was not found, GTRR to it will destroy the established found set. But if you can determine whether the record is among found or not, you can then branch accordingly. I'm not quite sure how to do this though… E.g. one can somehow capture the search criteria and use them later to ‘manually’ check if the original record matches them or not.
One option is to have either a second window or a second layout that refers to the same data-source table but a different table occurrence. That different window or layout will have it's own found set, current record and sort order--so sometimes I just freeze the window, switch layouts, process data and switch back.
In this specific case, since you are performing a find, you have criteria--perhaps stored in global fields--that you can compare against your current record before performing the find. If it meets criteria save the serial number to pop to it after the find. If not, leave the global field empty as a flag and check it for a value before using GTRR to pop back to the same current record after performing the find.
I ended up using the following method: I created two table occurances 2 & 3 first I perofrmed a find on the current record and used GTRR (for current record only) and moved it to occurance 2. then I performed the main find and moved it to occurance 3 with related records only. then I used constrain find to the current record ( using a saved serial number) and then I used the IF control to test for the last found count: if zero I restored from occurance 3, if not zero I restored from occurance 2 (without show related records only).
I forgot to say that occurance 2 wath related to the original using a global variable carrying the serial nuumber of the current record and occurance three wath related to the original using serial numbers