Object Viewer / Open Object Dialog: (1) Treeview expand stability, (2) Data Tab stability / 5999 Bug Number: 2nd (of two) parts of 5999, plus related stability enhancements Release notes (y/n): Yes For Release Nums: 7.2 (maybe 7.1.3 in the future). This commit contains a couple "stability" fixes for the Object Viewer, and its interaction with "torn off" Open Object dialogs. One of these fixes was the 2nd (of two) parts of Gnats 5999: (1) Stable vertical scroll position (in the various list tabs) with respect to individual Object Tabs -- DEFERRED. (2) Stable treeview expanded/collapsed states with respect to individual Object Tabs. Regarding the part of 5999 that is being addressed here (#2), switching to a different object tab always closed all treeview controls in the following data tabs: (1) Slots (2) Methods (3) Account Methods Treeview items which can have an expand/collapse treeview control include: (1) Element Objects (in an Aggregate Object) (2) Method-Dependent Slots (on the Methods tabs) (3) Method-Dependent Slots under an Element Object (on Methods tabs). (4) Slot Groups. (NOTE however that THESE did have stability). This treeview expanded/collapsed instability was ALSO A PROBLEM when undocking and redocking Object Viewer object tabs to/from single-object Open Object dialogs. The solution provided by this commit also addresses that deficiency. In the Object Tab undocking and redocking functions, ANOTHER INSTABILITY was identified and addressed. The undocked or redocked object always reverted to the "Slots" data tab (i.e. even if some other data tab was selected, i.e. "Methods", "Accounts", "Accounting Methods", "Attributes", or "Description"). This instability has also been addressed. The undocked or redocked object retains the original object's data tab selection. ------------------------------------------------------ TECHNICAL (1) -- Treeview Expanded/Collapsed Stability ------------------------------------------------------ This stability was implemented at a level BELOW the application uses of multiple levels of items. At the appropriate times, we record which QTreeWidgetItems having multiple child items were Expanded (rather than Collapsed). This makes use of a specially constructed "hash" string made up of the name text for a QTreeWidgetItem AND all of its parent items. This is done for the "Slots", "Methods" and "Account Methods" tabs using these static QMaps: typedef QSet StringSet; static QMap _expandedSlotListItemHashSetMap; static QMap _expandedPhyMethListItemHashSetMap; static QMap _expandedAccMethListItemHashSetMap; Each time a SimObj is "installed" into the OpenObjectDlg's widgets, we record which treeview items had been expanded in each of those three data-tab treeviews (for the formerly installed SimObj), and then apply the save expanded states for the newly installed SimObj. (Note that the OpenObjectDlg class implements BOTH the Object Viewer and the Open Object dialog). Since those three QMaps are static, their data is available to the Object Viewer and all Open Object dialog instances. The saving of the treeview expanded states is performed by this first (new) method. The reapplication of those states occurs at the end of the second method: (1) void OpenObjectDlg::saveTreeViewExpandedItemHashSetMaps (SimObj* refObj); (2) void OpenObjectDlg::installSimObj (SimObj* refObj, bool force=false); This makes use of these new utility functions -- in RwQt4Utils. These could be used to implement treeview open/closed stability in other QTreeWidgets, as long as the distinguishing "names" of items can be taken from one particular display column at all levels of the tree (which is typically the case): QString RwQt4Utils::treeWidgetItemPathHash ( const QTreeWidgetItem& refItem, int nameCol); QSet RwQt4Utils::expandedTreeWidgetItemHashSet ( const QTreeWidget* twid, int nameCol); void RwQt4Utils::expandTreeWidgetItemsFromHashSet ( QTreeWidget* twid, int nameCol, const QSet& hashSet); ----------------------------------------------------------------------------- TECHNICAL (2) -- Object Data Sub-Tab Stability when Docking/Undocking Objects ----------------------------------------------------------------------------- When docking or undocking an object into or from the Object Viewer, the object data-tab selection (Slots, Methods, etc.) is set on the "receiving" Object Viewer or Open Object dialog. Note that the process of docking or undocking an object CAN RESULT in the deletion of the source dialog -- so the determination of the object data-tab selection in the source dialog (i.e . the tab's label text) must be put aside in an automatic (stack, local) variable. This process makes use of these two new "Main (data/list) Tab Support" methods. (Note that these tabs were the OpenObjectDlg's original "main" tabs -- hence the "MainTab" semantics. These are now effectively subordinate to the Object Viewer's new object tabs). (1) QString OpenObjectDlg::currentMainTabLabel() const; (2) void OpenObjectDlg::selectMainTabByLabel (const QString& tabLabelStr); --------------- ADDITIONAL FIX: --------------- When the Object Viewer has more tabs than can be simultaneously visible (i.e. when the Object Tab Bar has horizontal scroll controls), it's possible for the Tab of the currently "installed" (shown) Object to be scrolled out of view. We had implemented the side effect of clicking the Object Type Icon Button of rescrolling that object's Object Tab into view -- i.e. in addition to the effect of selecting that object on the RiverWare Workspace. However, clicking that object icon button was causing the object data list (e.g. the Slots list) to FLICKER. That flicker has been eliminated. ---