How people always try to do things the hard way with WPF
I lurk a lot on StackOverflow - it sometimes strikes me how hard people try to make their problems. Instead of using a simple solution, they will over-engineer it until it becomes impossible to do what they’re trying to accomplish. If you are trying to bind to the parent control via templatebinding and do a trigger that is dependant on the parent control being a ContentControl – you are creating trouble for yourself down the road.
I think, all the problems stem from trying to force a solution into XAML or more eloquently trying to solve all problems using the hammer. It may be that the WPF technology is so new – or it may just be the fact that people are stupid… but they tend to forget that ‘Simple is better’ and ‘use the appropriate tool for the task at hand’. Common examples follow:
1. “I want to have these default values set on all Buttons”
Use a Style in App.xaml with key-tag blank and set all the properties.
2. “I only want some buttons to have this default style”
Inherit from Button (e.g. StyledButton) and do 1.
3. “I want to use data from a parent data object in my childTemplate”
Put parent data object into ObjectDataProvider and bind to that or make an extra property on your viewmodel (viewmodels are cheap compared to maintaining a complex binding) – stop using relative bindings!
4. “I want to inherit from another style and then just set these few extra properties”
Don’t. It is not a violation of DRY to repeat property setters in different styles.
This advice might seem weird coming from a guy that specializes in the “new and fancy” world of WPF, but the problem with all frameworks is that they always provide edge-case functionality. Functionality that might seem nice on the surface but will bite you where it hurts if you use it. RelativeBindings might seem like a good idea – but when I try to use them, the views will continue to haunt me when I do refactorings or re-create a layout. They are pain-point that I would rather be without. And of course – no rule without exceptions – but for a complete ERP solution, I have managed without them. Having styles inherit from each other might also seem like a good idea – but the problem is that come 6 months – you now have an(or more if you have inheritage styling trees) extra place(s) to look for that setter that is causing you headaches on top of local values, inherited values, bound values etc.
Just because you are in XAML doesn’t exempt you from using good ol’ OO-techniques!