Thanks. However, when I execute this code, the 2 rows in column 0 span thru column 1 and column 2. That seems to mess up columns 1 and 2, since I have 2 full UI columns in 1 and 2. I need the grid to stop and column 1.
Thanks. I got it. There was a missing Grid tag and one too many Column definitions.
Next question. If I have the following Grid (which is the same), why doesn't putting TextBlocks in Row 2 work? It always puts the two text blocks in Row 0, no matter what value I put in Grid.Row. Putting the Text in Grid.Columns 0,1, or 2 works fine. But, not the rows.
The question is a little fuzzy. do you mean the Views as in the ASP master page? In which case we have main page that has the masterpage type info on it and a navigation frame. Each navigatedto view has a VM supporting it.
Do you mean the data Master/Details structure, for this it is exactly like our old winforms, details at the top, gridview of child records and click through to the details of the child.
Never underestimate the power of human stupidity
Yeap, I recognize fussiness!!! What I mean is, kindda, close to the first. Namely, dialogs. But I didn't want to say that word because the obvious answer would be something like "IDialogService" which, to me, is still terra incognita - I don't consider myself stupid but, whatever I do, I just can't get my head around the concept!!!
What I've tried so far is this:
The main view holds a ListView with all the records - bound to an ObservableCollection. Adding is done with a button that pops up a details dialog with an OK and a Cancel. Editing is done in a similar way. But, while adding works fine, editing doesn't. In editing, when I change the data, the ListItem behind is updated in real time, and the OK button seems non-responsive. What I want is the ListView item to be updated onlywhenthe OK button is pressed.
I always have a list and a selectedobject in my VM, the selected object is used to service the dialog. I use the same VM to service both the list and the dialog.
You need to implement IEditableObject on your model, this basically takes a copy of the object when you BeginEdit and either throws away the copy if you save or copies it back to the original if you cancel.
When the content of a field changes then I set the IsDataChanged and bind that to the Save button
I don't use a dialog service, I also do not do TDD so I don;t have to be pedantic in the MVVM design. I stick my dialog initiator in the code behind.
Never underestimate the power of human stupidity
A coworker and I were discussion the design for a WPF app. It's being built using MVVM.
We have a series of user control that are going to be added to the main window at runtime. The user controls to be added are determined by the data coming back from the repository. So for model A, add user control A, type B, add user control B, and so on. The main window's VM would call into the repository, get back a collection of models, and then for each mode, determine which user control to add to the grid in the main window.
He was adamant that the VM "should not know anything about views because this breaks the MVVM pattern." He insisted that you can do all this through data templates. he also suggested that I read up on MVVM and I'll see this is true. Now I'v read lots of MVVM artiicles and Josh Smith's book, and blogs galore. I have never hear this notion that the VM can't know about views (add views at runtime).
If you're going to add controls at runtime, then the main window VM is going to need to know about the views. I am working on another WPF app that has a toolbox and design surface (canvas). The user will be able to drag & drop controls off the toolbox onto the design surface. I don't see how this could be templated, and I'm pretty sure that there's no way to do this without the main window VM adding the controls to the main window view.
I'm open to opinions. Documentation would be good.
Visibility, can however, be controlled via binding.
Other items like collapsing an Accordion just do not work using binding and I have not found a decent way to implement this without accessing view controls in the view model.
From a purist's perspective, yes, a view model should not know absolutely anything about the view.
Think of this from a unit testing perspective - if you are going to write some tests for your view model and you have reference to the 'view' in that, its going to be that much harder to get around the view and write a test case.
However, I've noticed that while implementing run-time animations etc, I have sometimes failed to have view 'independent' view models.
Very often, I just use the Tree Helper and parse through view controls from within my view model - not the best implementation from the purist perspective. But with animation and 'hey whatever works' in mind, sometimes a deviation from the pattern works better.