W jednej aplikacji pracuję znalazłem ten kod -celu korzystania FrameworkElementFactory
public class MatrixCellTemplate : ColumnDataTemplate<MatrixCellContainer>
{
}
public class ColumnDataTemplate<T> : DataTemplate where T : FrameworkElement
{
public ColumnDataTemplate()
{
FrameworkElementFactory factory = new FrameworkElementFactory(typeof(T));
VisualTree = factory;
}
}
Ten MatrixCellTemplate
służy do ustawiania CellTemplate
niestandardowej DataGridTemplateColumn
(później dodano do DataGrid.Columns
kolekcji) jak ta -
<DataGridTemplateColumn.CellTemplate>
<Matrix:MatrixCellTemplate />
</DataGridTemplateColumn.CellTemplate>
nie jestem pewien, co jest zaletą korzystania z tej FrameworkElementFactory
i jaki problem mogę zmierzyć gdybym bezpośrednio korzystać MatrixCellContainer
jako szablon komórkowy -
<DataGridTemplateColumn.CellTemplate>
<DataTemplate>
<Matrix:MatrixCellContainer>
</Matrix:MatrixCellContainer>
</DataTemplate>
<!--<Matrix:MatrixCellTemplate />-->
</DataGridTemplateColumn.CellTemplate>
Dzięki H.B., +1 dla wycofanych informacji. Nadal będę szukał w jakich przypadkach sensowne jest użycie FrameworkElementFactory z DataGrid. – akjoshi
Jednym z celów jest wydajność. Jeśli masz dużo kontroli za pomocą złożonych szablonów, tworzenie formantów z XAML jest znacznie wolniejsze niż tworzenie z kodu. – TcKs
@TcKs: Pokaż mi swoje dane empiryczne, ponieważ nie uwierzę w to inaczej, mówimy tutaj o szablonach, kontrole nie są tworzone, dopóki nie będą potrzebne. Jeśli zdefiniujesz szablon w kodzie lub w XAML nie powinno mieć znaczenia, obie są kompilowane, chyba że użyjesz luźnego XAML, co jest mało prawdopodobne. –