Im' a huge XAML noob, and I'm building an WinRT application with MVVM. Basically, I have a function getBackgroundColor() that returns a SolidColorBrush, and I want to make it so that at any given time, I can change the background color, and have the XAML element notice and change to match the new output of getBackgroundColor. I'm aware that this should be done with bindings but don't really understand any of the documentation online. Can someone explain this to me like I'm 5?
相关问题
- Sorting 3 numbers without branching [closed]
- Graphics.DrawImage() - Throws out of memory except
- Why am I getting UnauthorizedAccessException on th
- 求获取指定qq 资料的方法
- How to know full paths to DLL's from .csproj f
Flip's answer is a textbook answer and will most likely achieve the results you're looking for. Often for me, I find MVVM to be a constant practice of academia vs real world. Following the MVVM pattern works in your scenario, but there are other ways to change the UI color. And this is where the conversation begins. Does the ViewModel need to know about how the view is displaying whatever it is you're displaying? If yes, stick to the other answer. If no, slap it in the view (your window.xaml and window.xaml.cs)
For instance, I have a color converter I use, because i decided that my ViewModel doesn't need to know what color I'm switching between in the view. So in the view xaml.cs (or really you can declare this anywhere since it's a class) I defined:
Now this isn't pretty because I feel like I kind of violate the MVVM design pattern by inspecting in the view the viewmodel's data, but I'm okay with it (let the flame begin!).
So at this point all you need to do then in your xaml is to define your color converter:
And then use it wherever necessary! I used it in a datagrid to "gray" out selections:
Cheers!
Assuming you know what a property and interface are - you need a property to bind to, so for example you would have a
Border
element with a binding set up likeBackground={Binding BackgroundBrush}
. Then you would have a view model object of a type that implements theINotifyPropertyChanged
interface. The interface has one event -PropertyChanged
and you need to raise the event when a value of a property changes, so most typically the "bindable" property will raise the event in its setter when it's being set to a value different than the previous value. Your view model code might look like this then:More frequently though you would create a base class somewhat like this:
Then your view model could look like this:
This makes your view models cleaner and safer for refactoring (you're not passing property names around).
As for modifying a XAML element's color while the view is onscreen - what's the point? If it's color is only modified when it's on screen - why not use the same color always? Also if you're writing any code that responds to changes in the UI like scrolling - it's typically better to write that code on the view side - in a control, attached behavior or a service class of some sort.