Click here to Skip to main content
15,884,750 members
Please Sign up or sign in to vote.
5.00/5 (2 votes)
See more:
I have custom treeview in wpf


<treeview grid.row="0" grid.column="0" name="ApplicationTree" datacontext="{Binding}" itemssource="{Binding Master}" itemtemplate="{StaticResource MasterTemplate}" borderbrush="Black" borderthickness="3,3,3,3" height="500">

<datatemplate x:key="DetailTemplate" xmlns:x="#unknown">
            <canvas height="30">
                <Image Source="{Binding Imageurl}" Width="25" Height="25" VerticalAlignment="Center"/>
                <Label Name="lblDetailTree"  Content="{Binding Info}" FontSize="15" Canvas.Top="0" Canvas.Left="30" MouseDown="lblDetailTree_MouseDown" MouseUp="lblDetailTree_MouseUp" />
            </canvas>
        </datatemplate>

private void lblDetailTree_MouseUp(object sender, MouseButtonEventArgs e)
        {
            System.Windows.Controls.Label lblnode = (System.Windows.Controls.Label)sender;
            lblnode.Background = Brushes.CadetBlue;
        }


</treeview>


when i select node, i get selected node label,then i change color of selected node & its changing..but when i selected another node then i want to change color of previously selected node back to its old style.

need help asap..thanks in advance.
Posted
Updated 3-Mar-11 19:16pm
v2
Comments
Sergey Alexandrovich Kryukov 4-Mar-11 1:52am    
Pretty good Question, my 5. Please see my Answer.
--SA

1 solution

Good question, because this technique is very important, because default coloring of framework elements used as tree nodes is quite ugly, so you need such code in many cases.

Let's assume you use TextBlock for your selectable items, also assume that the TextBlock has default black-on-white colors (or set all those colors programmatically when a new item is added to be in sync with selected/deselected colors use below):

C#
lblDetailTree.SelectedItemChanged += (sender, eventArgs) => {
    TextBlock oldItem = eventArgs.OldValue as TextBlock;
    TextBlock newItem = eventArgs.NewValue as TextBlock;
    if (oldItem != null) {
        oldItem.Background = Brushes.White;
        oldItem.Foreground = Brushes.Black;
    } //if oldItem
    if (newItem != null) {
        newItem.Background = Brushes.CadetBlue;
        newItem.Foreground = Brushes.Yellow;
    } //if newItem
}; //lblDetailTree.SelectedItemChanged


Tested: CadetBlue does not look so nice, try Navy :-).

You cannot use strings as nodes (there is nothing to paint in this object :-)). Because of a very flexible content model of WPF, writing this effect for polymorphous objects or universal code insensitive to the node type is a bit difficult. For example, using direct base class of TextBlock is not possible, because this is FrameworkElement, which does not have Background or Foreground property, so, it you use a combination of controls and other framework elements, you will need to make a separate cast/check for every FrameworkElement-based class which is not Control and one for all Control-based classes.

—SA
 
Share this answer
 
v4
Comments
Tarun.K.S 4-Mar-11 2:04am    
From my perspective, doing this in code-behind isn't a good practice.
How about using DataTemplate.Triggers to set the background. Whats your say on this?
Sergey Alexandrovich Kryukov 4-Mar-11 2:33am    
It's a matter of personal taste. I would suggest avoiding any extra complexity in XAML in favor of code behind. C# is designed to be well readable, supportable, collected a lot of best features based on best practices (and a bit of not very best, maybe), by XAML is not. Most XAMLs are already too crowded, and readability is quite inferior compared to C#. So... you see I have some reasons...

Binding and data template can be very elegant, but to me it's a puzzle compared to code behind. It depends, of course.
Tarun.K.S 4-Mar-11 2:55am    
Binding is one of the key important features which makes WPF so elegant and powerful. Taking into consideration the MVVM pattern, no code-behind should be used for such purposes.
Sergey Alexandrovich Kryukov 4-Mar-11 3:35am    
Well, I agree, but I hope you understand my point. There are many practical considerations that define the usage; each way has its place.
--SA
Sergey Alexandrovich Kryukov 4-Mar-11 2:38am    
I write most of the code in XAML manually (no clicks on designer: don't like the quality and speed), but there are things that I never write in XAML.
For example, let's take suck thing as event handlers (both Forms and WPF). I never put them in designer and never in XAML. Why? because it auto-generates code where I don't want it, in ve-eeeery bad obsolete syntax and violation of Microsoft naming conventions which I want to fix. I need anonymous method and where I want it (a separate file, thanks to "partial"). This rule already saved me tons of my time.
--SA

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900