Guess, we solved it.
FileMaker looses the record focus, if in the portal the record being deleted in the child table is the current record in the master table (portal row shows a selfjoin). So we scripted a check, whether the record number in found set is zero after the deletion and if that happens, we set it to the first record.
FileMaker looses the record focus, if in the portal the record being deleted in the child table is the current record in the master table
Hilarious. If you delete the current record via a portal the current record is deleted and filemaker loses it's "focus" because all the meta-data stored in the record is gone, gone, gone.
You might want to store the record number and the portal row number and use them to restore the focus.
I thought FileMaker would just point the focus to the next possible record - I didn´t think it could loose any focus since in form view there is always one record shown, one active record (at least when the database is not empty or you search for something inexistant).
I would tend to think, this is a bug or at least something not very ellegantly thought.
Perhaps I haven't understood what you mean by "lose focus"?
current record in found set = 0
When you think about it FM has always responded to a non-matching criteria with the 0 record in the 0 found set state. I error trap for it in every find, since I don't want my users to feel stuck when what they are looking for is not found. Trapping for it allows me (the developer) to decide how I wish to inform the user of the not-found state of their search and what and how many records I want to return to the found set for them to view so they will not feel lost. So I guess this would be more of an inelegant situation than a bug. Trap for it, force a screen refresh, or maybe even a Commit Records script will help with re-establishing the current record focus, but at any rate you get to decide what happens next when you trap for it.
If you had a found set of 2 records, and you deleted those 2, one at a time, you would be left with a found set of zero, even if there are millions of other records in the table for that layout.
Deleting the local parent record via a self-join portal can leave you in the same spot, with zero found records, depending on your found set. It's expected behavior.
Any time you have no parent record, you should expect to see no child records. Again, expected behavior.
If you want it to do something else, you need to script the deletion and test -- immediately following the deletion -- for a current found set of zero, and then figure out what should happen instead -- possibly a dialog box with a warning and an option to show all records or go into Find mode to search for a new found set.