博客园_享受代码,享受人生

Resume

2010-06-23T12:10:00Z

Summary

Ning Xu is the architect manager of PFS group in State Street Technology (Zhejiang). Mr. Xu is responsible for implementing the architecture design of new system with the help of PFS team in Princeton. He has worked in Princeton for four months with onsite architecture team.

In last 5 years, Mr. Xu was involved in one financial product development as an offshore architect manager to work with the product management team, development team and UAT team in State Street Technology (Zhejiang). He is leading an architect team which contains of 20 developers in china, while the whole development team contains of nearly 100 developers. He has travelled to Germany with 10 Chinese developers in order to set up a development team in China in 2011. He was named "Employee of the Year " in 2009 in his company. He was promoted as officer(Bank title) in 2011.

Ning Xu has 6 years experiences on C#/.Net technology, he has translated two popular books “Practical .NET 2 and C# 2” and “Programming WCF”, and he has been recognized as a Microsoft Most Valuable Professional in C #area in 07/2007. He also has a very good understanding and a lot of experiences on object-oriented design and design pattern.

Professional Experience

State Street Technology (Zhejiang), Hangzhou 2007/05 - Present

State Street Technology (Zhejiang) is the wholly owned subsidiary of State Street and the global development center for State Street worldwide.

Project experience

WPF based C/S accounting system

This project is a C/S system which migrated from an old MFC application. The old application contains millions of lines of codes which is apparently a huge system. The core business is written in native C++ code, our job is to reuse those codes as much as we can, but build a fantasy GUI with the new technology. This project is divided into two parts like others, frontend and backend. The backend is hosted as WCF service; internally we use C++/CLI to make a wrapper layer in order to reuse the existing codes. The latest GUI technology WPF is used for building the frontend in order to get the best user experience. MVVM pattern is heavily used in this project, which makes the whole system more testable.

I mainly worked on frontend architecture which includes implementing the core architecture for the input screen; meantime, I also managed the whole team to deliver all kinds of reusable controls, patterns for building particular screens, resolve common issues and improve the performance of the whole system.

Community

Translator of “Programming WCF”

http://www.china-pub.com/38123

Translator of “Practical .NET 2 and C# 2”

http://www.turingbook.com/Books/ShowBook-218.aspx

Microsoft Most Valuable Professional in C# area in 07/2007.

http://www.microsoft.com/china/community/Professional/MVP/MVPListMain.mspx

Blog

http://idior.cnblogs.com

Skill certificate

CET4 CET6

Education

Southeast University, Nanjing, China 2004/09 – 2007/05

Master in Computer Science

Southeast University, Nanjing, China 2000/09 – 2004/07

Bachelor in Computer Science

本文链接

Covariance and Contravariance

2010-06-20T06:36:00Z

协变和逆变，这两个词的翻译实在很难表达出他们的真实含义。其实他们是继承和多态的衍生物，而且在.Net 1.0 和2.0中都提供了某种程度的支持，只是在.Net 4.0中支持的更加完善了。

简单说来，协变和逆变就是希望支持更多情况的隐式类型转换,使得我们的编程更加方便，而通常来说只有具备继承关系的两个对象才可以发生隐式类型转换，如Base b=new Derived(). 协变和逆变则使得更多的类型之间可以发生隐式类型转换，如通过协变以下代码可以正常工作：

Func<Derived> dFunc=GetDFunc();
Func<Base> bFunc = dFunc;

IEnumerable<Derived> dEnum=GetDEnum();
IEnumerable<Base> bEnum = dEnum;

那么我们为什么需要这种功能呢？让我们从一个多态的例子开始：

abstract class Animal
{
internal abstract void Eat();
}

abstract class Mammal : Animal
{
}

class Tiger : Mammal
{
internal override void Eat()
{
Console.WriteLine("Tiger eat");
}
}
class Program
{
static void Main(string[] args)
{
Tiger tiger = new Tiger();
FeedAnimal(tiger);
}

static void FeedAnimal(Animal animal)
{
animal.Eat();
}
}

