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
Dot Net What Not Posts
OK, so hands up who knows the difference? Hmm, just as I thought, not many. Don’t worry about it, nor did I until just now! Rather than rambling on (as usual), I’ll just point you at a StackOverflow question where this was answered as clearly as this is likely to be answered anywhere! http://stackoverflow.com/questions/2876616/returning-ienumerablet-vs-iqueryablet By the way, if you just query your EF context and don’t explicitly convert your results, you’ll end up with an IQueryable<T>. If you use .AsEnumerable(), you’ll end up with an IEnumerable<T> (surprisingly enough).
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…
One annoying problem is when sometimes you try to build your solution, only to get a pile of compilation errors due to a missing DLL. This is often caused by one of the DLLs not downloading from NuGet. The package will be in packages.config, but only the .pdb file gets downloaded.
Even more annoying is when you’re the only developer to have this problem. Everyone else can build the solution without problem.
The answer is fairly simple, but not obvious. Read more for the details.
It seems we aren’t the only ones to find filtering and sorting child entity collections unnecessarily painful. Someone has been kind enough to write a Nuget package (part of a suite of them by the looks of things) that simplifies your code significantly.
This package removes the need for some of the tortuous hoops we had to negotiate before.
A fairly standard set up for me is to have a solution in which I have a Data project that contains an EF6 .edmx file, generated from an existing database. I then split the entities into a separate Entities project, and have a Repositories project that references them both.
The problem was, I wanted to write unit tests against the code, but couldn’t work out how to do it. This post shows what didn’t work, and then what did.
When refactoring, it’s often hard to see which methods can easily be moved to another class, and what depends on what. Visual Studio has a built-in tool that can make this pretty easy, and almost fun! For a quick video overview of the tool, see this Channel9 video. The current article covers a lot of what is in that video, but concentrates on how to use the tool for refactoring. It’s worth watching the video, as there is a lot more to this than will be shown here. Note: The dependency graph feature is only available in the Grown Up versions of Visual Studio, ie Enterprise, Ultimate or whatever-they-call-it-this-week versions Creating a dependency graph To get started, click the Architecture menu, choose Generate Dependency graph, and then For Solution… Sadly, you only seem to be able to do this for a whole solution (the For Include File option is for C++…
A few years ago, I blogged about how to implement an “Are you sure” pop-up in MVVM. Well, I’ve grown up (a bit) since then, and realised that the code there wasn’t testable. I therefore take great pleasure in presenting for your delight, a testable “Are you sure” pop-up in MVVM. Aren’t I kind 🙂
Being good boys and girls, we want to write testable code, so if by some miracle we ever get around to writing unit tests, we can run them safe in the knowledge that they stand a fetid dingo’s kidney’s chance of working! One of the main issue involved here is ensuring we keep all view-related code out of the view model.
This post explains how to do it (with some pointless pictures)
As my regular reader will doubtless remember, I recently blogged about the important lesson I learnt while solving problem 8. I prophetically commented there…
“So, am I going to contemplate my problem domain before diving in and coding next time? Probably not, but at least if I don’t, I might have some idea where to look when the bug reports come in!”
Hmm, I thought I was joking! Well, sadly I wasn’t.
As I briefly mentioned in my rant about the F# fanboy lies, I have been using Project Euler to help me learn F#. I have got as far as problem 8, which was to find the largest product in a series of digits.
Apart from the fact that this was an interesting problem, I learnt a very important lesson from this one, and thought it worth sharing.
Leave a Comment