Kevin Dente's Blog

From time to time I find myself faced with a really annoying problem - a Windows application that has positioned itself offscreen. This usually happens for one of two reasons:

The inimitable Jeff Atwood of Coding Horror fame (or is it Stack Overflow fame now?) recently blogged about the importance of typing skills for developers. In typical smackdown style, he posited that "coding is just typing". Jimmy Bogard disagreed, saying that the number of lines of code typed per day is actually quite small, and the productivity difference for typing that much code is quite negligable.

In an effort to plumb the outermost depths of blogging lameness, I'm writing today to announce my participation in a podcast about software development. Why is that lame? Because the podcast started over two months ago. Yes, that's right, I can't even be bothered to pimp my own stuff. Like I said, lame.

Scott Hanselman tweeted a link to Daniel Cazzulino's blog post about automatically synchronizing the Visual Studio Solution Explorer with the active item open in the editor. It's a great tip, but I personally have never been a fan of the Track Active Item option - I find that it slows down the IDE, causes distracting visuals, and often just isn't the behavior I want. I do, however, often want a way to manually sync up the Solution Explorer with my currently open item.

Sadly, it appears the answer is "yes". Specifically, the debugger has a huge limitation - one that's been there since Visual Studio 2005 (maybe even 2003). You can't set a breakpoint on the first line of an anonymous function. Consider, for example, the following:

I finally got around to installing the latest beta of Windows Live Writer, my favorite blogging tool. As part of the install, it displays the following dialog:

 A while back I blogged about a problem I had installing Visual Studio 2005 on a fresh Vista install - it complained about requiring Windows XP SP2. I never found a satisfactory explanation, but copying the DVD contents to the hard drive worked around the problem. The stock suggestion was to check the Compatibility settings on the property page for setup.exe -  but in my case no compatibility mode was set. Or was it?

Maybe this is common knowledge, but my co-worker and I spent some time chasing this down today, so I figured I'd post it in the hope that it will save other people some time.