虽然FeedAnimal方法接受的参数类型为Animal ,但是当我们传入一个Tiger 的实例，方法能够编译通过，并得到正确的执行。这是一个典型的多态运用。之所以能够这么做是因为Tiger 继承于Animal ，在FeedAnimal方法中对Animal对象的各种操作，Tiger 对象同样支持，而不会发生调用了animal的某个方法A，而tiger中不存在A方法的情况。那么如果我们把这一原则推而广之，就出现了协变这一概念。

static void FeedAnimal(Func<Animal> animalCreator)
{
var animal=animalCreator();
animal.Eat();
}

static Tiger CreateTiger()
{
return new Tiger();
}

现在我们让FeedAnimal方法接受一个能够返回Animla的delegate，而同时又创建了一个能够返回Tiger的方法。按照之前的推理，FeedAnimal方法无非就是对delegate中返回的Animal对象进行各种操作，那么如果给它一个返回Tiger对象的delegate，也应该能够正常的工作。所以下面这段代码是可以在.NET 2.0中工作的。

class Program
{
static void Main(string[] args)
{
FeedAnimal(CreateTiger);
}
}

这就是所谓的协变，我们希望两个对象之间，除了继承关系外也能做隐式类型的转换，因为我们认为这种转换是合理的，是类型安全的。

大家可能很奇怪，如果.Net 2.0就已经支持了以上的代码，那么4.0又搞了些什么？

先来看看下面的代码:

class Program
{
static void Main(string[] args)
{
Tiger tiger = new Tiger();
FeedAnimal(tiger);
}

static void FeedAnimal(Animal animal)
{
Console.WriteLine("Feed Animal"); } static void FeedAnimal(Mammal mammal) { Console.WriteLine("Feed Mamal"); }
}

以上这段代码的输出结果是 Feed Mammal，当碰到两个匹配的重载方法时，.Net编译器选择了形参类型在继承树上更接近自己的方法。可是如果我们把Animal改成Func<Animal> 以下代码就编译出错了，编辑器不知道选择哪个方法作为匹配。

