Whilst editing a WPF view, the XAML designer claimed it couldn’t display a child user control due to a null reference exception. Looking at the stack trace, I noticed a wonderfully named method…
What seemed like a simple request to enable spell checking in a WPF application turned out to be significantly more work than I expected.
Specifically, applying a custom dictionary everywhere, without having to write wads and wads of duplicate code kept me going for a while.
We have found a problem whereby when a window loads, some of the buttons are disabled. Clicking anywhere on the window (even on the title bar) enables the button, but this doesn’t give a good user experience. Thankfully the fix is simple. You need to find a place in the view model code where all the data has loaded, all events have been raised, and all INC properties have been set. Then you add the following lines… That will fix the issue. Ideally you would do this in the base view model, but this requires having somewhere in there where you know all data has been loaded. If you have that, then consider yourself amongst the blessed
When laying out controls on a window or user control, it is common to end up with wads of XAML that looks like this: Before you even start adding in the controls, you have quite a lot of XAML just for laying out the grid itself. Enter stage left, the GridHelper class (round of applause please). With the addition of the appropriate line to the namespace section of your window or control (depending where you save the GridHelper class): …you can reduce the XAML spaghetti above to the rather more succint: The row or column definitions are now reduced to a comma-delimited list of heights or widths. These can be absolute or star values, and can take an optional minimum value (specified after the colon). Grid splitters Grid splitters are a common feature in complex layouts, and the GridHelper class allows you to add them without writing extra XAML. All…
I had the need today to add my own property to a WPF user control, and have that property available in the Properties panel of the Visual Studio designer, so the property could be set at design-time. The purpose of this was that my user control had a toolbar, and I had come across the need to use the control, but not show the toolbar. Simple eh? Well, not quite!
I was having some trouble with WPF data binding yesterday, where the binding looked correct, but the data wasn’t being shown. It turned out that I had forgotten an .Include() on the original query (this data is being sent across the wire through a WCF service, so I can’t use lazy loading), but along the way, I discovered a really useful blog post on how to debug WPF data binding.