One of these applications, I'm embarrassed to say, was one of mine. This was merely a sin of omission on my part, since I have addressed this issue in many applications in the past, but I still felt a bit sheepish when I encountered it. Fortunately, the fix is very simple and is a good practice to get into if you are creating programmatic tabbed tables. Here's the scoop...
As you recall, you can make a programmable tabbed table by selecting the proper settings in the table properties dialog box.
To select a particular row in the tabbed table, you use the $table-name field and set it's value to the appropriate row. The $table-name field is created for you when you name the table and the row value is obtained from the row tag name. Both of these values are defined on the Table Programming tab.
You can see in the picture above that I've called the first tab "Tab1" and subsequent tabs are named in a similar fashion. Thus, at it's most basic, the formula to switch from this tab to the fourth tab in this table would be
@SetField("$NavTable" ; "Tab4");
This is a great feature, since it works in both read and edit mode. A programmable tabbed table has many uses. One example is displaying conditional information. I have an application in which usually only certain tabs should be shown, based on user input. By using a programmable tabbed table along with an outline, I provide a nice method to navigate among the various tabs, skipping over those that are not necessary. You can see an example screen below.
If you look at the document properties for a document with a programmable tabbed table, you'll actually see the $table-name field included with all of the other document fields.
Here's where the (potential) problem occurs. When a user edits the document, the current value of $NavTable is saved. So if I save and close when I'm on Tab4, that's the tab the next user will see when they open the document.
In order to avoid this problem, I simply use the code above in the query save event to set this field back to the first tab. Alternatively, you could reset the value when the document is opening. I needed to do this once when I was retrofitting some functionality into an existing application. Rather than mess with the QuerySave event (which had a huge mess of ugly LotusScript), I simply created a CFD field on the form called "SetTabbedTable". The formula for this field was:
This insured that the user was always presented with the first tab, whether in read mode or edit mode.
Well...that was a really simple tip and I probably provided way more background than you needed, but better to be thorough I say. In any event, this is an easy fix to apply and although it seems rather trivial, remember that the small things add up when we're on the way to user experience nirvana.