Re: MVVM Recommendations - WPF Discussion Boards

8-Nov-11 7:10

I'm in the middle of designing a WPF app that is going to have a view with a lot of information. It is a sort of Management Console for an app that we are developing.

I am envisioning some sort of tabbed interface to organize all of the various "things" that this UI has to deal with.

The model part is fairly straightforward; it is going to be accessing an SQL database with lots of different tables.

I am wondering if the "standard" way of doing things would be to create one large view model class that worked with the overall view, or if it is more appropriate to treat each tab like a separate view, with a separate view model for each? Or does that add needless complexity? Or does it even really matter? Confused | :confused:

Thanks for any advice on the matter. Smile | :)

WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.

There are 10 kinds of people in the world: People who know binary and people who don't.

SledgeHammer018-Nov-11 7:23

SledgeHammer01

8-Nov-11 7:23

Definitely each tab should be its own view and have its own VM. There is no view for managing the tabs per se. Its more of a control that data binds to a collection of views or VMs. Typically it'll bind to a collection of VMs and you'll use DataTemplates to map a View to the VMs and the "control" will auto create the view and wire up the data context, etc. Personally though, I find that backwards as I like to launch a view and have the xaml specify what the VM is through a ViewLocator.

Tom Delany8-Nov-11 7:52

8-Nov-11 7:52

Thanks for the feedback. I'm seriously considering using DevForce A/F to help me out.

http://drc.ideablade.com/xwiki/bin/view/Documentation/devforce-caliburn[^]

[Edit:] I'm thinking that if we ever decided we needed a web interface, I could leverage the Silverlight support in the above with minimal code changes.

WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.

There are 10 kinds of people in the world: People who know binary and people who don't.

Kevin Marois8-Nov-11 7:36

Kevin Marois

8-Nov-11 7:36

I'm doing the exact same thing right now. My app has tabs, and on each tab I add & remove user controls at runtime. So it's basically "nested' views. The MainWindowViewModel is responsible for creating the view and viewmodel and handling commands.

I created a TabInfo class. The MainWindowViewModel maintians a collection of TabInfo object. I then use that to manage the tabs.

Everything makes sense in someone's mind

Tom Delany8-Nov-11 7:53

8-Nov-11 7:53

Cool. Thanks for the feedback! Smile | :)

WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.

There are 10 kinds of people in the world: People who know binary and people who don't.

Abhinav S8-Nov-11 21:38

Abhinav S

8-Nov-11 21:38

Each tab should be a separate view / view model and you should be plugging in /removing views on demand.

There is no concept of creating one large view model that works for all views.

Tom Delany9-Nov-11 3:57

9-Nov-11 3:57

Thanks. That seems to be the general consensus. Sorry if it was a stupid question.

WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.

There are 10 kinds of people in the world: People who know binary and people who don't.

Wayne Gaylard9-Nov-11 4:23

Wayne Gaylard

9-Nov-11 4:23

Tom Delany wrote:
Sorry if it was a stupid question

There is no such thing as a stupid question Smile | :)

Only stupid answers. If you are unsure, it is always better to ask.

When I was a coder, we worked on algorithms. Today, we memorize APIs for countless libraries — those libraries have the algorithms - Eric Allman

Tom Delany9-Nov-11 4:51

9-Nov-11 4:51

Thanks

WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.

There are 10 kinds of people in the world: People who know binary and people who don't.

Abhinav S9-Nov-11 6:41

Abhinav S

9-Nov-11 6:41

Tom Delany wrote:
Sorry if it was a stupid question.

Nope. It was not.

_Maxxx_14-Nov-11 17:55

_Maxxx_

14-Nov-11 17:55

IMHO ...
If each tab in your tabbed interface is, essentially, stand alone, and could be presented in a different way (say in a tree view, or pop-up form etc.) then you need to model that view using a view model. the fact that a particular View attached to that view model happens to sit on a tab control somewhere is 'nothing to do with' the ViewModel.

OTOH if the separation into tabs is more just a gui convenience (that is, all the tabs are necessary and inter-related) then the ViewModel should model all of the controls on all of the tabs - and the View just 'happens' to split them into tabs. Some other implementation may decide to present all of the data in one large, scrolling form, for example, still bound to the single view model.

this isn't a criticism, as I do it myself, but I believe one of the aims of using ViewModels is that you try to design the ViewModel first rather than thinking 'I want a tabbed interface' you think 'I want to perform these functions." The ViewModel contains the data to be presented/updated, and offers the functionality - then you design the view to be able to provide the interface to the user.

So in the case of the 'Management Console' style, i would think you would have several ViewModels, one for each piece of functionality, and a ManagementConsoleViewmodel that has, as properties, each of the view models it requires to perform its functionality.

