Let me try to explain the situation.
Whenever you move the data sheet to a different row, it sends out a message to every other window in the database about this. If it is a form window, that message gets passed to every object within the form. Each form object will respond as necessary, usually be redisplaying itself if the object contains database data. However, if you are using a Text List or Matrix that is linked to the database with the Navigation option, the response will be to change the displayed selection.
The same sequence happens if you use a Text List or Matrix navigate to a different row, for example clicking on a different row. In that case, the Text List or Matrix sends the message all around, including back to the data sheet.
In all of these cases the original source of the message is an Apple structure called an NSTableView. NSTableView is the engine that powers grids in macOS, so each data sheet, text list or matrix has an NSTableView structure associated with it. NSTableView can send out a message whenever the selected item change, and Panorama takes that message and routes it around Panorama as I described above.
The problem occurs because NSTableView sends out the same message whenever the selected item changes, no matter what the original reason was. It could be because it got clicked, or it could be because programming code changed the selected item. There’s no way to tell the difference, the message is ambiguous.
So, let’s suppose there is both a Data Sheet and a Text List open. You click on a different row, which send a message to the Text List telling it that the selected record has changed. So the Text List changes the selected item in the list, which causes a second message to get sent back to the Data Sheet. These messages continue bouncing back and forth, causing a beachball. For some reason they don’t continue infinitely, but they do make the database very, very sluggish.
I have spent a lot of time trying to figure out how to break this loop, but so far I have not been able to do so. As far as I can see, the Apple API doesn’t provide any way to tell which table view originated the change and which one is just responding to the change. It makes sense that Apple never addressed this because who would design their software with two (or more) table views synced together like this?
So long story short - I think it’s fine to have both windows open at the same time - until you start navigating to different records. That’s where the problem occurs. So as long as you close the first window before you start moving from record to record, you should probably be ok.
I have been opening an intermediary ‘Empty’ window so that a window is always open and it seems unnecessarily awkward.
The empty window is unnecessary. If the Data Sheet is the only window open in that database, simply use makesecret instead of closewindow. Then you can open the form window (you might need to use setactivedatabase after makesecret, I’m not sure if that is required).
It used to be that we could open a window offscreen with negative parameters using the OpenForm options for the position of the upcoming window. Alas that does not work any longer
If that doesn’t work any more it’s because macOS no longer supports off screen window coordinates. There’s nothing Panorama can do about that. Anyway, opening the window off screen wouldn’t solve the problem I described above. Even if a window is off screen it is still going to receive the messages about updating when a new record is navigated to, and you would still have the beachball problem. So better to use the makesecret technique I described above.