i am creating my first mvvm app in wpf, i came to a point where i need to drag and drop files into a ListBox, i couldn't see any other way to do it but use the DragEnter and the Drop events, then add the dropped files to my collection by casting the DataContext of the view to my ViewModel and the accessing the collection from there, and that is working really great.
something like this in my View in the drop event
(this.DataContext as ImageViewModel).ToUpload.Add(new ImageModel() { localfilelocation = fi.FullName })
but is there anyother way do it?
To be honest, dragging and dropping is probably one of those activities that MVVM finds most difficult to fit naturally into it's paradigm. However, the most common way of doing this is by using Attached Behaviours. A DragDropBehaviour, sub-classing Behavior<T> will allow you to hook into those events on the ListBox and have the advantage of being totally re-usable.
A good example of this can be found here.
Related
I'm somewhat new to MVVM but I have had my hands on it for some time now. Unfortunately, perusing the internet there seems to be no solid consensus on the best way for an application to process events in MVVM. I have a situation pictured below in which I am combining two controls - each in a self contained xml that i'm going to call two separate views: ListBox and ButtonPanel.
How should the direction of events flow then? Let's take a scenario where upon clicking my button in the button panel, a file is created in the list box control. Would the flow of events in image one or in image two be more appropriate?
Event Flow One - Communicating ViewModel to ViewModel:
Event Flow Two - All Front end classes don't communicate. All messages are passed via the Application Layer (whatever is hooked up to the back end: db, processing functions, etc..)
Please note - i didn't picture it but I am using ICommand to pass the click event from my Button Panel View to my Button Panel View Model.
And lastly once again my question is: How should events be processed in an MVVM flow. Are either of my graphics appropriate?
* **EDIT IN RESPONSE TO Ed Plunkett's ANSWER ***
Is this then the sort of event flow you would expect:
Is this closer to the correct architecture?
In this image the << >> between ViewModels are actually properties being exposed to the views, and the majority of the events are being handled as bindings there in the view.
My concerns with this are:
The Master ViewModel is now responsible for collecting information from both views. I'm not sure how to handle this without using mediator/messenger - that is without tightly coupling my parent view model to the child. Either i'd have to register events by name in all view models, or make specific callbacks by name for each of the viewmodels, so a mediator would still be necessary to achieve loosely coupled design (which is the entire advantage of using MVVM).
Even if i'm wrong in point 1 - what is the advantage of using a parent child ViewModel relationship?
Concerning the point of ViewModels don't know what a button or a panel is:
I agree. You can ignore my naming of classes here. I've just done it this way to make the question easy to understand - named classes so that an onlooker knows what control is being handled in each. My actual classes are named based on the data they handle, not the component.
Simplest case: One viewmodel.
The button invokes a command that it gets from a property of the viewmodel.
The viewmodel also has a property something like
public ObservableCollection<SomeFileViewModelClass> Files { /* INPC stuff */ }
The button has no idea what the command does. Presumably the command tells the viewmodel to create a file, and add a new instance of SomeFileViewModelClass to Files.
Meanwhile, back in the XAML, the ListBox is using Files as an items source:
<ListBox
ItemsSource="{Binding Files}"
...
...so the listbox will automatically update to show the new file.
If you want your button panel to have its own viewmodel (you almost certainly don't, and even if you do, don't call it a "button panel viewmodel"; viewmodels don't know what buttons or panels even are) and your file list to have its own viewmodel (maybe), make those kind of things child viewmodels of the main viewmodel. The main viewmodel creates them and manages relationships between them.
public FilesViewModel FileList { /* INPC stuff */ }
Maybe FileList now owns ObservableCollection<SomeFileViewModelClass> Files -- but if that's all it owns, it isn't a viewmodel. Just put that Files property on the main viewmodel.
<Button Content="Create File" Command="{Binding CreateFileCommand}" />
<!-- ... snip -->
<ListBox ItemsSource="{Binding FileList.Files}" />
Maybe CreateFileCommand should be a property of FilesViewModel, if that even exists.
Keep it as simple as possible, but no simpler.
Do not design a UI and then create one viewmodel for each thing in the UI. That's backwards. Controls don't have viewmodels.
Design viewmodels to model the things your application needs to deal with. Parent and child viewmodels, based on the actual relationships between the actual stuff (personally, I prefer to model the smallest "leaf node" things first, then work my way into the center). Then add views to display them to the user. This takes a little getting used to, but it pays off.
Your viewmodels are "The Program". You write views to display the program to the user and let the user talk to the program. You write models/database/file access/whatever to let the program store and retrieve state.
Your "All messages are passed via the Application Layer" idea is not MVVM.
Your second thing with the yellow "mediator/messenger" box is close to correct, but there's no "mediator/messenger"; parents talk to children. If a child will need to know something about a sibling, you would manage that by having the children expose events. The parent can wire up event handlers among the children -- to do it quick and dirty, you can always handle INotifyPropertyChanged.PropertyChanged on a child, but specialized events are often preferred. Dependency injection is another option but it's easy to end up writing classes with a maze of dependencies. DI can turn into an antipattern, and multi-colored block diagrams of the information flow in user interfaces is a leading indicator that it's about to.
Your case is simplified, but you'd really have a "ListBox View" that contains a ListBox and a "Button View" that contains the button. Both of those views would be child views of the "Main Window View".
I'd have to disagree with Ed here and say I would never combine VMs... that breaks the single responsibility paradigm that MVVM tries to install.
The standard MVVM way of having VMs communicate is through the messenger / event aggregator paradigm.
So i'd vote for workflow #1. ALMOST...
VM's should NOT send a message to another VM to write to a DB, etc. That's what models are for.
If you want to abstract away the DB, the standard way to do that is to define a IDataProvider type interface and use DI to inject it into VMs that need it. You'll find as your app gets larger and more complicated, DI and MVVM are a match made in heaven.
MVVM + DI + Messenger all work together beautfully and keep everything seperate and organized.
Personally I like to keep V <-> VMs 1:1 with no code behind, but that's the super purist definition of MVVM.
EDIT: Just to clarify, I don't think you really mean you are just plopping 2 controls on a form and making each a VM, I wouldn't do that. Break the UI into logical "regions" and each "region" would have a VM and a V.
I am having a form with different type of controls like Text Box, Drop downs, Check box, Radio buttons etc. All these controls are loaded dynamically from database at run time.
I want to perform validation on Text box on conditional basis. For example, If we have selected any value in drop down, then you must have to fill details in Text box. Otherwise text box details are not required.
I am open to use database to perform this task and I am using MVVM pattern in my project.
Any help on this is highly appreciated.
Thanks.
(I started this as a comment, but it ended up being too long).
In theory you have access to all these controls and their values in your ViewModel.
Without knowing the specifics of your program, it's difficult to suggest anything useful, but in essence you need to expose some more properties from your ViewModel (probably boolean) which will be calculated based on the values in your controls. Then you need to bind IsEnabled properties on your controls to these new properties.
Sounds simple, but I think you have some architectural problems which will make it difficult to implement what I suggested above. In order for this to work and automatically update your controls whenever other controls' content change, your ViewModel needs to implement INotifyPropertyChanged and raise PropertyChanged event every time you update one of those boolean properties.
I think what you're trying to do could be achieved with ItemsControl and DataTemplates (and maybe DataTemplateSelectors). This will allow you to store "data" in your ViewModel (say List or something more specific) without referencing the actual Controls and the relevant DataTemplates will add the right controls for different data types you have in your ViewModel.
I am a total beginner in this field so I need some help.
In my application I have to different buttons which has to change to position or location of some elements on click.
I have one Textbox and one ListBox with 4 Listboxitems and on button click their position has to change.
Can you please tell me how to implement this in code.
Thank you so much!
In WPF you normally use the MVVM pattern. If you haven't heard of it, there is a good explanation here. So basically, you listbox is just a presentation of an underlying list of data items. You don't change the presentation listboxitems, but instead change the items in the underlying collection and let the WPF UI handle the resulting update of the presentation layer.
You button should activate a command that switches the data in the viewmodel (or even in the model, depending on your needs). For an introduction to commands, you might find this interesting.
I want to make a complex layout, and would like advice on the best way to go about this.
Here is the behaviour I'm looking for: Layout of some text blocks and some images, such that a tap anywhere on the layout will go to another related page to that item. I want a long list of this item in a scroll viewer.
First, I tried to make a grid, add the items in it, then add this grid in the outer grid, the main one for pressing, I made an event handler for mouse click, but a problem appeared; that when I try to scroll "on the item to view the all list" the event handler fired!, I tried the mouseButton up and down, and the same happen
Second, I'm not sure if it's an efficient way to make it.
I want a good way to design this complex layout, and of course it will be a programmatic way, and a way to recognize the item I press on.
It sounds like you're trying to create your own ListBox control. Using this will give you the scrolling functionality for free, and you can use the ListBox's SelectionChanged event to determine when an item has been clicked.
The best way to design the layout will depend on how complex it actually is. If it merely contains an image and some text, you should have no problem hand-coding that in XAML. If there's a lot more to it than that, I'd recommend looking into Microsoft's Blend tool. Whichever route you choose to produce the XAML, you will place the code in the ListBox's ItemTemplate, which determines how each item in the ListBox is displayed.
A good walkthrough of something similar to what you're doing can be found at http://weblogs.asp.net/psheriff/archive/2010/10/27/windows-phone-list-box-with-images.aspx
Is there an ItemActivated event (like in Windows Forms) in the WPF ListBox or ComboBox controls? I can't see one.
It seems crazy for there not to be some event doing the same kind of thing - so does it just go by another name? If not, is there another easy way to do it? I've seen various blog posts about this but they all seem to involve subclassing the control and other things like that. I'm sure the WPF designers realised this was pretty much the most common thing that is done with a ListBox or ComboBox!
I'm basically looking for an event which will fire when the item is activated, telling me which item has activated and allowing me to access the properties of that item.
from what I understand of your description, you want to look at the SelectedItem (individual) and SelectedItems (a collection) properties. Additionally, there should be a SelectionChanged event (though I'm not certain about that naming there).