Modify or 'tweak' an existing TreeViewItem control template?

Question

Ok... this is sort of a two-parter here. (Sort of. May actually just be one. That's what I'm hoping anyway.)

First, more generally, is it possible to target, via XAML only, a named item in a control's template? For instance, if a control's template has a ContentPresenter named 'PART_Foo' and we want to specifically set the HorizontalAlignment on that specific item to 'Stretch' via pure styling, can it be done? I know we can do this in the OnApplyTemplate override of a subclass where we explicitly search for the control by name then set the property in code, but again, we're hoping for a XAML-only solution so we can do this strictly via styling and not subclasses, which are mostly discouraged anyway except for specific use-case scenarios.

Also, we do not want to have to manually specify the template for the control as we want the current theme to determine what that template is and thus how the control appears. We just want to say 'In whatever template the theme has chosen, if there's a part named 'foo', set this property on it via pure styling. If a part with that name isn't found, do nothing!

The desire for a XAML-only approach is more because of the second part, which is we're targeting a generated container object, not the control itself, meaning it wouldn't be a straight subclass anyway as we'd have to muck around with ItemcontainerGenerators and such, which is a real pain in the a$$, especially when the ItemsControl is virtualized.

For specifics, our ultimate goal is to single out the Border named 'Bd' in a TreeView's TreeViewItem's template and set its attached property 'Grid.ColumnSpan' to '2' instead of its default of '1'. That's it! It amazes me how something so simple seems damn near impossible without manually replacing the entire TreeViewItem's template or resorting to a code-behind-based solution.

Answer 1

No, this is not possible using XAML only. You would at least have to write an attachted property for this (wich you then could use in XAML). And that would only work if you do not have any controls being created on the fly at runtime as it happens in virtualized lists. It would look something like this: c:TemplateHelper.ReplaceStretchForTemplateItemName="PART_Foo". In the changed handler you would walk the visual sub tree of that control using VisualTreeHelper and look for that name and apply whatever you want.

Modifying the a template like this is flawed tough and considered to be bad practise. It is very likeley that there is a theme or will be in the future that does not have "Part_Foo" or that "Part_Foo" is something completely different than you expected it to be. Themes and thus the ControlTemplates are subject to change. New themes will appear (and automatically applied to your application) as Microsoft updates its operating systems and if you support custom themes you designers might come up with a theme that is different.

You could argue that this a disadvantage of ControlTemplates and it to some extend it is. But then again try customizing Controls in windows forms (or any other UI framework on this planet)... It's just that when getting used to the immense felxibilty of WPF it's harder to accept limitations, which in this case are by design.