I am very new to WPF and am struggling with the most basic of tasks. I really hope someone can point me in the right direction please. I am using WPF with Modern UI utilising the MVVM pattern.
I have a UserControl which is successfully displaying some data in a datagrid. All I want to do is, via a button click, navigate to a second page (Usercontrol) and show some details of the selected row for editing etc.
I have found several examples of master detail setups on the same page but none that answers my questions using different windows/pages/usercontrols.
This seems like it should be the most simple of tasks but for some reason I am really struggling. I hope I am just missing something obvious as I am feeling pretty stupid about now.
Thanks in advance.
To use different controls together, you need to make the view models communicate. This can be done by passing references, or more commonly via a messaging framework.
I prefer MVVM Light from NuGet. It allows each view model to send and register to messages of specific types.
It's kind of like broadcasting events but allows your parent view model to send messages to the child view model without actually knowing about it.
Related
A have programmed in Java (Android, PC) and iOS and I am starting to program in C# WFP.
My question is if In Android for each new view I have activities, at Java swing I have card panel, in iOS I have story board with different classes for each view. How does it work in C#? What is the right way to navigate between classes with views. What term should I search to find the right tutorial for this, can you please point me at the right direction.
I would consider the following:
Use the MVVM design pattern
Use an MVVM framework (e.g. Caliburn.Micro)
Use the view model first approach
In this case, you create instances of your view models, and the views are located and displayed which correspond to the view model.
The UI elements on the views (e.g. Button) invoke verbs (methods) on your view models. Properties exposed on your view models are bound to the UI elements so that changes either side are reflected on the other.
I also had the same problem a while ago.
I used Matthew MacDonald's Pro WPF with C# 2010, the book was really good, as it has lots of really good examples.
Take a look over here: http://msdn.microsoft.com/en-us/library/ms748948.aspx
There will explain what is WPF and how to use.
Take a look also over: http://msdn.microsoft.com/en-us/library/ms754130.aspx
As part of a school project, a group and I will develop a Windows application using C#.
We are not very experienced in C# but has some basic understanding for it. We do however have experience from other languages and platforms.
We would like to build an application in which the layout is split into two primary parts: the menu, which will reside to the left and the content which will be to the right.
The menu will be more or less static and when an entry in the menu is chosen, the content will be changed.
We have not been able to figure out the best way for achieving this nor have we been able to find good material on this. The idea is to have one window and add a view (as far as I can understand, this should be a UserControl?) to this window. This control will be the menu.
Now, our question is if anyone can point us in the right direction to achieve the navigation in the program. Say, when a menu entry is clicked, how will we change the content of the window and how will we manage which view is active? I suppose that every view (in the "content area") will have a controller.
We are interested in the "best practices" for this when using WinForms and the MVC pattern.
We hope that someone can help us further in this project.
If I were you I would seriously consider using WPF instead of winforms.
It, and the use of the MVVM pattern, allows you to do some pretty impressive stuff with far less code than if you are using winforms. If you don't already know winforms then it might also be a slightly less steep learning curve as WPF is a better thought out framework (at least in my opinion).
If you go the WPF route spend some time getting to understand how bindings work and how to bind your ViewModel to the UI. Once you have a good understanding of proper UI separation you are able to do far more than you could with the old WinForms framework.
I found this link quite useful when I first started looking at WPF. Especially the RelayCommand.
If you are using Winforms the options that you have got is:
-dynamically clearing forms and generating content on menu navigation
-using mdi container form, which can be parent to a number of child forms
If you are using for WPF you could use Pages in a Frame control loaded based on used menu selection. You could also use MVVM pattern to build your app.
I'm working on a windows 8 metro-style app, using developer preview for an academic project at university. We have to use MVVM pattern.
In the main Page we have a metro-style main menu with buttons. Each button leads to an application facility (ie. 'Show my Library', 'Show Favourites', ...) which should belong to a different View, according to MVVM pattern.
In your opinion should we create a new 'metro-style Page' for each View or expect a 'Scenario' for each use case refreshing the main Page, like those present in many example apps?
In other terms, using MVVM should there be a 1:1 match between 'plain old WPF Windows' and 'brand new metro-style Pages'?
The thing with MVVM is that there are no hard rules as to what constitutes a View other than the fact that it is the means by which the user can view the ViewModel data.
A View need not be a Page, but can be a Control. Thus you can have one page, on which many View controls are displayed, if you wish. Quite often I have my Views as controls, even if they are to be the sole item displayed on a page, as it allows me to embed them in other pages more easily at a later date.
The MVVM pattern is purely a means of separating the UI from the business/code logic. A ViewModel class doesn't care how it's data is displayed, it just provides the binding points, properties etc., for the data to be displayed and trigger points for code function.
Some people will insist that there is never any code in the code behind files, but I think that a more pragmatic approach is required. Code that controls visual aspects of the View is fine, and there are occaisions when what appears to be business logic intrudes.
For example when implementing drag and drop functionality code will be required in the code behind. This is really just a visual aspect so no problem there, but if the business model dictates that only certain items, or a maximum number of items are dropped in a given location then the ViewModel will need to provide some data binding points that the View can use to implement this. By doing so you could argue that the View code behind now implements some business logic.
So back to your original question. I would try to implement the application such that it behaves as is expected for a windows 8 metro-stryle application. This will obviously have a bearing on how you code, but it should still be possible to stick to the MVVM pattern when doing so.
I've done several WPF application(not using MVVM) in the past and I had always to implement my own system of navigation between view(instantiate the view once, and then load in a container component, with refreshing required components of my view).
It works, but:
It's always custom, so if a new developer comes he has to learn of it how it works
I'm pretty sure that It's not the most optimized(most of things haven't been done in background worker, ...)
It's a time loss
So I was wondering if there is an official way to handle this ? I don't exactly how, but I was thinking to a navigation component, which can act a little like a tab panel, or a little like the MVC framework in asp.net, we can call a specified controller for an action and some parameters.
Maybe deactiviting bindings when they aren't in the current view
You can use DataTemplates/Styles to customize content of your control ( not only apearance, but data, cause that what you're asking for I presume)
http://msdn.microsoft.com/en-us/library/ms742521.aspx
You can have one Host control and at runtime change its appearance based on events/ states.
Like an example can have a look here:
http://code.google.com/p/svnradar/ how this program manages a appearance of Group and Flat view of repository information.
Another example:
Podder of Josh Smith
http://joshsmithonwpf.wordpress.com/2008/03/05/podder-v2-has-been-released/
Hope this helps.
You may be interested by Lakana, a lightweight (but powerful) framework that can handle for you all the navigation concerns !
Riana
I'm trying to create a strategy for handling popup forms for use throughout any part of my application. My understanding so far is that I will need a single UserControl in the root of my MainWindow. This will be bound to its own ViewModel which will handle the messages that are sent within the app.
I'm using MVVM Light, and I'm fairly new to the Messenger class.
Imagine a Master/Details scenario, where a list a objects are contained within a ListBox. Selecting one of these items and clicking an Edit button would display a UserControl which covers the whole screen. The user can then edit the selected item, and click OK to commit the change.
I want the UserControl that is opened to be "generic" in a way that I can throw any (probably a ViewModel) at it... for it to render the ViewModel via a DataTemplate and handle all the object changes. Clicking OK will callback to the sending class and persist the change as before.
Some situations where this would be useful are...
Display error messages with no required user input (other than OK to close it)
Display an edit form for a data item
Confirmation dialogs (much like a standard MessageBox)
Can anyone provide any code samples of how I might acheive this?
When designing a UI with MVVM the goal is to separate the concerns of the View from the concerns of the ViewModel. Ideally, the ViewModel should not rely on any view components. However, this is the idal and another rule of MVVM is that you should design your application as you wish.
In the area providing a service showing dialogs there are two different approaches floating arround:
Implementing the DialogService on the View (e.g. see http://geekswithblogs.net/lbugnion/archive/2011/04/13/deep-dive-mvvm-samples-mix11-deepdivemvvm.aspx Sample 03).
Implementing a service component that does is not attached to the view (e.g. see http://blog.roboblob.com/2010/01/19/modal-dialogs-with-mvvm-and-silverlight-4/)
Both approaches rely on an interface that defines the functionality the service provides. The implementation for this Service is then injected into the ViewModel.
Also, do both approaches have their specific advantages and disadvantages.
The first approach works also well for WP7, however, it requires a common view base class as this contains the implementation of the view service.
The second approach works well for SilverLight and WPF and appleals as it keeps the service separate from the view and does not impose any restictions on the view.
Another possible solution is to use messaging to show the dialogs.
Whatever approach you are using try to keep the View and the ViewModel de-coupled by using an IoC (inversion of control) pattern, i.e. define an interface so that you can use different implementations. To bind the services into the ViewModel use injection, i.e. passing the service into the constructor of the ViewModel or by setting a property.
I recently started learning MVVM for a WPF app I was creating, I used this article as a basis for showing dialogs, if you download the sample project then it is actually quite a nice decoupled method, it is nicely abstracted and to get a view you pass an instance of a viewmodel. I extended it somewhat for my own means, I also used the WPFExtendedToolkit MessageBox for warnings, errors etc because the standard win32 MessageBox is fugly.
With regards to dynamic forms then you'll want to investigate the ItemsControl, and in your ViewModels have a Collection of Data Items which need to be edited by the user for the ItemsControl to bind to. I have a dialog for editing actions and their parameters in a workflow system designer where the dialog list of actions was totally dynamic. This was done by exposing a collection of my items with their data types so I could then use a DataTemplateSelector to select DataTemplates which contained the correct types of controls, i.e. a datatype of DateTime showed a DatePicker.
Hope That Helps
From the perspective of a developer coming in to 'maintain' that generic code, it sounds like a pain. From what you've described, I would give the form and the dialog the same view model and create a specific XAML template for the dialog that you want to show.