The View that binds to the 'big' view model may place the smaller views on tabs, in trees, or on the sides of an animated 3D spinning cube - by binding to its view model it has access to all it needs regardless, and each of the smaller viewmodels can also be viewed in whatever way you want - and indeed can also be used independently if required.

MVVM# - See how I did MVVM my way
___________________________________________
Man, you're a god. - walterhevedeich 26/05/2011

.\\axxx
(That's an 'M')

Tom Delany20-Nov-11 11:27

20-Nov-11 11:27

Sorry for the slow reply. My father passed away on the date that you sent this to me and I had to leave town suddenly.

Thank you for the advice. I appreciate it. Smile | :)

I do not in fact take your comments as criticism. In actuality, I have been trying to code up the view models first, but in parallel I have also been trying to get some idea what the view will end up looking like. As you say, it may indeed end up looking completely different that a tabbed interface. If I construct the view models properly (and that's a big if), I should be able to swap in any sort of views that I desire with minimal fuss.

WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated.

There are 10 kinds of people in the world: People who know binary and people who don't.

Button with popup submenu - like the one in toolbars

_Maxxx_20-Nov-11 13:15

_Maxxx_

20-Nov-11 13:15

Tom Delany wrote:
My father passed away on the date that you sent this to me and I had to leave town suddenly.

My sympathies - not a good time. Rose | [Rose]

Tom Delany wrote:
If I construct the view models properly (and that's a big if),

yes - that's the problem I faced many times! I actually split my ViewModel and ViewData into separate classes - as I find this makes more sense (to me, anyway!) so my model really models the functionality to be presented, and the data is just the data that allows that functionality to occur. It allowed me more flexiblity to do what I wanted to do but it may not suit you!

Cheers

MVVM# - See how I did MVVM my way
___________________________________________
Man, you're a god. - walterhevedeich 26/05/2011

.\\axxx
(That's an 'M')

Member 10339078-Nov-11 5:29

Re: Button with popup submenu - like the one in toolbars

8-Nov-11 5:29

What is the easiest way to get a button (acting like a normal Button) with a small arrow symbol or something on the right side and when the arrow is clicked, a submenu (ContextMenu) si displayed. This is fairly common espacially in toolbars and such, see for example "New Project" button in the Visual studio toolbar.

I know I can probably get the job done with extensive templating but I want to code as little as possible and loose as little as possible of the default button behavior (mouse over effects implied by windows theme and such).

Thanks for sugegstions.

SledgeHammer018-Nov-11 6:45

SledgeHammer01

8-Nov-11 6:45

There is no built in split button in WPF, but people have already written it for you:

A WPF SplitButton[^]

or

http://wpfsplitbutton.codeplex.com/[^]

modified 9-Nov-11 16:19pm.

Re: Button with popup submenu - like the one in toolbars

Member 10339079-Nov-11 9:07

WPF Drag Drop - handling DragEnter and DragOver to disallow drop impossible?

9-Nov-11 9:07

Thanks, I tried googling it but never tought of the term "split button".

MAF

columbos149278-Nov-11 4:16

columbos14927

8-Nov-11 4:16

Hello,
I created a DLL that is loaded by some host application using the MAF technology.The DLL it self uses some asembly.
Every thing goes fine, i activiate the DLL from my host aplication and when i try to use some DLL's function i get an exception:

"FileNotFoundException" when the file is the asembly that i use in the DLL,ive checked several times that the path of the assembly is corect.

what could be the problem?

Thanks

Member 10339078-Nov-11 0:51

Re: WPF Drag Drop - handling DragEnter and DragOver to disallow drop impossible?

8-Nov-11 0:51

I have the basic drag and drop functionality up and running. Now I want to handle DragEnter and/or DragOver on the drop target and in the event handler decide whether or not the drop is allowed. I thought I would do this by setting DragEventArgs.Effects property to None when the drop is not permitted but this has absolutelly no effect - mouse cursor still looks like everything is ok and indeed Drop event is fired when you drop the item. I remember that this was the way to go in windows forms, how can I conditionally diallow dropping (other that AllowDrop=false of course) in WPF?

Edited to add:
Straight from MSDN: The drop target is also able to specify what effects it intends in response to the dropped data. For example, if the drop target does not recognize the data type to be dropped, it can refuse the data by setting its allowed effects to None. It typically does this in its DragOver event handler.

So where is the problem? I am handling DropOver, settings Effects to None and yet the drop is allowed.

Mark Salsbery8-Nov-11 5:13

Mark Salsbery

8-Nov-11 5:13

You still need to check for drop allow in the Drop event handler and generally do nothing if drop isn't allowed.

Mark Salsbery
Java | [Coffee]

Re: WPF Drag Drop - handling DragEnter and DragOver to disallow drop impossible?

Member 10339078-Nov-11 5:25