我目前正在将我创建的许多附加行为迁移到混合行为，以便它们支持在 Expression Blend 中进行拖放。我注意到混合行为的作者倾向于将行为属性定义为依赖属性。
我创造了一种行为，TiltBehaviour，它公开了公共依赖属性，TiltFactor，双精度类型。在 Expression Blend 中，我可以设置此属性的值，但是，添加“数据绑定...”的选项呈灰色显示：
我还注意到行为延伸DependencyObject，因此他们没有DataContext因此不能继承DataContext它们所附着的元素。这对我来说真是一个弱点！
因此，底线是，如果我无法在 Blend 中设置对我的行为依赖属性的绑定，并且它不继承DataContext，为什么要费心使用依赖属性呢？我可以只使用 CLR 属性。
除非支持绑定，否则混合行为几乎毫无用处！我重新创建了您的倾斜行为，它支持在 Blend 4 中绑定，没有任何问题，所以我不知道您到底哪里出了问题。也许您可以重现我的简单示例，然后推断您的设置出了什么问题。
这是具有依赖属性的（非功能性）倾斜行为：
public class TiltBehavior : Behavior<FrameworkElement>
{
public double TiltFactor
{
get { return (double)GetValue(TiltFactorProperty); }
set { SetValue(TiltFactorProperty, value); }
}
public static readonly DependencyProperty TiltFactorProperty =
DependencyProperty.Register("TiltFactor", typeof(double), typeof(TiltBehavior), new UIPropertyMetadata(0.0));
}
然后只需创建一个新窗口并将行为放到网格上，Blend 就会创建以下内容：
<Grid>
<i:Interaction.Behaviors>
<local:TiltBehavior/>
</i:Interaction.Behaviors>
</Grid>
属性选项卡中提供了 Blend“数据绑定...”选项。
我使用 WPF 和 Silverlight 项目对此进行了测试。内置行为、触发器和操作都通过使用依赖属性来支持绑定，并且所有 Blend 示例都大量使用绑定，因此这has上班。
事实上，你可以删除一个内置行为，例如FluidMoveBehavior到你的网格并检查Duration是一个依赖属性，支持绑定。如果这不起作用，我有no知道发生了什么事！
让我们考虑一下绑定是如何作用于这些被称为行为的奇怪野兽的。
作为 WPF 或 Silverlight 程序员，我们非常熟悉诸如此类的绑定FrameworkElement。它有一个属性叫做DataContext我们可以操纵它来控制默认绑定源，并且当我们使用该属性时，嵌套元素会继承该属性don't覆盖它。
但行为（以及触发因素和行动）是not类型的FrameworkElement。它们最终源自DependencyObject，正如我们所期望的那样。但是虽然我们可以使用绑定any类派生自DependencyObject，我们熟悉的DataContext在这个低级别缺少，因此绑定必须提供源。That's不是很方便。
所以行为是从（无论如何在 WPF 上）派生的Animatable and Animatable源自Freezable. The Freezable类是依赖对象的简单性与框架元素的复杂性交叉的地方。这Freezable类也是更熟悉的东西（例如画笔和图像源）的基类。这些类不需要框架元素的全部复杂性，但它们想要参与有限的方式以及与它们相关的元素。
经过复杂的神奇过程，Freezable实例获取继承上下文：与它们最密切相关的框架元素，并且当使用默认绑定（没有源的绑定）时，Freezable使用DataContext而是它的关联元素。
事实上，当你了解行为时AssociatedObject是一个中心概念；对于行为来说，它是该行为所依附的事物。但重要的一点是，所有Freezable对象可以使用DataContext他们的AssociatedObject通过代理。
所有这些魔法是什么乔什·史密斯调用：
所以所有这一切都导致说由于希尔伯格冻结技巧，混合行为支持使用其关联元素的数据上下文作为默认源进行绑定。因此，行为绑定似乎“正常工作”，无需我们付出任何努力。因此，行为的用处要大一千倍。