In Silverlight (and probably WPF), when I define a System.Windows.Interactivity.Behavior<T>
for e.g. an ItemsControl
, like
public class SomeAwesomaticBehavior : Behavior<ItemsControl>
{
}
it will appear in Visual Studio's XAML editor (and probably in the Designer too) even for ordinary, non-Items-Controls and throw nasty runtime exceptions. This is contrary to Attached Properties which will appear only for intended types.
Is there a way to restrict that visibility? So开发者_开发技巧me magic attribute maybe (although that would be a redundant declaration)?
If there is no way today, I hope there will be so in the future? Because it surely does confuse co-workers and designer folks when a lot of Behaviors pop up that don't have anything to do with the current object.
Update: I have filed uservoice items.
Silverlight: http://dotnet.uservoice.com/forums/4325-silverlight-feature-suggestions/suggestions/1224253-restrict-behavior-visibility?ref=title
WPF: http://dotnet.uservoice.com/forums/40583-wpf-feature-suggestions/suggestions/1224259-restrict-behavior-visibility?ref=title
@HeRz you are correct, there is no way to filter behaviors by their targeted type. Blend (and probably vs designer) use reflection to find all of the types you create which inherit from base type Behavior and displays them in the assets list.
Blend will prevent you from dragging a behavior or trigger onto an item which it is not intended. So that should help prevent their misuse.
I usually try to write behaviors as reusable pieces of code, not scoped to a specific case. They are simply tools with specific purposes.
精彩评论