class Program
{
static void Main(string[] args)
{
FeedAnimal(CreateTiger);
} static Tiger CreateTiger() { return new Tiger(); }
static void FeedAnimal(Func<Animal> animalCreator)
{
var animal=animalCreator();
animal.Eat();
}

static void FeedAnimal(Func<Mammal> animalCreator)
{
var animal = animalCreator();
animal.Eat();
}

究其根本，在C# 2.0中你无法实现以下delegate间的隐式类型转换

Func<Tiger> tFunc = CreateTiger;
Func<Animal> aFunc = tFunc;

而C# 4.0, 使得上述代码能够成功运行，之前的两个方法他也能够做出正确的选择。这是通过out关键字实现的。注意Func<TResult> 这个delegate在C# 2.0和4.0中的定义是不同的：

//C# 2.0
public delegate TResult Func<TResult>();

//C# 4.0
public delegate TResult Func<out TResult>();

out关键字表示该类型用于返回值，而返回值可以发生协变，因为一个方法如果能够接受一个返回Animal的delegate，那么他必然也可以接受一个返回Tiger的delegate，因为他对animla的操作同样可以作用于tiger上。

既然delegate能够支持协变，那么interface也应该给予支持，因为它无非就是多个delegate罢了。

以下代码在C# 2.0中式不能通过编译的, 这样看来interface还不如delegate支持的好。

static void Main(string[] args)
{
List<Tiger> tigers = new List<Tiger>();
FeedAnimals(tigers);
}

static void FeedAnimals(IEnumerable<Animal> animals)
{
foreach (var animal in animals)
animal.Eat();
}

下面的代码也就更加不行了：

List<Tiger> tigers = new List<Tiger>();
IEnumerable<Animal> animlas = tigers;

到了C# 4.0中，由于out关键字的缘故，以上两段代码都能正常工作了。而IEnumerable<T>的定义也被改为

public interface IEnumerable<out T> : IEnumerable
{
IEnumerator<T> GetEnumerator();
}

之前举得例子都是描述协变的，其实逆变无非就是扩大了输入参数的类型转换的可能，不过方向是反的。

static void FeedAnimal(Animal animal)
{
animal.Eat();
}

static void Execute(Action<Mammal> tAct)
{
tAct(new Tiger());
}

在Execute方法中，我们接受一个类型为Action<Mammal> 的delegate，我们在使用这个delegate时，可以传入各种类型的Mammal，比如Tiger， Lion。如果我们传入的delegate能够作用于Animal对象，那么他自然可以作用于Tiger， Lion。所以我们可以传入一个输入类型更抽象的delegate。因此，在逆变的支持下我们可以写出以下代码。

static void Main(string[] args)
{
Action<Animal> aAct = FeedAnimal;
Action<Mammal> mAct = aAct;

Execute(aAct);
}

参考资料：

eric's series on covariance and contravariance

本文链接

How does ElementName Binding work?

2010-06-14T06:49:00Z

How does ElementName Binding work? - Part 1 Logical Tree & NameScope

How does ElementName Binding work – Part 2 BindingExpression

How does ElementName Binding work – Part 3 InheritanceContext

本文链接

Weird behavior of DataContext Inheritance

2010-06-13T12:16:00Z

Actually there are several questions in this post, though all of them are about DataContext inheritance. I think you will have have fun with these questions, if anyone can explain what's going on here, it will be greatly appreciated, however it's really not that easy to answer.

I created a CustomControl which derives from ContentControl by adding a Gutter property, so that the user of this control can specify two part of this control Content and Gutter. Here is my codes:

The template is quite simple:

Now if I use it in the main window, it works as expected:

<Window x:Class="DataContexPropagate.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:DataContexPropagate"
Title="MainWindow" Height="350" Width="525">
<Grid>
<local:BizField>
<Button Content="Click one"/>
<local:BizField.Gutter>
<Button Content="{Binding}"/>
</local:BizField.Gutter>
</local:BizField>
</Grid>
</Window>

public partial class MainWindow : Window
{
public MainWindow()
{
//Notice DataContext is set before parsing the baml
this.DataContext = "Hello";
InitializeComponent();

}
}

The button defined in the Gutter shows "Hello". Now I try to add the gutter as BizField's logical child.

private void OnGutterChanged(DependencyPropertyChangedEventArgs e)
{
this.AddLogicalChild(Gutter);
}

It still works fine, but if I set the DataContext after loading xaml, it will broke.

public partial class MainWindow : Window
{
public MainWindow()
{
InitializeComponent();
//Set datacontext after parsing baml
this.DataContext = "Hello";

}
}

If you run the application, the button show nothing, apparently DataContext Inheritance doesn’t work properly now. But if i change the button to a TextBlock, it will work. What’s the magic with TextBlock?

To make the databinding works for the button, i have to add following codes to BizControl.

protected override System.Collections.IEnumerator LogicalChildren
{
get
{
yield return Content;
yield return Gutter;
}
}

According to this example, you will find that "setting datacontext before or after parsing Baml does matter". But i don't why and more intersting what happened to the TextBlock?

Full source codes for BizField:

public class BizField : ContentControl
{
static BizField()
{
DefaultStyleKeyProperty.OverrideMetadata(typeof(BizField), new FrameworkPropertyMetadata(typeof(BizField)));
}

public object Gutter
{
get { return (object)GetValue(GutterProperty); }
set { SetValue(GutterProperty, value); }
}

// Using a DependencyProperty as the backing store for Gutter. This enables animation, styling, binding, etc...
public static readonly DependencyProperty GutterProperty =
DependencyProperty.Register("Gutter",
typeof(object),
typeof(BizField),
new UIPropertyMetadata(null,
new PropertyChangedCallback(OnGutterChanged)));

private static void OnGutterChanged(DependencyObject sender, DependencyPropertyChangedEventArgs e)
{
var me = sender as BizField;
me.OnGutterChanged(e);
}

private void OnGutterChanged(DependencyPropertyChangedEventArgs e)
{
//Comment this out, it will search for the visual parent.
this.AddLogicalChild(Gutter);
}

//Only by adding this method, it can work properly.
protected override System.Collections.IEnumerator LogicalChildren
{
get
{
yield return Content;
yield return Gutter;
}
}
}
<Window x:Class="DataContexPropagate.MainWindow"
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
xmlns:local="clr-namespace:DataContexPropagate"
Title="MainWindow" Height="350" Width="525">
<Grid>
<local:BizField>
<Button Content="Click one"/>
<local:BizField.Gutter>
<Button Content="{Binding}"/>

</local:BizField.Gutter>
</local:BizField>
</Grid>
</Window>

public partial class MainWindow : Window
{
public MainWindow()
{
//Notice DataContext is set before parsing the baml
//this.DataContext = "Hello";
InitializeComponent();
//Set datacontext after parsing baml
this.DataContext = "Hello";

}
}

本文链接

How does ElementName Binding work – Part 3 InheritanceContext

2010-06-12T07:19:00Z

In this part, I am going to introduce a new concept called InheritanceContext. In WPF, there are some elements are not FrameworkElement or even Visual, which means they will not be shown on either Logical Tree or Visual Tree, e.g. Brush, however we still wish they can enjoy the feature called “property value inheritance”. Property value inheritance enables child elements to obtain the value of a particular property from parent elements, inheriting that value as it was set anywhere in the nearest parent element.

In following example, the Brush can get the DataContext property from its parent, however a Brush is neither a FramewrokElement nor Visual.

In this example, Brush doesn’t have a logical parent nor visual parent, so how does it get the DataContext property from its parent? The secret is in InheritanceContext. Brush is a Freezable object whose InheritanceContext property is set to the element which contains it.

Here is the Rectangle, while Rectangle inherits the DataContext property from its Logical Parent StatckPanel.

With the help of InheritanceContext, the ElementName Binding will work properly in following codes:

Although SolidColorBrush doesn’t have a Logical parent, it will try to get its InheritanceContext instead, by which it will reach the Rectangle, then follow by the logical parent, we will find the Window which owns a NameScope; Finally btn will be found in this NameScope.

Now let’s take a look at a popular issue in WPF development: use ElementName in ToolTip or ContextMenu.

The content defined in the a ToolTip is not part of Logical tree or Visual tree, it’s not a Freezable object either. Then how can we use ElementName binding in the content?

A straightforward solution comes into my mind is to do some hack to set the InheritanceContext property of TextBox to the Window directly. By looking into the source code of FrameworkElement, I found a static filed called InheritanceContextField whose type is UncommonField<DependencyObject> in which there is a SetValue method. By knowing this, I can use reflection to set the InheritanceContext manually.

