A quick tip showing how to tell the XAML designer the context for sections of code that are not under the current DataContext. This helps keep your XAML error-free, and gives you Intellisense where you otherwise wouldn’t get it.
Category: <span>XAML</span>
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…
I kept having problems when I opened a XAML file, in that the designer would show the following… This makes it somewhat hard to design a view when you can’t see the design! It turns out that when the XAML designer loads, it attempts to run code in your view model. There is some (questionable) justification for this, but overall, it’s a huge pain, and is one of the reasons why editing XAML files can be such a slow and tedious process. However, there is a way to mitigate the problem. If you can identify which parts of your code are causing issues, you can add code to prevent them from running when you are in Visual Studio. First you need to add the following line to the top of your code file… …then wrap the offending code in a check as follows… Apart from the fab method name (who…
I’ve recently discovered a very useful property that’s been available since .NET 4.5, called Delay. It’s used in the XAML when binding a property, and it delays sending the binding back to the ViewModel for the number of milliseconds that you specify. For example… In this example, the SearchText property will not get updated as soon as the user types, but rather will wait 1 second from when the user finishes typing to update the property. This is beneficial when you have a service call, or search method that is triggered when the bound property is changed. Here are two links that describe the usage and functionality very well: http://www.jonathanantoine.com/2011/09/21/wpf-4-5-part-4-the-new-bindings-delay-property https://msdn.microsoft.com/en-us/library/system.windows.data.bindingbase.delay(v=vs.110).aspx#Version%20Information
You have probably noticed that Visual Studio can sometimes take an age to load a XAML file. The reason for this is because it runs any code it can find before displaying the designer. This can take a while. Sometimes, you might see something like this… This happens when Visual Studio encounters an unhandled exception in the code it’s running while trying to load the XAML file. This is, to say the least, somewhat annoying. You may be tempted to click the middle link that offers to disable running project code in the designer. Don’t. Trust me, you don’t want to go there. Really, I’ve done it, and it took me about an hour to get the designer back into a workable state. Whilst this sounds like a good idea in theory, in practice it has all sorts of side-effects that you probably didn’t consider. For example, if you use…
Whilst working a WPF window, I ended up dumping loads of small jobs onto another developer, as he was the main one working on the XAML file for the window, and if we both tried to edit the file, we ended up with conflicts. After dumping the umpteenth extra job on him, I was trying to work out if there is a way I could ease his burden a little. There had been quite a few new issues where the extent of my involvement had been to modify the database and update the model. After that, I had to pass it over to him, to avoid us stomping on each other when working on the same files. So, I got to wondering if there was any way we could split the new quote window up, so multiple people could work on it at the same time. I immediately rejected using…
One of the great things about WPF is that you can declare all your binding in XAML, and not have to write any code. One of the most painful things about WPF is that you can declare all your binding in XAML, and not have to write any code. Huh? OK, so I am tired, but I’m not that tired, there was some sense in those first two paragraphs! XAML binding is extremely powerful, and allows you to do fab things without having to write a lot of C# (or VB.NET if you’re weird). However, when things don’t work as you expected, it’s very difficult to debug XAML. With C#, you can step through the code line by line, and see where it went wrong. You can’t do that with XAML. However, you can get some clue as to what went wrong using System.Diagnostics.PresentationTraceSources. Never heard of it eh? Don’t feel bad, nor had I…
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…
Leave a Comment