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…
Dot Net What Not Posts
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 have always wished for my computer to be as easy to use as my telephone; my wish has come true because I can no longer figure out how to use my telephone.”
Danish computer scientist Bjarne Stroustrup
One of my first posts on this blog was about the problem of using anonymous types when you want to send the data outside of your current class. At the time, the only way I knew to solve this was to create a simple class that had the structure of the anonymous type, and create one of these instead of the anonymous type. I do this regularly, although I have taken to naming such classes CustomerOverview, OrderOverview, etc, instead of CustomerTmp as I did in that blog post, as they aren’t really temporary classes at all, they are slim, flattened overviews of the class.
This approach works well, but it can have its downsides. One, as mentioned in that post, is that it is easy to end up with a proliferation of classes, many of which may only be used in one location in the code. If the classes represent lightweight views of entities in the model (such as the two examples shown above), then I don’t worry about this, as it is clear what they represent, and it’s fairly certain that I’ll end up using them somewhere else at some point.
I previously blogged about a seemingly innocent LINQ problem that had me baffled for ages, which was how you sort or filter an entity’s child collection in Linq. For example, if you want to pull a collection of customers, and include all of their orders from this year, but none from earlier, then there doesn’t seem to be a simple way to do this in Linq. You need to do the query in two stages, the first which builds an anonymous type, and the second which links the to parts of it together. See that post for more details.
I also blogged about the problem of Linq not including child entities when doing joins, which requires you to cast the query to an ObjectQuery<> so you can use the Include() method on it.
The problem comes when you want to combine the two methods, meaning that your query needs to be constructed in two stages to ensure that the sorting or filtering of the child collection is done correctly, but you also need to cast the final result to an ObjectQuery<> before you send it out over WCF. The problem arises because you need to enumerate the query before doing the Include(), as that is the only way to ensure that the sorting is done, but calling AsEnumerable() gives you an IEnumerable<> (reasonably enough), which can’t be cast to an ObjectQuery! So what’s a fellow to do? Good question, and one that had me going for ages.
I am currently working on an application where I want to have a search feature that allows people to search for businesses within a certain distance of their home (or anywhere else they care to choose). I have some old UK postcode data knocking around, and was going to use that. For those not familiar with them, UK postcodes are made up of two parts, a major (also known as “outward”) part, and a minor (or “inward”) part. The major part is one or two letters followed by one or two digits, and the minor part is a digit, followed by two letters. Examples of valid postcode formats are M25 0LE, NW11 3ER and L2 3WE (no idea if these are genuine postcodes though). Coupled with the postcodes are northings and eastings. These odd-sounding beasties are simply the number of metres north and east from a designated origin, which is…
Of course, we professional programmers never make mistakes, ahem. That’s why we never need to use debuggers, ahem.
Well suspend belief for a moment, and assume that I had a bug in the code I was developing. You know the feeling, you stare at it, you write unit tests, you stare at it some more, and still can’t work out why on earth Visual Studio is claiming that there is an error in your code, when it’s so obvious that there isn’t. You even get to the point of talking to your computer, pointing out the error of its ways…
I was underwhelmed at being awarded two separate recognitions for my contribution to the community.
Read on and be as underwhelmed as I was!
Sadly, whilst building a solution yesterday, my machine started behaving in a very weird manner, with applications not responding, the taskbar disappearing and so on, followed by the dreaded blue screen of death. When I checked the event log after pulling the plug out (I hate doing that!) and rebooting, I found lots of errors, which led me to a Microsoft Connect article (now sadly removed) where someone was reporting a very similar problem.
To my amazement, the very last comment by a Microsoft employee in response to this bus report was “This is known issue, this bug was resolved by mistake, we are already addressing this issue.”
Surely they didn’t mean that did they? Someone tell me I read that wrong!