Blend Behaviors - можете ли вы связать их свойства?

Question

В настоящее время я переношу несколько прикрепленных поведений, которые я создал для Blend Behaviors, чтобы они поддерживали перетаскивание в Expression Blend. Я заметил, что авторы поведения Blend склонны определять свойства поведения как свойства зависимостей.

Я создал поведение, TiltBehaviour, которое предоставляет публичное свойство зависимости, TiltFactor, типа double. В Expression Blend я могу установить значение этого свойства, однако, возможность добавить «Binding Data ...» неактивна:

Я также заметил, что Поведения распространяется DependencyObject, поэтому они не имеют DataContext и поэтому не могут наследовать DataContext элемента, к которому они присоединены. Это кажется мне настоящей слабостью!

Итак, нижняя строка, если я не могу установить привязку к свойству зависимостей моего поведения в Blend, и он не наследует DataContext, зачем вообще использовать свойства зависимостей? Вместо этого я мог бы использовать свойства CLR.

Answer 1

Редактировать: dain верен, вы все равно можете привязываться к DataContext, который создается искусственно, как часто вы видели, как люди привязываются к SolidColorBrush.Color? Он также работает, хотя SolidColorBrush наследуется от DependencyObject и, следовательно, не имеет DataContext.

См. this blog post on the inheritance context.

Дело в том, что с тех пор, как поведение привязано, они не появляются в логическом дереве и, следовательно, не будут наследовать DataContext.

Answer 2

Смешанное поведение было бы почти бесполезным, если бы они не поддерживали привязку! Я воссоздал ваше поведение наклон и поддерживает привязку в 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)); 
} 

Тогда просто создать новое окно и падение поведения на сетке и смесь создает это:

<Grid> 
    <i:Interaction.Behaviors> 
     <local:TiltBehavior/> 
    </i:Interaction.Behaviors> 
</Grid> 

и параметр «Связывание данных ...» доступен на вкладке свойств.

Я тестировал это как с проектами WPF, так и с Silverlight. Встроенные действия, триггеры и действия поддерживают привязку в силу использования свойств зависимостей, и все образцы Blend используют привязку сильно, поэтому для этого работает.

Фактически вы можете просто отбросить встроенное поведение, например FluidMoveBehavior, на свою сетку и проверить, что Duration, который является свойством зависимостей, поддерживает привязку. Если это не работает, у меня есть no Идея, что происходит!

---

Давайте рассмотрим, как именно обязательные работы для этих странных зверей называются поведением.

В качестве программистов WPF или Silverlight мы хорошо знакомы с привязкой к таким вещам, как FrameworkElement. Он имеет свойство, называемое DataContext, которое мы можем манипулировать, чтобы контролировать источник привязки по умолчанию, и это свойство наследуется вложенными элементами, когда не переопределяет его.

Но поведение (и триггеры и действия): не типа FrameworkElement. В конечном итоге они получены от DependencyObject, как и следовало ожидать. Но пока мы можем использовать привязку на любого класса, полученного от DependencyObject, наш знакомый DataContext отсутствует на этом низкоуровневом уровне, поэтому привязка должна обеспечивать источник. Это не очень удобно.

Так что поведение происходит (на WPF в любом случае) от Animatable и Animatable происходит от Freezable. Класс Freezable - это место, где простота объектов зависимостей пересекается со сложностью элементов структуры. Класс Freezable также является базовым классом для более знакомых вещей, таких как кисти и источники изображений. Эти классы не нуждаются в полной сложности элемента структуры, но они хотят участвовать в ограниченном пути с элементами, с которыми они связаны.

Через сложный волшебный процесс, Freezable экземпляры приобретают контекст наследования: рамочный элемент они наиболее тесно связаны, и когда по умолчанию привязка используется (один без источника), то Freezable использует DataContext из него ассоциируется элемент вместо.

Фактически, как вы узнаете о поведении, AssociatedObject - это центральная концепция; для поведения это то, к чему привязано поведение. Но важно то, что все объекты Freezable могут использовать DataContext своих AssociatedObject прокси.

Все это волшебство, что Josh Smith называет:

• Hillberg Freezable Trick

И так все это приводит к говоря, что из-за Hillberg Freezable Trick, Смешать поведения поддерживают связывание с использованием контекст данных связанного с ними элемента в качестве источника по умолчанию. В результате привязки к поведению, похоже, «просто работают» без каких-либо усилий с нашей стороны. Из-за этого поведение в тысячу раз более полезно.