views:

88

answers:

1

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? Some 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.

+2  A: 

@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.

Jason Stevenson
Wow, finally an answer after all these years, thanks. I already suspected that there is no way. I write widely reusable and very general behaviors to, but still there are some cases that don't always make sense for all `DependencyObject` types. So, I think I'm gonna file a feature request these days.
herzmeister der welten