I have used Visual Studio.NET 2002 since it came out, and Visual Studio.NET 2003 since beta 2. Now, don't get me wrong Visual Studio.NET is has a great IDE, a great C++ compiler, and a great debugger, but something is lacking. In my travels through development project after development project, I began to use the STL more and more to accomplish whatever I had in mind at the time. Now, as every programmer knows, nothing works on the first try, and often not on the second, third, or forth. That's where every programmer's favorite tool comes in, the debugger. But as I found, sometimes even the best debugger available will not give me the information I need to squash those flaws once and for all. STL containers simply did not parse in the way I wished they would. Sure, I can view _Mylast and _Myfirst in a vector, but what good does that do when my vector is 1200 elements long! Perplexed and yet slightly intrigued by the problem, I sought a solution. VSEDebug was born.
VSEDebug is the last revision of a line of rather bad attempts at solving the problem. Initially, I had envisioned that I would replace the STL container elements in the Visual Studio.NET debug windows with my own parsers, and be done with it, but this soon proved impossible. Not only could I not replace the information currently in the debug windows, I couldn't read it at all. The second attempt realized that it would be more beneficial to replace the Visual Studio.NET windows with windows of my own design. I could build a better mousetrap! The intial strides toward such a solution proved successful, within a short time I had four of my own debug windows up and displaying everything a normal Visual Studio.NET window would, only slower and clunkier. But hey, I'm not done yet. Then I added support for custom types, integrating the parsing code right into the add-in code. Bad Idea. Before long I realized how hard maintence and extension would become, and I realized a script solution would suit me best. Furthermore, the fact that I had to go very lowlevel into an STL container in order to extract the values meant that other STL implementations would be left out in the cold with my current version. So, I integrated a script engine into the code and wrote scripts in JScript.NET. This was a Good Thing. Easier to test and extend, the Add-In took on a life of its own. But, there was a problem: it was still very slow.
VSEDebug was taking around 4-5 seconds to update a single window. Ugh, slow, not good. How could I expect myself to use such a product, let alone other users, if it was too slow to work with. Operation Speed Attrition! I spent about a week streamlining performance, and now it feels only a bit slower than the normal Visual Studio debug windows. USEABLE!
After adding a bit of flare and polish, it is finally ready to see the world. Enjoy!