2010-09-10 10 views
6

En Silverlight (y probablemente WPF), cuando defino un System.Windows.Interactivity.Behavior<T> por ej. un ItemsControl, comoRestringir la visibilidad del comportamiento de Silverlight/WPF

public class SomeAwesomaticBehavior : Behavior<ItemsControl> 
{ 
} 

que aparecerá en el editor XAML de Visual Studio (y probablemente en el diseñador también) incluso para los no ordinarios, Artículos-Controls y lanzar excepciones de tiempo de ejecución desagradables. Esto es contrario a las Propiedades adjuntas, que aparecerán solo para los tipos previstos.

¿Hay alguna manera de restringir esa visibilidad? Algún atributo mágico tal vez (aunque eso sería una declaración redundante)

Si no hay forma hoy, espero que así sea en el futuro? Porque seguramente confunde a compañeros de trabajo y diseñadores cuando aparecen muchos comportamientos que no tienen nada que ver con el objeto actual.

Actualización: He archivado los artículos de usuario.

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

Respuesta

3

@HeRz estás en lo correcto, no hay manera de filtrar comportamientos por su tipo de objetivo. Mezcle (y probablemente contra el diseñador) use la reflexión para encontrar todos los tipos que crea que heredan del Comportamiento de tipo base y los muestra en la lista de activos.

La mezcla le impedirá arrastrar un comportamiento o disparar a un elemento que no está destinado. Entonces eso debería ayudar a prevenir su mal uso.

Por lo general, intento escribir comportamientos como fragmentos de código reutilizables, sin alcance para un caso específico. Simplemente son herramientas con propósitos específicos.

+0

Guau, finalmente una respuesta después de todos estos años, gracias. Ya sospechaba que no hay forma. Escribo comportamientos ampliamente reutilizables y muy generales, pero aún hay algunos casos que no siempre tienen sentido para todos los tipos 'DependencyObject'. Por lo tanto, creo que voy a presentar una solicitud de función en estos días. – herzmeister

Cuestiones relacionadas