Object Viewer Obj Tabs and OpenObj Dlgs: Stable vertical scroll pos in item list subtabs [5999] [2]
Bug Number: 5999 (part 1) (part 2 was previously addressed)
Release notes (y/n): Yes
For Release Nums: 7.2

Followup. There were some circumstances where a not-completely initialized 
QTreeWidget vertical scroll position was being saved over the previously saved 
position (for that Object and sub-tab, e.g. "Slots", "Accounts", etc.) AND 
some other transitional states which were not being handled correctly.

All changes are to Q3GUI/OpenObjectDlg (.hpp and .cpp).

(1) Method OpenObjectDlg::selectObjTab (SimObj*) -- because of an apparent bug 
in Qt 5.5.1, the QTabBar isn't scrolled to the specified index IF that index 
is already the QTabBar's current index (but is scrolled, horizontally, out of 
view).  As a workaround (implemented last May) we initially select an adjacent 
tab, and THEN the tab we want.  That initial scroll to some other tab was 
resulting in the scroll position (first visible item) of the desired tab list 
to be recorded.  In certain circumstances (e.g. when adding an Object to the 
Object Viewer), the scroll position hadn't yet been initialized to the 
previously saved value.  So this was overwriting the saved scroll position 
with an incorrect one.

(2) The process of saving all of the sub-tabs vertical scroll positions 
(first visible item) was not happening when the Object Viewer was closed.
Calls to saveTreeViewFirstVisItemHashMaps (SimObj*) were added for this in 
these two place:

  (a) OpenObjectDlg::internalClose()
  (b) OpenObjectDlg::closeEvent (QCloseEvent*) -- for asynchronous closes.

(3) We now explicitly avoid doing scroll position processing for an object 
for which a deletion is currently being processed.

(4) Throughout Q3GUI/OpenObjectDlg.cpp, the five QTreeWidget pointers are 
now checked for NULL before dereferencing.  There is some time, during a 
dialog deletion process where those QTreeWidgets have been deleted, but 
some additional processing in the instance may occur.