Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: C#3.5
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 3-Mar-11 19:09pm
Edited 3-Mar-11 19:16pm
v2
Comments
SAKryukov at 4-Mar-11 1:52am
   
Pretty good Question, my 5. Please see my Answer.
--SA

1 solution

Rate this: bad
good
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 Smile | :) .
 
You cannot use strings as nodes (there is nothing to paint in this object Smile | :) ). 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
  Permalink  
v4
Comments
Tarun.K.S at 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 at 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 at 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 at 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
SAKryukov at 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
Tarun.K.S at 4-Mar-11 2:57am
   
But one small issue with coding in XAML is debugging. Its pretty easy to debug in code-behind.
SAKryukov at 4-Mar-11 3:36am
   
Absolutely, this is one of the issues.
--SA
SAKryukov at 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.
--SA

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

  Print Answers RSS
0 Sergey Alexandrovich Kryukov 369
1 _Amy 230
2 OriginalGriff 220
3 Peter Leow 205
4 Andreas Gieriet 180
0 OriginalGriff 7,540
1 Sergey Alexandrovich Kryukov 6,412
2 Maciej Los 3,849
3 Peter Leow 3,653
4 CHill60 2,702


Advertise | Privacy | Mobile
Web01 | 2.8.140721.1 | Last Updated 4 Mar 2011
Copyright © CodeProject, 1999-2014
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