Providing the Ability to Override Advance Level in UI

There has been a request to allow a workflow to explicitly set the advance level of a View independently of the main Advance Level Control in the top-level View. This override advance level would then propagate down to all children Views until the next advance level override is encountered.

In the current design, the advance level information is actually stored at the UIManager level and not in the Views themselves. This was done to ensure that the current advance level was consistent between all of the Views being displayed.

In order to support this design change, the advance level information will need to be moved into the BaseView class and out of the UIManager. The new api would be:

  • setLocalAdvanceLevels(…)
  • unsetLocalAdvanceLevels()
  • localAdvanceLevels(…) const

This information could be store in the View Configuration and therefore would be persistent across runs. If these methods are called on the top-level view and if it is displaying the Advance UI controls, they would get updated appropriately.

The next step is how this information would get propagated down to the View display hierarchy. One approach would be to add a method to return the current advance level which is either localAdvanceLevel (if set) or its parent’s advanceLevel via recursion. A more efficient approach might be to change the updateUI API to include a version that takes in the advanceLevel to be used as shown below:

  • updateUI() - updates the View (and its children) using its localAdvanceLevel if set or don’t filter by advance level if not.
  • updateUI(int readLevel, int writeLevel) - update the View (and its children) using its localAdvanceLevel if set or using the advance levels passed in if not.

@dcthomp @johnt @chart3388 @waj334 Comments welcome!

Am I following correctly that the “Show Level” combo box in the attribute editor would/could automatically change when the user switches tabs or views? I presume the user could still manually change the combo box if desired.

The show level would still be “owned” by the top level View so it would not change based on tabs - by allowing the designer or plugin explicitly set the advance level for an non toplevel View, they can “fix” the advance level for that View subtree.