Click here to Skip to main content
12,955,842 members (65,925 online)
Rate this:
Please Sign up or sign in to vote.
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" />
private void lblDetailTree_MouseUp(object sender, MouseButtonEventArgs e)
            System.Windows.Controls.Label lblnode = (System.Windows.Controls.Label)sender;
            lblnode.Background = Brushes.CadetBlue;


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 3-Mar-11 19:09pm
Updated 3-Mar-11 19:16pm
SAKryukov 4-Mar-11 1:52am
Pretty good Question, my 5. Please see my Answer.

1 solution

Rate this: bad
Please Sign up or sign in to vote.

Solution 1

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):

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.

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?
SAKryukov 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.
SAKryukov 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.
SAKryukov 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.
Tarun.K.S 4-Mar-11 2:57am
But one small issue with coding in XAML is debugging. Its pretty easy to debug in code-behind.
SAKryukov 4-Mar-11 3:36am
Absolutely, this is one of the issues.
SAKryukov 4-Mar-11 2:42am
It should be understood that many features are invented not for effective fast quality work, but in marketing goals, just to impress people who may be not doing all works with their own hands. Unfortunately. Lamers are impressed with auto-generated code (but if fact, this is one of the trivial tasks, nothing wonderful), much less people can critically see the poor quality of the generated code.

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

    Print Answers RSS
Top Experts
Last 24hrsThis month
OriginalGriff 6,719
CHill60 3,550
Maciej Los 3,153
ppolymorphe 2,060
Jochen Arndt 1,975

Advertise | Privacy | Mobile
Web02 | 2.8.170525.1 | Last Updated 4 Mar 2011
Copyright © CodeProject, 1999-2017
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100