      void Window_Loaded(object sender, RoutedEventArgs e)
        {

            var tooltipContent = tbx.tooltip;

            var field = typeof(FrameworkElement).GetField("InheritanceContextField",
                                                          BindingFlags.static | BindingFlags.nonpublic);

            var inheritanceContext=field.GetValue(null);

            //type of UncommonField<DependencyObject>
            var type = Type.GetType("System.Windows.UncommonField`1[
                                                                    [System.Windows.Dependencyobject,
                                                                     windowsbase,
                                                                     version=3.0.0.0,
                                                                     culture=neutral,
                                                                     publickeytoken=31bf3856ad364e35]
                                                                  ],
                                    windowsbase, version=3.0.0.0, culture=neutral, publickeytoken=31bf3856ad364e35");



            var setMethod=type.GetMethod("SetValue");
            setMethod.Invoke(inheritanceContext,new object[]{ tooltipContent,this});
        }

Although it’s not a good fix, it do resolve the problem. Do we have a better solution? Since ElementName binding cannot work here, we can try to use another Binding - Source Binding.

First of all, we need to define a Spy make it inherit from Freezable class,

public class ElementSpy : Freezable
{

public static readonly DependencyProperty ValueProperty =
DependencyProperty.Register("Value", typeof(object), typeof(ElementSpy),
new FrameworkPropertyMetadata(null));

public object Value
{
get { return (object)GetValue(ValueProperty); }
set { SetValue(ValueProperty, value); }
}

protected override Freezable CreateInstanceCore()
{
throw new NotImplementedException();
}
}

Then we put it into the Resource of the Window. Since Freezable object’s InheritanceContext will be set to the containing element, here it’s the window, Element binding will work fine for ElementSpy.

Now we can simply use ElementSpy as a bridge to make ElementName Binding work for ToolTip.

Here is the rule how ElementName binding works:

Get the BindingExpression which is created by the ElementName Binding.
Start from the TargetElement of the BindingExpression. If the value of BindingExpression’s ResolveNamesInTemplate property is true, it will search in the TargetElement’s template, if an element with the same name can be found in its template then return it, else go to next step.
Keep searching on the logic tree via its logic parent or InheritanceContext(when logic parent is null), until an element which has NameScope is found, let’s call it NameScopeElement. If no element owns a NameScope, search will stop.
Call the NameScope.FindName method on the found NameScope.
If the element is found, return it, otherwise try to get the template parent of NameScopeElement; if the template parent is null, it will stop search. or it goes back to step 3, search on the logic tree for an element owns a NameScope.

Related resources:

Enable ElementName Bindings with ElementSpy

Artificial Inheritance Contexts in WPF

Hillberg Freezable Trick

Leveraging Freezables to Provide an Inheritance Context for Bindings

本文链接

How does ElementName Binding work – Part 2 BindingExpression

2010-06-07T12:28:00Z

In part 1, I gave a general finding rule for ElementName binding, it works in most cases, however there are some cases you cannot explain them with the general rule. I will cover some of them in the following articles which involve some advanced concept in WPF, like BindingExpression and InheritanceContext.

What happens when ElementName binding is used in DataTrigger?

Take a look at following codes:

Let’s go back to our rules first:

Start from the element which applied the ElementName Binding, keep searching on the logic tree via its logic parent, until an element which has NameScope is found, let’s call it NameScopeElement. If no element owns a NameScope, search will stop.
Call the NameScope.FindName method on the found NameScope.
If the element is found, return it, otherwise try to get the template parent of NameScopeElement; if the template parent is null, it will stop search. or it goes back to step 1, search on the logic tree for element owns a NameScope.

If we start from DataTrigger, you will find its logic parent would be null, the search will not continue. Ok, I have to acknowledge the original statement is oversimplified.

It actually starts form the TargetElement of the BindingExpression which is created by the ElementName Binding. Here it is the CustomControl1. A little confused here? Let’s see what’s the BindingExpression and what’s the relationship between a BindingExpression and Binding.

Binding class is the high-level class for the declaration of a binding; the Binding class provides many properties that allow you to specify the characteristics of a binding. A related class,BindingExpression, is the underlying object that maintains the connection between the source and the target. Normally BindingExpression is created by WPF framework, WPF programmer rarely use it in functional codes. A key difference between BindingExpression and Binding is that Binding only contains the Source info while BindingExpression also contains the Target info. That is being said, Binding only tells you where the data comes from, while BindingExpression also defines where the data will transfer to.

In most cases, the TargetElement of the BindingExpression will be the DependencyObject whose DependencyProperty is set to a Binding MarkupExtension. For example, the TargetElement of the BindingExpression will be set to the Button object in following codes:

However our style of CustomControl1, DataTrigger is not a DependencyObject and Binding property is not a DependencyProperty either.

The BindingExpression will be created in a different way than others, it’s created in StyleHelper.GetDataTriggerValue methods which are internal to the WPF framework. In that method, the BindingExpression’s TargetElement will be set to the object which applies the style that defines the DataTrigger.

Ok. We are clear of where should we start the search, let’s continue our search. CustomControl1 doesn’t own a NameScope, so we will get his parent which is Window, since Window has a NameScope, we will call the FindName method on Window’s NameScope, but we still cannot find btn. As I said both Window and ControlTemplate have their own NameScope, btn is registered in ControlTemplate’s NameScope rather than Window, so you cannot find btn in Window’s NameScope.

But if you run the above code, you will see it works. Ok, there is another point i missed in part 1.

When we start the search from the TargetElement of the BindingExpression, it will check ResolveNamesInTemplate property of the BindingExpression, if it’s true, it will try to find the element defined in its template first. In our case, the BindingExpression is created from a DataTrigger, the ResolveNamesInTemplate is set to true in StyleHelper.GetDataTriggerValue method, now btn can be found.

Let’s revised the finding rule:

Get the BindingExpression which is created by the ElementName Binding.
Start from the TargetElement of the BindingExpression. If the value of BindingExpression’s ResolveNamesInTemplate property is true, it will search in the TargetElement’s template, if an element with the same name can be found in its template then return it, else go to next step.
Keep searching on the logic tree via its logic parent, until an element which has NameScope is found, let’s call it NameScopeElement. If no element owns a NameScope, search will stop.
Call the NameScope.FindName method on the found NameScope.
If the element is found, return it, otherwise try to get the template parent of NameScopeElement; if the template parent is null, it will stop search. or it goes back to step 3, search on the logic tree for an element owns a NameScope.

In part 3, I will give some introduction to InheritanceContext which is also called LogicalParent 2.0. :)

