c# wpf datatemplate

¿Hay una manera de construir una plantilla de datos con solo C#



wpf datatemplate (2)

¿Hay una manera de construir una plantilla de datos sin usar el método deprecated FrameworkElementFactory o XamlReader.Load de interpretación de cadenas para codificar (pregunta relacionada) u (otra relacionada) ?

DataTemplate dt = new DataTemplate(); StackPanel sp = new StackPanel(); ComboBox cellComboBox = new ComboBox() { Visibility = Visibility.Collapsed }; CheckBox cellCheckBox = new CheckBox() { Visibility = Visibility.Collapsed }; sp.Children.Add(cellComboBox); sp.Children.Add(cellCheckBox); // then add the stackpanel somehow?

Actualización: ¿Por qué? Esto es para un nuevo programa que puede tener que ser soportado por años. El análisis de cadenas de XamlReader en el tiempo de ejecución para algo que tiene un constructor, métodos, propiedades ... se siente confuso. FrameworkElementFactory ha quedado en desuso en varias versiones, pero nunca tuvo un reemplazo real.


¿Hay una manera de construir una plantilla de datos con solo C #

Sí, utiliza el método FrameworkElementFactory o XamlReader.Load para crear un DataTemplate programáticamente.

... sin usar el método FrameworkElementFactory o el método de XamlReader.Load .

Respuesta corta: No.

¿Por qué necesitarías otra manera cuando ya hay dos? También tenga en cuenta que es perfectamente correcto usar la clase FrameworkElementFactory si no desea usar cadenas. A pesar de lo que dice la documentación en MSDN, este tipo no está realmente marcado como obsoleto o en desuso en .NET Framework 4.7.2.


Para elaborar la respuesta de @ mm8: no, porque si inspecciona el método FrameworkTemplate.LoadContent , encontrará que una plantilla es básicamente un contenedor que utiliza FrameworkElementFactory o TemplateContent para cargar el contenido. corriente. Así que estas son las únicas dos formas en que una plantilla puede operar.

Personalmente, de los dos, recomiendo usar XAML (como un archivo * .xaml en lugar de una string ), porque es mucho más legible, pero también porque FrameworkElementFactory tiene una funcionalidad limitada, es decir, solo admite propiedades de dependencia y eventos enrutados no puede crear una fábrica que establezca una propiedad CLR normal o un controlador de eventos). Sin embargo, tiene una ventaja sobre XAML : admite clases genéricas, por lo que tal vez una combinación de ambas sea el enfoque más adecuado.