I am not using anything other than a simple WPF application project in visual studio. I've implemented an mvvm application.
I want to display a list of content changes made by a user. I have a main window view model and it currently just builds a strings with changes. I have objects that I can reuse to display their properties (the content).
Currently, I use a MessageBoxResult to show a really long string with the changes. This is a terrible design (I know), but I couldn't really find an answer to what class a regular wpf project has that would allow me to achieve what I want.
I know there is a popup class I can use. In practice, which is better-- another view model for the dialog, or a popup?
Can anyone provide a simple example of one of the two approaches?
Thank you in advance for your response.
What I've done in the past is have a simple Border control, and inside of a TextBlock and whatever Button controls I need. I bind the TextBlock.Text to a public string property named "MessageBoxMessage" which calls OnPropertyChanged(). I bind the Command of each Button to a separate public ICommand which specifies what action to take in the view model when the button is clicked. I then bind the visibility of the Border control - which contains all of the other controls I mentioned - to a Visibility property.
When I want to show a dialog, I set the MessageBoxMessage to the message I want to show, makes sure the commands are set properly, and then set the Visibility on the Border to Visibility.Visible. This shows the box (border), message, and buttons.
You can even implement a semi-transparent rectangle underneath the border (over the rest of the form) that you set to visible at the same time. This will give you the nice "form dimmed" effect and also block the normal form controls from being clicked. A general note - for this to work, these controls need to be at the very bottom of your XAML as the z-index among controls at the same level is inferred from their placement in the XAML - lower in the code is top level on the form.
Let me know if you have any questions about implementing this if it sounds like what you are looking for.
I am in the process of re-writing one of our large Silverlight apps to use PRISM and the MVVM design pattern.
A very common scenario is a DataGrid in the View. Double clicking a row allows the user to edit the entity represented by the row, using a ChildWindow.
I am tempted just to capture the DoubleClick event in the code behind, create a new ChildWindow of the proper type, and set the DataContext to be DataGrid.SelectedItem.
I know that this is not the proper way to handle this scenario with PRISM and MVVM, however.
I would love advice on what is! (re: my title...it seems like InteractionRequest might be the best way to do this?)
Thanks...
EDIT: We did end up deciding to go with InteractionRequest for our solution. We almost always use "Notification" as the type and pass a new ViewModel (each ChildWindow has its own) as the Content.
In our case the ChildWindow view was complex enough to warrant its own viewmodel. This view isn't too closely coupled with the data grid view.
So, we have an EventTrigger attached to the data grid (we actually use Telerik's data grid) in XAML. The event trigger executes a command in the view model using InvokeCommandAction.
The command publishes an aggregated event that has the selected item as the payload. The event is picked up by the central application controller that is responsible for creating the ChildWindow view and a corresponding view model (using the event payload as the context).
I think that interaction request could potentially be used in your case, but based on my understanding the idea behind an interaction request is a very simple Ok or Yes/No interaction. You might be pushing the boundaries with a bunch of text boxes, validation, etc.
I'm writing an app that connects to network resources.
When the app is connecting, I want to popup an overlay with the usual spinney progress graphic and a cancel button. I have designed a ConnectProgressViewModel and matching ConnectProgressView for the overlay.
My question is what is the cleanest way to show/hide the overlay from the parent ViewModel?
A) Expose a constant ConnectProgressViewModel from my parent ViewModel, and have the ConnectProgressView bind its visibility to the ConnectProgressViewModel.IsConnecting property.
B) Expose a generic Overlay property from the parent ViewModel, and set it to a ConnectProgressViewModel when the user wants to connect. The parent View binds a ContentControl to this Overlay property and data templating takes care of the rest.
C) ?
The first seems to encapsulate the functionality more, with the app not having to care about showing and hiding the overlay, but exposing a constant ConnectProgressViewModel all the time feels wrong when it's only show occasionally.
The second seems to fit MVVM better with the ConnectProgressViewModel only being created when it's needed, but it places more functionality onto the parent, and also the generic Overlay property feels a bit weird too.
Cheers
EDIT:
I should clarify that this view does more than just show busy status. It allows cancelling/retries and selection of different network resources etc. I omitted such details for brevity which was perhaps a mistake as people are concentrating on the busy indicator.
I always just use a BusyIndicator from the Silverlight Toolkit. It does not have a cancel button, but you can probably style it to have one. The BusyIndicator has an IsBusy property that I bind to an IsBusy property on my ViewModel. If you style the control to have a button, you can add a cancel command to your ViewModel.
Edit
I just saw that this is WPF not Silverlight. I'm not sure if the WPF Toolkit has a BusyIndicator
Edit Again
It looks like the Extended WPF Toolkit has a BusyIndicator. Note, I have no experience with this.
I would go with something like your suggestion in A) and argue that you shouldn't implement something as generic like B) until you actually have that degree of flexibility as a requirement, like being able to show different overlay views.
Keep it simple!
I'm developing a WPF application in C# and was thinking about implementing a custom UI element accross various windows.
I would like to have a minimized tray (only about 4px visible) that expands after clicking on an icon next to the tray. The expanded version would show all controls and would minimize when I click the icon again. I created a quick HTML concept to clarify things.
I know I could put a stackpanel and button in my application and making both of them move up when I click the button, but then I would need to duplicate the code a lot.
Though I'm experienced with C#, I'm fairly new to WPF interface development/templates, but I'm sure there has to be a way so I can use that UI element accross my application without needing to copy/paste a lot of lines of code in my form class file.
I hope someone can help me, or at least point me in the right direction.
There are three ways to customize your elements.
1 If you only need visual modifications you can use styles to change the appearance of the .net default controls. You can even override / extend the default templates.
2 If you want custom logic in a control you can create a custom control. The framework brings a lot of "primitives" to build upon. Examples are ContentControl or HeaderedContentControl. Say you want to build a custom expander control you can inherit your custom control from HeaderedContentControl which provides you with Header and Content properties and you just have to implement the toggling logic yourself.
CustomControls are a good choice if you want to build basic functionality which can be used throughout your application. They can be themed/styled depending on the use case, too (see 1).
3 If you want to compose different controls into one control you can create a UserControl. User controls are composed using XAML. Most top level controls are user controls driven by a view model.
Your case can be build using a Popup and ToggleButton or an Expander.
The decision depends on the desired behavior. If you want the opened panel to move following content down you need a expander. If you want a dropdown like functionality you need popup.
If you use a popup just bind the IsPopupOpen Property to IsChecked of the ToggleButton and set PopupStaysOpen = false to wire the button to your popup.
If you use an expander control you should create a style which can be applied to all equal expanders in your application to minimize the required XAML in each view.
How about using Expander Control?
There's a control called an Expander that is perfect for this. You'll have to style it to look like you want, however it has the functionality you want built-in.
I have a a user control which contains several other user controls. I am using MVVM. Each user control has a corresponding VM. How do these user controls send information to each other? I want to avoid writing any code in the xaml code behind. Particularly I am interested in how the controls (inside the main user control) will talk to each other and how will they talk to the container user control.
EDIT:
I know that using events-delegates will help me solve this issue. But, I want to avoid writing any code in xaml code-behind.
Typically, it's best to try to reduce the amount of communication between parts, as each time two user controls "talk" to each other, you're introducing a dependency between them.
That being said, there are a couple of things to consider:
UserControls can always "talk" to their containing control via exposing properties and using DataBinding. This is very nice, since it preserves the MVVM style in all aspects.
The containing control can use properties to "link" two properties on two user controls together, again, preserving clean boundaries
If you do need to have more explicit communication, there are two main approachs.
Implement a service common to both elements, and use Dependency Injection to provide the implementation at runtime. This lets the controls talk to the service, which can in turn, keep the controls synchronized, but also keeps the dependency to a minimum.
Use some form of messaging to pass messages between controls. Many MVVM frameworks take this approach, as it decouples sending the message from receiving the message, again, keeping the dependencies to a minimum.
Your conceptual problem is here:
Each user control has a corresponding VM.
Having a separate ViewModel for every view pretty much defeats the concept of a ViewModel. ViewModels should not be one-to-one with views, otherwise they are nothing but glorified code-behind.
A ViewModel captures the concept of "current user interface state" -- such as what page you are on and whether or not you are editing -- as opposed to "current data values'.
To really reap the benefits of M-V-VM, determine the number of ViewModel classes used based on distinct items that need state. For example, if you have a list of items each of which can be displayed in 3 states, you need one VM per item. Contrarily, if you have three views all of which display data in 3 different ways depending on a common setting, the common setting should be captured in a single VM.
Once you have strucutred your ViewModels to reflect the requirements of the task at hand you generally find there is no need nor desire to communicate state between views. If there is such a need, the best thing to do is to re-evaluate your ViewModel design to see if a shared ViewModel could benefit from a small amount of additional state information.
There will be times when the complexity of the application dictates the use of several ViewModels for the same model object. In this case the ViewModels can keep references to a common state object.
There are many differenct mechanisms for this, but you should first find out in what layer of your architecture this communication belongs.
One of the purposes of the MVVM framework is that different views can be made over the same viewmodel. Would those usercontrols talk to each other only in the view you are currently implementing, or would they have to talk to each other in other possible views? In the latter case, you want to implement it below the view level, either in the viewmodel or the model itself.
An example of the first case may be if your application is running on a very small display surface. Maybe your user controls have to compete for visual space. If the user clicks one usercontrol to maximize, the others must minimize. This would have nothing to do with the viewmodel, it's just an adaption to the technology.
Or maybe you have different viewmodels with different usercontrols, where things can happen without changing the model. An example of this could be navigation. You have a list of something, and a details pane with fields and command buttons that are connected to the selected item in the list. You may want to unit test the logic of which buttons are enabled for which items. The model isn't concerned with which item you're looking at, only when button commands are pressed, or fields are changed.
The need for this communication may even be in the model itself. Maybe you have denormalized data that are updated because other data are changed. Then the various viewmodels that are in action must change because of ripples of changes in the model.
So, to sum up: "It depends...."
I think the best solution would be using Publisher/Subscriber pattern. Each control registers some events and attaches delegetes to events exposed by other controls.
In order to expose events and attach to them you would need to use some kind of Mediator/EventBroker service. I found a good example here
The best way to do this in my opinion is via Commanding (Routed Commands / RelayCommand, etc).
I want to avoid writing any code in the xaml code behind.
While this is a laudable goal, you have to apply a bit of practicality to this, it shouldn't be applied 100% as a "thou shalt not" type of rule.
You can communicate between elements on the UI by using element binding, so assuming a user control you created exposes a property, the other user controls could bind to it. You can configure the binding, use dependency properties instead of basic properties / implement INotifyPropertyChanged but it is in theory possible, but does require some forethought to enable to communication this way.
You will probably find it far easier using a combination of events, code and properties than try a pure declarative way, but in theory possible.
You can share some View Model objects between controls as well as Commands...
For example, you have some main control, which contains two other controls. And you have some filtering functionality in the main control, but you want to allow user to set some part of the filter in the first sub-control (like "Full filter") and some part of the filter in another (like "Quick filter"). Also you want to be able to start filtering from any of sub-controls. Then you could use code like this:
public class MainControlViewModel : ObservableObject
{
public FirstControlViewModel firstControlViewModel;
public SecondControlViewModel firstControlViewModel;
public ICommand FilterCommand;
public FilterSettings FilterSettings;
public MainControlViewModel()
{
//...
this.firstControlViewModel = new FirstControlViewModel(this.FilterSettings, this.FilterCommand);
this.secondControlViewModel = new SecondControlViewModel(this.FilterSettings, this.FilterCommand);
}
}
public class FirstControlViewModel : ObservableObject
{
//...
}
public class SecondControlViewModel : ObservableObject
{
//...
}
In the main control XAML you will bind sub-controls DataContext to the appropriate View Models. Whenever a sub-control changes filter setting or executes a command other sub-control will be notified.
As others have said you have a couple of options.
Exposing DepedencyProperties on your user controls and binding to those properties provides a pure XAML solution in most cases but can introduce some UI dependencies in order for the bindings to see each other
The other option is a decoupled messaging pattern to send messages between ViewModels. I would have your user controls bind to properties on thier own VM's and then on the property change inside that VM it can "publish" a message that notifies other "subscribers" that something has happened and they can react to that message however they want to.
I have a blog post on this very topic if it helps: http://www.bradcunningham.net/2009/11/decoupled-viewmodel-messaging-part-1.html
If you're using strict MVVM, then the user-control is a View and should only "talk", or rather, bind, to its ViewModel. Since your ViewModels most likely already implement INotifyPropertyChanged, as long as they have a reference to each other, they can use the PropertyChanged events to be notified when properties change, or they can call methods (better if it's through an interface) to communicate with each other.