本文链接

Logical Tree & Visual Tree

2010-06-04T13:14:00Z

The existing documentation about the visual tree and logical tree in the Windows SDK leaves much to be desired. Ever since I started with WPF, I have felt unsure about what exactly differentiates the two. Here I will use a simple diagram to make a comparison between them.

<Grid>

</Button>

</Grid>

</Window>

Following is the logical and visual tree of the above xaml codes:

There may be several questions come into your mind after seeing this picture:

Why those red elements are chosen to be part of logical tree?

The secret is behind a property called LogicalChildren. Panel, ItemsControl, ContentControl, and Decorator, which are the most common base classes, all define this property make the logical tree operate already. For example, if you create a custom Button that subclasses ContentControl, your Content property will pick up your button as the logical parent without you doing anything.

At the end of this article, a table lists the classes that have special support for logical children, and under which property they implement that support.

Why there is a TextBlock under Label’s visual tree?

Unlike the button, we didn’t declare a TextBlock as the Content of Label, instead we only used a string “Xuning” there. Who created a TextBlock for us? Apparently, it’s created by WPF framework. When WPF starts to render an object, it will first check whether there is a template defined for that type, either control template or data template, if it cannot find one, it will simply call the object’s ToString method and put the return value into a TextBlock.

Why Label’s logical child is a string?

