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!
Dot Net What Not Posts
I had been having some serious grief with Visual Studioâ€™s unit testing tools. VS was complaining that some tests did not exist, and others called methods that didnâ€™t exist. Both claims were total lies as all methods in question existed, and could be found by using the â€œNavigate toâ€ feature in VS.
I had two basic errors when I tried to run tests. One was of the form “Method TestProject.SystemsRepositoryTest.CreateNewCamera does not exist” when the method did exist. I could right-click the test in the Test Results window and choose â€œOpen testâ€ and it would take me there. However, when trying to run the test, VS claimed it didnâ€™t exist.
The other error I got was of the form “Test method TestProject.SystemsRepositoryTest.GetAllCameras threw exception: System.MissingMethodException: Method not found: ‘System.Collections.ObjectModel.ObservableCollection`1
Thanks to these problems, I have wasted loads of time debugging things that could have been fixed with unit testing. It has been frustrating to say the least!
Well, I finally found the answerâ€¦
I opened the bin/Debug folder in the test project in Windows Explorer and deleted everything in it. I then rebuilt the test project, and my tests ran fine.
For some odd reason, it looks like rebuilding the test project wasn’t actually changing the DLLs in the folder, so it was using old versions, in which the methods didn’t exist. Deleting them all forced VS to grab fresh copies of the referenced DLLs, and rebuild the test project’s DLL.
I donâ€™t know if this is a bug in Visual Studio 2010, but it doesnâ€™t seem to be a feature that I would have added in by choice!
A common scenario is to have a button on a view that is bound to a command on the viewmodel. You can also have an ABCCommandCanExecute() method on the VM that tells the view whether or not the button can be clicked.
This is all fine until you want to ask the user to confirm the action that will be performed when they click the button. For example “Are you sure you want to reformat your hard disk, dial up all the people in your contact list and reformat their hard disks, and then destroy the world?” It’s kind of rude to do this without confirmation first.
The problem is that when you use WPF binding to bind the VM’s command method to the button’s Command property, you lose control over the execution process, and so can’t inject a message box into the flow.
When you use Linq to create a query against an entity framework model, a common scenario is to use the .Include() extension method to make sure that any child objects are also loaded. This is mainly useful when the results of the query are to be sent over WCF, where the client is disconnected from the source of the query, and so cannot go back to the database to pick up any child objects as needed.
This works fine for simple queries, but falls apart when you want to do anything clever, like joins or shaping.
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.
I came across an innocent-looking Linq problem the other day that really had me baffled for some time.
It’s easiest explained using the ubiquitous Northwind database (although just about any other relational database would probably do). Suppose you want a list of customers with their orders. Pretty easy eh?
Erm no, it wasn’t!
Although it’s not actually a .NET issue, I decided to blog about it anyway!
I’ve been looking at design patterns quite a lot recently. I have always been a “bung it all in the code-behind” kind of programmer, which is an easy way to program, but messy. You end up with spaghetti code that’s hard to maintain and impossible to test automatically (not that I ever tried mind you!).
I decided to learn some new skills, and discipline myself to programming the Big Boys’ Way. I dutifully went to Amazon and spent far too much on books, and sat down to read them all. Most were fairly tough going and dull. I was beginning to think it wasn’t worth the effort, until I came across Head First Design Patterns, which was a breath of fresh air. Apart from the slightly wacky style, the explanations were very good.
My only gripe with the book is that it’s very Java-oriented. Given that design patterns are language-agnostic, this is totally unnecessary. Most of the time it didn’t spoil the book, but in a couple of places it really annoyed me. However, it’s still the best design patterns book I’ve read by a long way.
I hope to blog more about this subject. Watch this space (unless you’ve got anything better to do of course!)
Linq is great for grabbing entity objects. The code is simple, and you end up with known objects that you can use.
But, when you want to deal with anything slightly off the beaten track, it gets a bit harder. For example, if you have a Linq query that returns an anonymous type, you can easily manipulate it in the same code block.
Here I detail an early exploration into the world of anonymous types