# .NET and More > WPF, WCF, WF >  WPF tabs

## jdlessl

I am very new to WPF and have been tasked with modifying an existing app.  One thing I noticed was that the main form's TabControl is bound to an Observable collection in the MainVM, which then gets populated with DetailVM's.  The TabControl is confgured to automatically load a particular type of View and bind any new element in the collection to it.

But here's the thing; the MainVM doesn't really do anything with the DetailVM's except just spawn them and hold them.  So it seems to me like this is kinda breaking the entire point of WPF, separating out data and ui.  If we wanted the view to use mdi windows instead of tabs, or to not use tabs at all and only display the most recently requested DetailVM, the viewmodel would be entirely unable to cope, since it's pretty much written with "tab windows" in mind.

Would it be better design to have the view manage its own tabs, and when given a new DetailVM, it decides what to do with it rather than the MainVM?  Which leads to the next question, how do I do that?  Don't want to call methods on the wpf view backer code, right?  Have a CurrentDetail property in the MainVM, and when the view detects it changing it creates a new tab and binds it to the value?

----------


## Sitten Spynne

I think you have a good point, but it's really hard to comment briefly. Some of this is philosophical.

I do NOT like for anything related to UI display to be in my ViewModels. It's often tempting to make color, opacity, visibility, and a handful of other properties part of the VM. Often that logic is something like, "I want this background to be red if this property is within a certain range". That should be a binding from the "this property" to the color property with an IValueConverter to decide the right color.

But not everything that "goes to the UI" is related to the UI. For example, tab pages need a caption for their tab. But MDI children also have a caption, so a property that indicates that caption MIGHT be appropriate. (IMO it's generally a property of the thing the VM represents anyway.)

OK. So I'm not really answering your question yet.

If I were making a page like you described, it does sound sensible so far that the MainPageVM might just hold a collection of SubPageVM instances. I could bind a TabControl to those VMs and then it'd be up to me to write some code to help the TabPage understand how to generate visual content for the VM. 

That would also probably work for an MDI-style application, though MDI isn't a native concept in WPF. That doesn't mean we can't make something that sort of facilitates it. Suppose we write a custom Panel that can allow Window-like elements to be laid out within, moved around, opened/closed, etc. I can see it behaving just like the TabPage. It's bound to a collection of SubPageVM objects. For each SubPageVM object it wants to generate some visual elements. Each of those elements generates some content based on the other properties of the VM.

So the architecture you're describing _doesn't_ sound bad to me at a high level. Maybe in the code itself there are things that'd change my mind. But in WPF, "a collection of tab pages" should be represented by "a collection of ViewModels that the UI knows to associate with tab pages".

----------

