Friday, April 18, 2008 - Posts
Locating the active item in the solution explorer
Say you are working with a code file. At some point, you “Go To Definition” of another type, and now you have its code file opened. Or maybe you just run the solution to debug a weird issue that’s happening, turn on “break when exception is thrown” option, and just when the exception is thrown, Visual Studio gets activated, and you get the relevant code file opened at the appropriate location.
Now, say you have a typical solution, which contains solution folders and many projects. Can you quickly locate the project/folder where the file is?
I’ve found that MOST developers simply go fishing for the file, or look at the file path and pray the solution folders actually match physical folders so they can manually traverse it, etc. Turns out there’s a much better alternative, which is to turn on “Track Active Item in Solution Explorer” under Tools > Options > Projects and Solutions:
Now after clicking OK, the solution explorer is automatically expanded and the proper node selected:
Much better, right?
Well, turns out that I’m pretty darn sure this option was ON by default in VS2002 and maybe even 2003. I reported this back in 2005 with a suggestion to turn it on by default again. It was resolved “By Design”:
…due to a significant amount of customer feedback we’ve received. The concern that people were raising about having this option enabled by default was that there were certain scenarios where there was a performance hit.
Well, I tried it with the certainly big Enterprise Library 3.1 solution (no unit tests), which contains 38 projects with 1867 files in 1136 folders and haven’t noticed any significant issue associated with enabling that option.
If you think the usability improvements from having this option on surpass the remote chance that in certain scenarios there may be a performance hit (?), please go and vote to get it fixed. Believe me, we CAN make it change. I’m going to reopen the bug if there are significantly new voters.
posted Friday, April 18, 2008 1:44 AM by kzu with 5 Comments
For those that think Microsoft Connect is useless
A while back I reported both through my weblog and Microsoft Connect what I thought was a serious flaw in the WPF validation infrastructure for ValidationRule and Binding. The issue, in short was:
The validation check is invoked during any attempt to update the underlying data … before a value converter is called (if present)…
Take special note that this was not some undocumented, strange behavior, but rather something that was explicitly explained on MSDN where the validation process was explained as part of the design.
But based on my feedback and the 13 other people that voted to fix the bug, it looks like they just did so (at least that’s what the bug status shows).
Pretty significant IMO, especially since in my experience these kind of “breaking changes even if the existing behavior was already broken” issues rarely get fixed, no matter how obvious the error might be.
Continue blogging and bitching about stuff that bothers you, but don’t forget to report it formally: it might make a difference and we may end up getting a better product from Microsoft (it may take years, but hey, it’s a learning process!).
posted Friday, April 18, 2008 1:12 AM by kzu with 1 Comments
/kzu dev↻d