Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
I cannot understand this:
Sometimes, however, the View needs to contain buttons that trigger
various actions in the ViewModel. But the ViewModel must not contain
Clicked handlers for the buttons because that would tie the ViewModel
to a particular user-interface paradigm.
What is the reason of commanding?
Clicked handlers are generally events created by controls. The handler can be specific to the controls you actually use. For example, you could create your own user controls with an event with a specific event handler.
Problem is that you want to seperate your view model with the implementation of your view. We don't want to force the view to use some controls: a List or ObservableCollection could be viewed in a ListView, ListBox, DataGrid, etc. That said, using click handlers or any handlers will result in forcing the view to use or return these handlers. This is dependency between your view and view model.
As a result, we use commanding instead. It removes this dependency since pretty much any controls can use commands and send commands event when a situation is raised (Click, drag, drop, etc).
I'll try to give you a practical answer from my own experience:
Making your code testable: You can read more about "Unit Testing", but basically they are scenarios written in code, and in these scenarios you're assuming the results.
Now because these "Tests" are just c# code, there's no way they can access your page and click the button to test the result. But in the other hand, they can instantiate your ViewModel, and execute the command.
If you write a ViewModel the proper way, you can reuse these ViewModels in differfent projects in differfent platforms: UWP (Phone,tablet,desktop.hololense,IOT) , Xamarin (iOS, Android, MacOSX).
Let's say you're writing this page which has a click event (in the code behind) that will submit data to a sever. what will happen if you want to call the same method but this time when the user presses "Enter" in the keyboard?. With Commands, you can easily bind the command to the proper event in the ViewModel
Related
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 2 years ago.
Improve this question
I have a window that displays a list of Employees. When I select one Employee and click on a button, another window should pop up displaying the details of the selected Employee. But since the new window creates a new instance of my View Model, it does not know which Employee I clicked. I know how to display the details in the same window using a Datagrid or listview but now I am trying to learn navigation in WPF and I really want to know how data is transferred in WPF between different windows. Right now I am using a single View Model for both the windows.
Inside the constructor of both the windows, I wrote this.DataContext = new EmployeeViewModel();
There are two patterns with MVVM. View first and VM first. You are using View first and are finding the issues with it.
VM first is more common and means that the VMs are in charge, and windows and views are just created to wrap the VMs. See my previous answer to see how to open a new Window for a VM in a VM first world.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I have extensive WinForms experience, but am new to WPF. Implementing Form design vision through XAML was easy enouhg to delve into, but I'm still a little unclear on what is expected from the M-V-VM programming style. I understand the principle of separating how things look from how they behave, but doing so sensibly in some cases continues to elude me.
For example, if I have a keypad with 9 buttons, and I want a means of enabling/disabling all of them through their IsEnable property, the Form designer in me wants to address them all in a code-behind method targeting them by Design Name. What is the WPF equivalent of such an operation? Am I expected to manage a series of bools in codebehind, and bind each one in the XAML to each respective button attribute? Thanks for any guidance. If this one scenario is explained, it should be sufficient to point me in the right direction
That specific problem is easily solved with binding. You would bind your buttons IsEnabled property to a public Property in your ViewModel and based on the logic contained in your ViewModel when that property value is changed your keypad button would get enabled or disabled.
As #GCamel mentioned you could also have a POCO class that would represent your button which would implement INotifyPropertyChanged interface with one of the properties being the IsEnabled property. You would add instances of this class to an ObservableCollection and when that IsEnabled property changes your button would become enabled or disabled in the UI.
I would also strongly recommend using one of the MVVM frameworks, my personal favorite is Simple MVVM Toolkit by Tony Sneed who also has a great article about the dialogs problem mentioned by #cwap Climb Onboard on the MVVM Message Bus
ideally, you would have an observable collection of button_info with IsEnabled property, icon and text - bind the collection to whathever suitable control like itemsControl, list, or grid and associate your button_info to a datatemple...you see what i mean ? no gui, no gui, just viewmodel and binding
or like this sample ???
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have 3 ViewModels, let s say ViewModelA, ViewModelB and ViewModelC.
Each view Model has a corresponding View.
In ViewModelA I have a Public Event that I`m using send some information.
I want ViewModelB and ViewModelC to subscribe to that Event in the current/Running instance of ViewModelA?
How can I do this?
If a new a ViewModelA I will have a different instance of ViewModelA, so I need a reference to the current ViewModelA...
Note: I`m not using MVVM Light or nay other framework (yet), because I did not learn them, yet :)
Thank you.
If you are creating new views from the view of ViewModelA you can pass the reference to another view like this
var viewModelA = DataContext as ViewModelA;
var newWindow = new ViewB(viewModelA);
Then you would need to have a property in your ViewModelB
public ViewModelA MyViewModelA { get; set; }
And in your new view:
public ViewB(ViewModelA viewModelA)
{
InitializeComponents();
var viewModelB = DataContext as ViewModelB;
viewModelB.MyViewModelA = viewModelA;
}
And then you can access your ViewModelA via MyViewModelA.
I've always done it like this and haven't seen any problems so far.
1) You can implement some kind of simple Publisher/subscriber like this one on codeproject. You will be one step ahead because most of frameworks has something similar:
In MVVM light it is called Messenger:
In Prism there is EventAggregator
2) Ugly solution would be to create static event in ViewModelA, this way you won't need a reference
While you can pass references between ViewModels, it makes your app tightly coupled and not particularly scalable. Also if you decide to make a change in the future the amount of refactoring quickly grows making managing changes a lot more difficult.
Have a look at a PubSub Event framework. These are all included in MVVM Frameworks such as PRISM or MVVM-Light that you mention, but you can always add your own version if you don't want or need the full frameworks mentioned above.
Have a look here for a simple no nonsense implementation that you should be able to adapt to your own requirements.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 7 years ago.
Improve this question
So i have a Pricing Table with 3 options, all on Upgrade.aspx.
'Starter'
'Champ'
'Master'
There is a button for each option. They will all navigate to Payment.aspx, but i want some variables, such as cost, and plan name, to be different based on what button they clicked on the previous page.
So if they clicked 'Starter' button, the Payment.aspx page would say Starter. But if they clicked the 'Champ' button, the Payment.aspx page would say Champ.
There are a lot of different ways you could do this. It seems a little ambiguous what would work best for your situation however.
One option is to create a singleton class with a variable which you set via button handles (IE sets the variable to "Starter" if that button was pressed).
Then the view for the Payment.aspx page could pull the information from the singleton class or consume it however you want it to.
You could also use form data, cookies, databases, and a variety of other things. It depends on where you want to store the data and how is easiest for you to store it.
There are a ton of facilities for this kind of event handling. I'd recommend looking at this article and see how it works for you MSDN - Cross-Page Posting in ASP.NET Web forms
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I'm beging to work on a re-design (software design) of XAML-based application, I wrote 2 months ago. I think I made lot's of architectural mistakes during development, which led to situation when the UI part of app is hard to extend, maintain, code is hard to understand. My app is written using PRISM 4 in MVVM style, but despite the fact that Prism was invented for modular design my App turned out to be very monolithic. I'm going to continue to use PRISM 4 in new design, but this time I want to break my UI part of application in smaller, reusable, extendable building blocks.
Suppose we are designing data input form.Top container contains Save,Cancel buttons and TabControl, which contains 2-3 tabs that contain lot's of grouped input controls.
The are 2 completly different aproaches to UI design I can see: static (compile-time), dynamic(run-time). Static it's when you predefine your UI before compiling, i.e DataGrid with columns defined in XAML. Dynamic it's when you compose UI at runtime, i.e you defined DataGrid in XAML but add columns at runtime based on user asctions.
What rules you use when you decide which aproach to use, sattic or dynamic? What you would choose in this particular example?
Next big question is how to break UI to pieces.
What rules you use when you define UserControls, how you would define UserControls for this example form? Now about ViewModels, would you create single VM for this example form or multiple (explain)? What do you think about situations when ViewModel contains other ViewModels (not simple wrapers around model, but real VM which contains logic).
And now the hardest question at least for me. Extending UI building blocks (UserControls and ViewModels).
Situation when you need to create a copy of some Form but with slightly different interface and|or logic is quite often, especially when you need to integrate authorization (permissions) in UI. Suppose we need to support slighly different version of out example form (doesn't matter how many exactly versions, suppose 2-6).
I can think of these aproaches to solve this problem:
Create duplicates of whole from (usercontrols and viewModels) and modify them (the static way). The good thing all variants are independent, great flexibility, no dependecies, the bad thing code duplicate, if you will need to change something in all variants most likely you will have to modify this everywhere, especially with ViewModels.
Conditional presentartion, you add lot's of conditional code to your ViewModel, like IsThisVisible, IsThatDisabled (the dynamic way). The good thing maximum code reuse, the bad thing code bloat and mess. Your code will be hard to understand,maintain.
Break UI to very small atomic UserControls, compose separate form variants from this UI pieces, and use ViewModel inheritance with virtual members and overrides. I haven't ever used inheritance of ViewModels, and would like to hear your opinion on this subject.
n. Other aproaches I can't think of.
In my experience, the development path tends to work this way:
Design a view in Blend or Kaxaml or whatever, and a view model that backs the view.
Realize that portions of the view need to be dynamic. Implement flags in the view model and styles in the view to show/hide them.
Realize that all the flags are getting out of hand. Get rid of the flags, and refactor the view to present collections of user controls, and the view model to dynamically populate collections of view models.
It sometimes happens that I know well in advance that I'm going to need to use approach #3, and I design for it from the start.
But one of the beauties of WPF and MVVM is that even if I don't design for this from the start, it's not too hard to move in that direction if circumstances demand it. Refactoring a bunch of view model properties into a single collection of view models doesn't take a whole lot of time or effort once you've done it a few times.
I can tell you this, though: making a copy of a XAML object and editing it makes klaxons sound in my head. It's possible to imagine circumstances under which that might be OK, but it's not the way to bet.