The element in logical tree doesn’t have to be a UIElement or Visual object, it can be any type. Label is a ContentControl which take its Content property as logical child, here it happens to be string “xuning”.

Related Resources:

Trees in WPF

Logical and Visual Tree

Of logical and visual trees inWPF

Understanding the Visual Tree andLogical Tree in WPF

Appendix:

Class	Property(ies)
*System.Windows.Controls*
AdornedElementPlaceholder	Child property
ContentControl	Content
Decorator	Child
Grid	Children (inherited from Panel), Columns, Rows
HeaderedContentControl	Content (inherited from ContentControl), Header
HeaderedItemsControl	Items (inherited from ItemsControl), Header
InkCanvas	Children
ItemsControl	Items
Page	Content
Panel	Children
RichTextBox	Document
TextBlock	Text
TextBox	Text
ToolBarTray	ToolBars
ViewBox	Child
*System.Windows.Controls.Primitives*
BulletDecorator	Bullet and Child
DocumentViewerBase	Document
Popup	Child
*System.Windows.Documents*
FixedDocument	Pages
FixedPage	Children
FlowDocument	Blocks
FlowDocumentReader	Document
FlowDocumentScrollViewer	Document
PageContent	Child
Table	RowGroups, Columns
Span	Inlines

本文链接

Memory leak caused by EventHandle - weak event

2010-06-04T08:48:00Z

When using normal C# events, registering an event handler creates a strong reference from the event source to the listening object.

If the source object has a longer lifetime than the listener, and the listener doesn't need the events anymore when there are no other references to it, using normal .NET events causes a memory leak: the source object holds listener objects in memory that should be garbage collected.

An article in codeproject provides various patterns for resolving the memory leak caused eventhandle.

1.Dispose pattern. Unhook the event handler in dispose method.

Disadvantages: Explicit memory management is hard, code can forget to call Dispose.

