Tab switching has always been a bit hacky, with setting the techIndex/resourceIndex/whateverIndex to -1 when a tab was inactive to prevent updates. This may have seemed sufficient in 2010, but has lead to a lot of edge case bugs and complicated code. It’s long been on my clean up list.

Recently I realized there is a bug around this - if you select a unit, go to another tab, go back, and update something on the unit, and then switch to another unit in the list, that update is lost, because the unitIndex is still -1. This is confirmed in both the latest update and 1.20 (although only with JavaFX lists; still, I would not be surprised if it affects Swing lists as well). I am not sure how far back this goes, but given the fragility of this area, it could be years, perhaps forever.

The fix is to make this resilient. In particular:

• Always just ask the list what the selected object/index (for Swing lists) is. Both for loading, and for saving.

• Always save the data when selecting a new item, or when going to a different tab.

• Always load the data when going to a tab. This will also remove complexity where right now tabs are trying to keep other tabs up to date. E.g. when we add a resource, we’re updating a zillion tabs so the resource list remains accurate. If we simply re-initialize the data on the tab (including lists that refer to other tabs) when opening the tab, that is much simplified.

  • This may even wind up being more efficient, if the user never revisits the tab. Even if not, the cost in performance is quite low compared to the complexity of the current approach.

• After this update, Save will only have to ask the current tab to save its data, rather than how it currently asks every tab to save its data. This will be simpler and more efficient.

• This will also likely make multi-BIQ support much easier. If you load a BIQ, all you need to do is re-initialize the current tab, and the other tabs will already be updating themselves when activated.

However, it is still a significant refactor.

‌