Silverlight / WPF
|
|
 |
|
Hello All,
I am stuck in Wpf datgrid Cell updation.
I want the backcolor of a cell change when the value in the cell increases or decreases accordingly. like if the value increases the cell backcolor shud become green, and when the value decreases then its backcolor is red. Also when can get the increment or decrement value or the previous value so that i can know by how much it has decreased or increased.
Thanks
|
|
|
|
|
I'm going to assume that you are using MVVM here, and I'm going to show you how to do this without needing to use a Value converter. Some may argue that this isn't pure MVVM because I'm going to put a colour in the VM, but it's not one that I would really worry about too much. Anyway, here you go - add this type of code to your VM:private const Brush greenBrush = new SolidColorBrush(Colors.Green);
private const Brush redBrush = new SolidColorBrush(Colors.Red);
private Brush currentBrush;
private int oldValue;
private int currentValue;
public Brush Background
{
get { return currentBrush; }
}
public int CurrentValue
{
get
{
return currentValue;
}
set
{
if (currentValue == value) return;
oldValue = currentValue;
currentValue = value;
if (oldValue < currentValue)
currentBrush = redBrush;
else
currentBrush = greenBrush;
OnChanged("CurrentValue");
OnChanged("CurrentBrush");
OnChanged("Difference");
}
}
public int Difference
{
get { return Math.Abs(currentValue - oldValue); }
}And that's it - bind the BackgroundValue to Background to get the background colour to respond to changes.
|
|
|
|
|
What's wrong with putting a color in the VM? That's kind of its job. To contain all the properties that the view needs to render the model. That's totally MVVM.
|
|
|
|
|
The reason you do not want the color in the ViewModel is that the viewmodel should not be concerned with View issues. The color is a something for the View since it is purely UI. This is just like having the ViewModel provide Visibility enumerations. The ViewModel should not have to worry about if you are in WPF or something else. Obviously there is nothing else besides Silverlight, which is the same, but that does not have to be the case.
|
|
|
|
|
That is the VM's job. To re-package the model for the view and to implement all the RelayCommands, etc. Visiblity, colors, widths, etc. are all appropriate for the VM. Otherwise, where do you draw the line? Say I have a listview. Now, you are saying the columns should not be in the VM because that is a view issue?
|
|
|
|
|
From Wikipedia:
View model: the view model is a “model of the view” meaning it is an abstraction of the view that also serves in mediating between the view and the model which is the target of the view data bindings. It could be seen as a specialized aspect of what would be a controller (in the MVC pattern) that acts as a converter that changes model information into view information and passes commands from the view into the model. The view model exposes public properties, commands, and abstractions. The view model has been likened to a conceptual state of the data as opposed to the real state of the data in the model.[10] The term "View model" is a major cause of confusion in understanding the pattern when compared to the more widely implemented MVC or MVP patterns. The role of the controller or presenter of the other patterns has been substituted with the framework binder (e.g., XAML) and view model as mediator and/or converter of the model to the binder.
Color is not an abstraction. You should be able to replace the View with a totally different implementation and still work. Color is part of the GUI, and not an abstraction of the Model, it is a requirement of the View. If it is decided that a different color should be used, that should not affect the ViewModel, any more than changing the position of the textbox should affect the ViewModel. Otherwise why not just go back to WinForms.
|
|
|
|
|
Clifford Nelson wrote: acts as a converter that changes model information into view information and
passes commands from the view into the model. The view model exposes public
properties, commands, and abstractions. The view model has been likened to a
conceptual state of the data as opposed to the real state of the data in the
model.
Sounds like the color would fit that description quite nicely IMO. Its an abstraction of a value change in this case. An up-tick is green and a down-tick is red. That's an abstraction.
Clifford Nelson wrote: Color is not an abstraction. You should be able to replace the View with a
totally different implementation and still work.
Having an up-tick color and a down-tick color exposed in the VM has no effect on swapping out the View whatsoever. Any View can either use it or not.
Clifford Nelson wrote: If it is decided that a different color should be used, that should not affect
the ViewModel, any more than changing the position of the textbox should affect
the ViewModel.
You are really reaching with that one  . A color in this case is an abstraction of the up-tick / down-tick concept.
Anyways, I'd REALLY hate to have to maintain your code where every VM has dozens of value converters just for the heck of it. Seems like a nightmare to me . If you are working on a big UI where there are 50 views, you are really going to have 500+ converters??? Are you serious???
And if you REALLY want to be an anal MVVM / OOP purist... the color change doesn't belong in either place. That belongs in a refactored "Cell" object  .
|
|
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin
Submit an article or tip
Post your Blog
