Perspective Dock Overrides

Ignition
1

I have a project with a LeftDock configured in “Shared settings”. My goal is to create a new “section” that will use a different Dock.

My impression was that if you add a dock to one of the pages, it will “override” the shared Dock and come into view. This doesn’t seem to be the case. If the dock is in Shared settings, it’s the only dock that will ever show.

(The ‘Corner Priority’ for a page does override shared settings).

Am I missing something or is that the intended function?

Ignition 8.0.13-rc2

2

Never mind. I did some more testing with Dock Close and Open page events.

I see that if you close one dock and open another when a certain page comes up it accomplishes what I was intending.

3

Let’s use an example to describe the expected behaviors:

  • In the “Shared” Page Configurations, let’s say we have a north-oriented Docked View which uses a View named “StaticTop” which is set to “visible”. This Docked View will be used for EVERY Page I configure within the project, and since it is set to “visible” it should be visible immediately.
  • I also have an individual Page Configuration for a page (/demo) where I don’t want “StaticTop” to be used for some reason. I configure a different north-oriented Docked View: “OneOff” which I also set to be “visible” because I always want it to be seen.

Using this example, when I navigate to /demo in a Perspective Session I’ll actually see StaticTop because we have two Docked Views set to be visible, and StaticTop was assigned first.

There are two ways to resolve this:

Correct way:
In the /demo Page Configuration, make an additional Docked View with a North orientation which uses the “StaticTop” View, but set this Docked View’s “display” setting to “onDemand” and set the “handle” property to “hidden”. Leave the OneOff Docked View as you’d like it.

Alternate Route:
As part of the View onStartup for the View which you do not want the StaticTop Docked View displayed, you can include a scripting call to close the StaticTop Docked View.

There are a couple fo reasons this method is not recommended:

  1. You might use this View on other Pages, where it would also close the StaticTop Docked View. You should never put anything in a View onStartup script which you don’t want to happen every time a View is opened.
  2. You have a hard-coded id in the closeDock function call, so if the Docked View’s id ever changes you have to go and find this script and update it.
4

Thank you @cmallonee for the great clarification!

I definitely see the advantages to do it the ‘correct way’ when you just want a ‘one-off’ dock change.

In my instance, I think I need to stick with the alternate route because when I open the ‘section’ homepage, I need that sections menu to stay visible and the only route back is to navigate back to the ‘root’ homepage, where the main menu will again become visible and stay visible.

5

@cmallonee Thank you for the explaination. But i find the behaviour a bit counter intuitive. Since only one Dock view can be seen at the time, it will be better i think to says that the rather than the first assigned, the latest visible assigned one is visible. When you define for instance a north-oriented Docked view in the Shared settings and, on a certain page, define again a north-oriented Docked view, the intention is clearly to override the one devine on the Shared view.
It might also be interesting to be able for a page to override a shared docked view by defining on the page a docked view with the same id. so if found the page docked view of page is used otherwise the one of the shared view.

6

For this behavior, you should "override" the "first" docked view with a local definition which declares that the docked view should be visible on-demand, and the "second" docked view should be visible immediately.

While it's easy to say "this is the way it should be", you have to recognize that some of these behaviors were put in place years ago - well before some use-cases were even dreamed of. We can't just change the behavior now because users have immense projects built around this old behavior which does indeed work, even if it doesn't suit everyone's expectations; to change it now and swap the order of which docked view is used would greatly impact other users.