This project is read-only.

[Version 2.0] Show/Hide Tool % MVVM

Apr 5, 2012 at 8:37 PM

Hi,

I'm looking for a simple way to have tools listed as checkable menu items. Unchecking the menu item would close the corresponding tool, checking it would show it. As part of my MVVM implementation, I have a model representing the tool. I would like to have a simple IsVisible property on this model and bind to it from the view.

I cannot for the life of me find a simple way to achieve this with the current code base. Am I missing something obvious?

Thanks

Apr 5, 2012 at 10:13 PM

Yes!

You point the AnchorablesSource property of AvalonDock to a collection of tool ViewModels in your Workspace ViewModel.

To Show/Remove the tool Anchorable you would add/remove its ToolViewModel to/from the tool ViewModels collection in the Workspace.

Steve

Apr 5, 2012 at 10:56 PM

Hmm, I suppose that will do. To be honest, that's not really idiomatic WPF. I should be able to just bind the visibility to a property and have it show/hide regardless of whether it's in the collection.

I may wrap the underlying collection in a collection view which filters out tools with IsVisible set to false.

Thanks

Apr 6, 2012 at 4:41 AM

I think you may be able to *hide* an open Anchorable with binding like that. Closing is different in my mind. I haven't played with the new version enough myself. Try going into the AD code and seeing what it can do.... best option till its finished and there is some documentation and more examples....

Apr 6, 2012 at 10:35 AM
Edited Apr 6, 2012 at 10:37 AM

I'm afraid AD isn't very MVVM friendly yet at all. Here's some notes on what I've found with respect to my original requirement above:

  • the VM command handler is passed a view construct (a LayoutAnchorable) as its command parameter for the AnchorableHideCommand
  • there is no way to specify your own command parameter (ie. I can't instead bind to my tool view model)
  • filtering out tools via a collection view does not work. The pane stays visible regardless of whether it's filtered out
  • even binding the view to an observable collection and removing the tool from the collection does not work!
  • one must call layoutAnchorable.Hide() in order to actually hide the tool. Thus, the VM must take a dependency on view constructs
  • there is also no way to specify style information a la ItemsControl.ItemContainerStyle

Basically, it all feels very restrictive and not very WPF-like in its design. Luckily for me I'm not using it for a mission-critical application. I think I'm gonna remove AD from my solution as it's evidently going to cause a lot of pain. I will keep an eye on V2 though in the hopes that its design improves in the future.

Apr 7, 2012 at 8:44 AM

I'm sorry you didn't find AvalonDock not suitable for your application. It's still a working in progress library but I think it will never address the issues that you pointed out.

I'm trying anyway to reply to your questions:

1) AvalonDock structure is much more complex than a TabControl. Internally AvalonDock itself has its own model-viewmodel framework. When you hide a tool, that tool can be positioned inside a floating window, an autohide window, inside an anchorable pane or a dockable pane just below the main docking manager. When you want to show a tool, dockingmanager and optionally developer must choose where position it, eventually creating a pane or a floating window on the fly or simply activating if it's already visible. I mean it is not just as put the visibility to visible of a simple tabitem in a tabcontrol. Actually even in VS 2010 you cant show/hide a tool with a menu item, often because a tool requires the presence of an addin or specific external library. I immagine that in VS2010 when you click a tool menuitem a command is raised and handled by a lot of components that load the tool/addin and positionate (or just activate) the pane.

2) As said above the hide command should be handled (when necessary) by the user view and there you have a reference to AD. I admit that is not so WPF-friendly to pass the anchorable via command parameter but this was required by the fact that user is able to hide/close tools and documents even when not activated. Maybe a better WPF design decision would be to provide a base class for the command parameter other then "object" a la EventArgs so that one could derive from it.

3) 4) Bugs fixed in my internal version that Im going to upload.

5) See point 1

6) Actually you could  customize everyting, you could provide your itemcontainerstayle for each kind of pane (-tabcontrol) and bind there you model property. Of course you have to restyle more than one itemcontainer because as said you have more than one container depending on the position of tool (anchored, floating or autohidden). I could of course expose such styles directly in the DockingManager without requiring library developer to provide a custom style for the anchorablepane/floating window and so on.