I'm just starting with the XamDockManager, so hopefully I'm not asking the obvious here. Is there any way to "lock" the layout? For example, let's say the user has the layout just like he wants, and wants to make sure he doesn't move things around by mistake (so easy to do... - e.g. double-click a title bar by mistake and suddenly the pane is floatong.) Essentially I'd like to be able to prevent people from moving/docking/whatever the panes - lock them all in place, but also I want the option of letting them revert to the normal behaviour of the dock manager (a setting would allow them to lock/unlock at will.)
Thanks,Michel
There is currently no single property that would disable all customization of the layout. There are properties on the ContentPane clas for allowing/disallowing all the various actions (AllowDocking, AllowPinning, etc.) and there are events raised as actions are about to occur. So there are a couple of things you could do. You could store the "unlocked" values for all of these properties on each pane when you are locking the layout, set all the appropriate allow properties to false, and then restore the saved settings when going back to the unlocked state. There is a GetPanes method on the XamDockManager that will return an enumerator you can use to access all the ContentPanes. If any panes are added programatically while in this unlocked state, you would have to handle initializing them as well.
Another option would be to hook the ExecutingCommand event of each ContentPane and set e.Cancel to true for any command that you don't want the user to be able to perform. All the commands that a ContentPane deals with are defined on the ContentPaneCommands class. In addition, you would probably need to handle the PaneDragStarting and set cancel to true. The downside to this approach would be that the various contentmenu and caption buttons would still be enabled.
You should also submit a feature request for this behavior to be built into the control.
Thanks Andrew. I gave that a quick try this afternoon, and it more or less works. The little "gizmo" (down arrow on the left of the pin) stays enabled even though it's empty - not a major concern, but it looks weird. I was however able to move a pane around within the split pane that owns it (but not to the document host nor other split panes.) Not sure if there's any way to disable moving the panes (i.e. by dragging them using the title bar) altogether?? I still need to experiment a little bit with various arrangements, to make sure that it otherwise does what I want.
I've submitted a feature request for this as well. The xamDockManager is a great way to quickly layout an application, but I would like all user ability to rearrange it removed and there is no easy way to do this. A single property on xamDockManager that removed all the UI for interactive layout (context menus, icons in headers etc.) would be great.
Andrew Smith"]The Window Position menu's visibility isn't currently tied to the presence of items - actually the items are generated on the fly and we raise an event (OptionsMenuOpening) so you could add items to it before its dropped down so I'm not sure we could automatically hide it. We could probably add a property in a future version that we use to bind that element's visibility to provide a way to turn it off without retemplating.
The Window Position menu's visibility isn't currently tied to the presence of items - actually the items are generated on the fly and we raise an event (OptionsMenuOpening) so you could add items to it before its dropped down so I'm not sure we could automatically hide it. We could probably add a property in a future version that we use to bind that element's visibility to provide a way to turn it off without retemplating.
OK, that explains it. I don't think it's much of a big deal, but I'll find out soon enough when I show off the prototype. :)
With regards to dragging within its split pane, cancelling the PaneDragStarting should have prevented any dragging whatsoever (except moving the floating windows). If you're cancelling that event and are still able to move the panes then I would report that to the support group.
Sorry, that was my mistake - I completely forgot to handle that event - it works as expected if I handle it and cancel. I now have the functionality implemented for locking/unlocking the layout and it works great (well, with the limited testing I've put it through anyway. :))
Thanks for your help!Michel