I'm using PRISM (and thus the MVVM pattern). I've got a complex DateTime picker view with radio buttons.
The user can pick today, yesterday, a date, a week of a year, etc. I use radio buttons for the different choices.
What's the best way to do that in MVVM?
I really can't think of a clean way. I could create lots of custom behaviors to add to each item to track them but it doesn't seem maintainable.
I'm going to put some code-behind but I really don;t like that and to me it breaks the MVVM principle (put everything in the XAML).
Does anyone have a better idea on how to go about that?
Keep the RadioButtons, add an enum type to your VM that can return things like "Today" "Yesterday" or "Tomorrow." On the UI side create a ValueConverter that takes a parameter like "Tomorrow" and compares it with the bound value on VM, then returns the bool? needed by IsChecked.
Put it in code behind.
The M-V-VM pattern is not "put everything in xaml" it's "separate concerns". Your VM wants a DateTime right? In which case it doesn't care how that DateTime is being chosen it just needs a DateTime.
Putting View logic in the ViewModel isn't a good idea as you're now giving the VM knowledge about the workings of the View. The flow is meant to be View knows about the ViewModel which knows about the Model. The reverse is not normally true. (As with all things computer related there is always exceptions)
Hope this helps.
How about a ComboBox instead of the RadioButtons presenting a list of TimeOffset (custom class) bound to your ViewModel, with a corresponding SelectedTimeOffest property.
If you need to display extra information depending on the type of TimeOffset, e.g. a WeekOffset (subclass of TimeOfset) with a WeekCount property, have a content control with several DataTemplates customized by the type of TimeOFfset.
Just an idea...
you could create a enum, bind the values of the enum to a listbox, retemplate the ListboxItems
this post is using silverlight, but something similar should work
http://leeontech.wordpress.com/2009/03/18/creating-radiobuttonlist/
The ViewModel is designed to present the model in a way the view can consume.
In this case, you could have a boolean property for each button in the VM, and when a button updates it just sets all the other properties to false. Then in your View you can bind each properties IsChecked to the corresponding property in the ViewModel.
Also, be aware there is currently a bug in binding radio buttons in WPF. Here's a potential solution.
Related
I am going crazy trying to figure out how to manipulate telerik RadGridView for WPF's column filtering from my ViewModel. I thought I might be able to bind the value of a FilterDescriptor to a ViewModel property, but I get
Cannot find governing FrameworkElement or FrameworkContentElement for target element
<telerik:CompositeFilterDescriptor>
<telerik:FilterDescriptor Member="Foo.SomeProperty" Operator="IsContainedIn" Value="{Binding SelectedThings}" />
</telerik:CompositeFilterDescriptor>
where Foo.SomeProperty is a VM property bound to a grid column and SelectedThings is a VM property containing a stringified array of unique values to filter against.
GridView is bound to a QueryableCollectionView.
I want the filtering to work at runtime, based upon some custom logic in the VM - ex. user clicks some button and the VM restricts distinct values of one of the columns.
This shouldn't be so hard. I must be approaching this wrong. I've been pooring over other stackoverflow questions but haven't found a solution that works yet. Any suggestions would be appreciated.
UPDATE
I would still like to achieve this with a completely MVVM approach, but for the time being I've decided to stop going nuts over it and resolve the issue in the following way.
ViewModel's ObservableCollection which is bound to a list of checkboxes representing some filtering criteria are updated by the user through the GUI.
Upon that property change the ViewModel sends a message via Messenger (MVVMLIGHT) which in the codebehind has registered to receive. The message includes the filtering criteria information.
The codebehind receives it and applies it directly to the GridView.
What's nice about this is it avoids having to wire up any DependencyProperties or other event handlers and allows the VM to remain ignorant of the View implementation. It's simple and it works.
Yes, there's a little code behind now, but until I can find some better info on how to solve this problem purely through MVVM binding, this is a workable solution.
Wish I'd done this at 9 AM yesterday instead of banging my head against the wall all day long reading Telerik's crappy documentation and hunting for examples of how to do it "the right way". Meh.
I'm developing a WPF/MVVM application and I have a listbox binding to data in a ViewModel. At various points I need the view model to cause the listbox to scroll to a given element.
How can I do this without creating a custom control and while still maintaining good separation of concerns?
I've currently got it working by creating a custom behavior class in the view layer with a dependency property VisibleIndex which the XAML code then binds to an integer in the view model:
<ListBox x:Name="myListBox"
local:ListBoxVisibilityBehavior.VisibleIndex="{Binding VisibleIndex}">
When the integer is set it triggers the dependency properties update handler which tells the listbox to scroll to the associated index.
This seems a bit hacky though because the dependency property value is never changed by the listbox and the update handler only gets called when the value changes, so the only way to ensure that the relevent item is visible is to do something like this:
// view-model code
this.VisibleIndex = -1;
this.VisibleIndex = 10;
The only reason I'm using a behaviour class at the moment is for binding my custom dependency property, is there a way to do something like this with events instead?
Attached properties are somewhat required in your case - as at some point, 'somewhere' you need to call the following method...
ListBox.ScrollIntoView(item)
or
ListBoxItem.BringIntoView();
And for that you need some sort of code behind - and attached properties/behaviors are a nice way of packaging that, w/o impacting your MVVM.
Having said that - if you just need to have your 'selected item' scrolled into view at all times (which is the case most of the time). Then you could use a different attached-property based solution (that again):
mvvm how to make a list view auto scroll to a new Item in a list view
All you have to do then is to set or bind to SelectedItem.
That's a bit 'nicer' if you wish - but the mechanism is the same.
For anyone else interested in the answer to this one of the MS engineers on the WPF forum cleared it up for me. Instead of binding to an event directly you bind to a wrapper object that encapsulates that event. The behaviour can then grab the reference to the wrapper from its DP and do whatever it wants with it i.e. subscribe to the event, trigger it etc.
Currently I have a UserControl that displays collections of data in the same layout. So one control could be instanced with a collection of ObjectA and another of ObjectB. I then use TemplateSelectors to choose the right DataTemplates.
Later on we thought we'd set the List as a GridView to show more information in the list itself. However each type of object has different properties and the columns may have different names and not the same quantity. I realized then that the columns and such where not set in the ItemTemplate but at the GridView itself and ListView of course has no templateSelector for itself.
I wasn't sure how to do it but several ways came into mind.
1) There is some kind of TemplateSelector property I'm not aware off.
2) I CAN set it somehow at the ItemTemplateSelector only don't know how.
3) I could do the GridView dynamically (could be difficult and wan't to avoid).
Any good way to do this, tutorials or similiar I could use?
EDIT:
As I have learned a little bit more about ListView and it's view property I'm pretty sure I could define the gridview in a staticResource. Still I would love a ViewSelector or something similar. I guess this was of course not intended as the the item could be dynamic while the Collection isn't.
But I'm thinking about cases where there could exist more types of view then gridview ( iconview or something else) and the user could switch between them it would have to be implemented in some way.
The solution I see know is using a trigger and basing it on the first item in the collection but I'm not liking that too much.
Have you looked at the AutoGeneratingColumns property of the Grid?
http://msdn.microsoft.com/en-us/library/system.windows.controls.datagrid.autogeneratingcolumn(v=vs.95).aspx
In the MVVM (Model-View-ViewModel) pattern should the ViewModel reference the view. I would think that it should not. But how should the following scenario be handeled? I have a view that has a tab control as the main container, the viewmodel for this view implements a command to add a new tab to the tab control. The easy way would be to allow the viewmodel to reference the view and then in the command implementation to just programmatically add the new tab to the tabcontrol in the view. This just seems wrong. Should I somehow bind the tabcontrol to the viewmodel and then implement a data/control-template to add the new tabs. I hope this makes some kind of sense to somebody :)
In "pure" MVVM, the ViewModel shouldn't really reference the View. It's often convenient, however, to provide some form of interface in the View whereby the ViewModel can interact with it.
However, I've found that I almost never do that anymore. The alternative approach is to use some form of attached property or blend behavior within your View, and bind it to your ViewModel properties. This allows you to keep the View logic 100% within the View. In addition, by creating a behavior for this, you create a reusable type that can be used to handle this in every ViewModel->View interaction. I strongly prefer this approach over having any View logic within the ViewModel.
In order to demonstrate this technique, I wrote a sample for the Expression Code Gallery called WindowCloseBehavior. It demonstrates how you can use a Behavior within the View bound to properties in the ViewModel to handle controlling a Window's life-cycle, including preventing it from being closed, etc.
Reed and Dan covered the general approach but in reference to your specific case, TabControl is an ItemsControl and so can bind its ItemsSource to a data collection in your ViewModel representing the set of tabs to display. The UI for each type of tab can then be represented by a DataTemplate specific to the data type of an item (either using DataType or a DataTemplateSelector). You can then add or remove data items as needed from your VM and have the tabs update automatically without the VM knowing anything about the TabControl.
I find that it's often a helpful compromise to expose an interface on the View that handles View-specific functionality. This is a good way to handle things that are awkward to accomplish with pure binding, such as instructing the form to close, opening a file dialog (though this often gets put in its own service interface) or interacting with controls not designed well for data binding (such as the example you provided.)
Using an interface still keeps the View and ViewModel largely decoupled and enables you to mock the specific IView during testing.
One of us is missing something obvious. Your tab control is an ItemsControl. You should bind the ItemsSource of your tab control to an ovservable collection in your view model. When you handle the command in your view model to add a tab, you simply add a new element to this collection and, voila, you've added a new tab to the control.
I'm working in a WPF project, I'm using the MVVM patter in my project.
I created a user control (also in WPF) and I want to use it in my project, now, my problem is that I have a method in my user control that I need to call from my View Model, but I don't know how to do that, how to bind to the method inside my control from the view model.
If I use code behind, obviously there is no problem since I have a direct reference to my control, so I can do "mycontrol.MyMethod();"m, but of course, doing in this way will go against the logic of the MVVM pattern.
I tried to use a Dependency Property in my user control, and use that Dependency Property to bind to it in the xaml of my project but it didn't worked, the compiler says that the property was not found or is not serializable.
So I will appreciate if someone can share some light about how can I accomplish this.
Edited
As far as I understand you have the view, which is all the GUI, then you have the model, which is all the logic, and them you have the view-model which is like an intermediate layer used to bind the view with the model, right?
In this way I have developed my project, however I came to the problem that I need a custom control, a TextBox that remember what the user entered, and when he start typing, if there are words that start with that letter, those words are shown as a suggestion, as Google does it.
This TextBox is used as a search filter; so I created a user control to do this, I added a method to my user control to allow whatever application that uses my control to add items to an internal array that holds all the strings that the user has entered.
I created a user control because I couldn't find any control that behaves the way I want.
So my problem is when I add my user control to the main project, because I need to someway be able to call the method that add the items to the internal array, but maybe I'm doing things the wrong way, so if any of you has a better idea, I will appreciate if you shared it with me.
You should never call View methods from ViewModel, and vice versa.
Make a property (ObservableCollection?) on your ViewModel, it will have CollectionChanged event, subscribe to it to monitor changes (if needed).
When you add an item to the collection in your ViewModel, GUI will be updated accordingly (you have to perform the Add() operation on GUI thread, btw).
If you need to change the current position in your list, there are colections for that (CollectionViewSource, etc).
If you really really need to pass a string to your control, make a DependencyProperty and bind it OneWay to your ViewModel's property. When you set the value, it will call PropertyChangedCallback on your DependencyProperty.
Why does the consumer of the user control need to maintain the control's internal array? That seems like you've exposed an implementation detail that you don't need to.
Why not simply make that array a dependency property (and an IEnumerable<string> or ObservableCollection<string> besides)? Then you can simply create the corresponding property in your view model and bind it to the control. It also makes the control considerably more versatile.
You shouldn't call something in the View from the ViewModel since that breaks the model.
If the reason you want to call the method in the user control is to do with UI only, I don't see anything wrong with doing it from the view - the view's cs and the view's xaml are in the same "space" in the model. You can be overly-purist in wanting to have lean and mean view cs files.