2. 　 Use an event wrapper.

This solution moves the event handling code into a wrapper class that forwards the calls to a listener instance which is referenced with a weak reference. This weak reference allows for easy detection if the listener is still alive.

Disadvantages : Leaks the wrapper instance when the event never fires.

3. WPF WeakEventManager.

WPF has built-in support for listener-side weak events, using the WeakEventManager class. It works similar to the previous wrapper solutions, except that a single WeakEventManager instance serves as a wrapper between multiple sender and multiple listeners. Due to this single instance, the WeakEventManager can avoid the leak when the event is never called: registering another event on a WeakEventManager can trigger a clean-up of old events. These clean-ups are scheduled using the WPF dispatcher, they will occur only on threads running a WPF message loop.

Also, the WeakEventManager has a restriction that our previous solutions didn't have: it requires the sender parameter to be set correctly, otherwise the source cannot be found in the listener's code.

Disadvantages: Tied to a WPF dispatcher, cannot be easily used on non-UI-threads.

A long thread in WPF-Disciples holds a discussion on a potential bug in RelayCommand. Nathan Nesbit though WPF’s CanExecuteChanged Implementation was Wrong.

The RelayCommand directly registers the CanExecuteChanged event handler with the CommandManager.RequestSuggested event. The MSDN docs say that the CommandManager.RequestSuggested only holds a weak reference to the handler, so shouldn't the RelayCommand also keep a strong reference to the delegate to avoid it being collected?

The answer is that we should either keep a strong reference to the delegate on Command Source or Listener. WPF keeps the delegate on Command Source which are Button, MenuItem and etc.

Check out the second line of HookCommand method which defined in ButtonBase:

private void HookCommand(ICommand command)
{
    EventHandler handler = new EventHandler(this.OnCanExecuteChanged);
    CanExecuteChangedHandler.SetValue(this, handler);
    command.CanExecuteChanged += handler;
    this.UpdateCanExecute();
}

Delay's blog talks about how to use SOS and gcroot to diagnose memory leak.

招聘广告，道富信息科技和网新恒天都招聘.NET高级开发人员和架构师。需要对.NET和面向对象设计有比较深入的了解和较好的英文读写能力，如果有 WPF 或Silverlight开发经验更佳，工作地点杭州。简历请发至 nxu [at] statestreet [dot] com。

本文链接

Resources on Debugging/Tracing WPF

2010-05-31T05:05:00Z

It is proven that we software developers spend more time debugging than actually writing code. Guess what?!! WPF is no different… We have to debug and debug and debug! XamlParseException- How...

How does ElementName Binding work? - Part 1 Logical Tree & NameScope

2010-05-28T09:31:00Z

Most developers have used {Binding ElementName= myControl , Path = myProperty} in their WPF projects, however you may find it didn’t work for you in certain cases, especially when you were build...

博客园_享受代码,享受人生

Resume

Covariance and Contravariance

How does ElementName Binding work?

How does ElementName Binding work? - Part 1 Logical Tree & NameScope How does ElementName Binding work – Part 2 BindingExpression How does ElementName Binding work – Part 3 InheritanceContext 本文链接

How does ElementName Binding work – Part 2 BindingExpression How does ElementName Binding work – Part 3 InheritanceContext 本文链接

How does ElementName Binding work – Part 3 InheritanceContext 本文链接

Weird behavior of DataContext Inheritance

How does ElementName Binding work – Part 3 InheritanceContext

How does ElementName Binding work – Part 2 BindingExpression

Logical Tree & Visual Tree

Memory leak caused by EventHandle - weak event

Resources on Debugging/Tracing WPF

How does ElementName Binding work? - Part 1 Logical Tree & NameScope

How does ElementName Binding work? - Part 1 Logical Tree & NameScope

How does ElementName Binding work – Part 2 BindingExpression

How does ElementName Binding work – Part 3 InheritanceContext

本文链接

How does ElementName Binding work – Part 2 BindingExpression

How does ElementName Binding work – Part 3 InheritanceContext

本文链接

How does ElementName Binding work – Part 3 InheritanceContext

本文链接