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 ???
Related
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 2 years ago.
Improve this question
I'm just starting with WPF (coming from Windows Forms) and I would like to bind a TextBox's text to a class's property and I would like this to be also synchronized with the application's settings (Properties.Settings.Default). Is it possible to achieve this without code-behind? Currently I have:
<TextBox x:Name="HostnameTextBox" Text="{Binding Path=ConnectModel.Hostname, Mode=TwoWay}" />
which successfully binds to the class's property Hostname. I have stumbled upon Multibinding but I understand that is not what I want to use in this case, right? How do I make Properties.Settings.Default.Hostname property synchronized with the TextBox and the class's property, i.e. when the TextBox.Text is changed, then both the user-defined class's property and the settings property will get updated? Is it possible to do that only in the XAML file?
Is it possible to achieve this without code-behind?
No because the Properties.Settings.Default is not represented in the Xaml in any form; and there is no such thing as chain binding especially using only one binding.
I see three ways of doing it, one wrong and two which would be right
(Wrong) Create a converter which when it gets a value changes the other property.
The primary class should implement INotifyPropertyChanged and there could be code which subscribes to the properties change event and updates the Settings accordingly.
In the setter of the property, change the settings when it changes.
Frankly I would go with #3 because its the least work.
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 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
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 6 years ago.
Improve this question
I have been wondering what component I should use to display state of enabled/disabled behaviours in WinForms.
For example I have function that returns state of 2 different processes.
And I want to display like green and red color on GUI, so that user could easily know which process has wich state.
In Java I have used ProgressBar, like setting it to 100 and 0, so it represents the state of that process. But as for now, I have moved to C#, so I would like to know what components you use for this purpose, maybe there is something better to use.
Any component with a background color property will do. I suggest you use Panel and switch the background color according to your state.
You didn't specify the technology, but CheckBox is one option in both WinForms and WPF. Plus you can use Label too (with BackColor / Background properties). Finally if you want to go fancy, you can use animations in WPF.
You could either use a Panel and change its background color or (more intuitively) a read-only CheckBox.
A progress bar is not really a good choice, unless you put it in "marquee" state when something is currently active and hide it when it is not. Otherwise a progress bar is meant to display ... well ... progress.
So this comes down to:
If you want to show that some process is activated/deactivated, for example by some sort of configuration, or simply "not performing a task right now", I'd use either a Panel with a background color or a CheckBox.
If you want to show that some process is currently working (without knowing the exact progress), I'd use a ProgressBack with a "marquee" state (also called "indeterminate").
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.