December 11, 2007
Karl Shifflett decided that Mole II was not good enough, so he added in a feature which allows you to see non-public fields of the object you are inspecting. Now you can see properties and fields, which makes the debugging process even more rapid because the true state of your objects can be seen with ease. After we reviewed the new feature, Karl blogged about it and wrote an article on CodeProject. Check out his updates here: http://karlshifflett.wordpress.com/2007/12/11/mole-v22-black-ops-version-released/
As of this writing, this new feature does not display the private fields of an object’s ancestor types. It only displays the fields found in the object’s most derived partial. I think that needs to be addressed before it is truly “done,” but so far it’s a great start. Nice work, Karl!
November 26, 2007
Woodstock was a prototype; a “proof of concept” which really caught on and matured. After I published the Woodstock article a good friend and cohort in WPF crime, Karl Shifflett, began working on a better WPF visualizer. After a couple weeks of us discussing, prototyping, emailing code snippets, sharing/critiquing ideas, and him working around the clock, he finally published an article about it. His WPF visualizer, called Mole, is now publicly available, just waiting for WPF developers to download it and put it to use.
I highly recommend that you check out Mole. It is the WPF visualizer. Forget about Woodstock, use Mole!
November 21, 2007
I finally figured out how to fix a bug in Woodstock’s snapshot image processing logic. The bug prevented images from showing up in certain situations, but now all is well. Get the latest drop here:
November 20, 2007
As I’m sure you’ve already heard a thousand times in the past two days, Visual Studio 2008 has been officially released. Accordingly, Woodstock had to be recompiled against the RTM build, because the Microsoft.VisualStudio.DebuggerVisualizers.dll assembly changed between Beta 2 and RTM. I dropped the latest build on CodeProject.
A couple of guys actually complained to me about the fact that I used an image of Woodstock from the Peanuts web site, saying that it’s “deplorable” and such. One guy even threatened to report my “crime” to whoever officially owns that image, so that they can sue me. To avoid having those wonderful, fun, cheerful folks lose any more sleep, I removed the image. To be honest with you, it never even crossed my mind that there might be a legal problem with using a picture of Woodstock that I got from a Web site.
You can get the latest bits here: http://www.codeproject.com/useritems/WoodstockForWPF.asp
November 20, 2007
Once again, Karl Shifflett is the man. He took the time to fix the element snapshot code so that the images are no longer clipped. I integrated his code into Woodstock and updated the file downloads. To thank Karl for his amazing efforts, I added him as an author of the article.
Get the latest drop: http://www.codeproject.com/useritems/WoodstockForWPF.asp
November 19, 2007
I performed some stress testing on Woodstock today, and found a couple of weak points in the code which prevented it from working well with absurdly large visual trees. By “absurdly large” I am referring to a visual tree with at least 10,000 elements in it. Huge, huge, huge visual trees. It should not be too often that a WPF user interface has a visual tree of that immense size, but I wanted to be sure that Woodstock can handle it well (up to a certain point).
The two performance enhancements that I addressed are:
1) Nodes in the TreeView are now loaded on-demand. When you expand a node in the TreeView it then loads the children of that node, if they are not already loaded. This drastically reduces the load time for the Woodstock window when your visual tree has thousands of items in it.
2) The children of a WpfElement are now temporarily removed from its Children property, just prior to that element being sent over to the debuggee process to be populated with property information and a snapshot image. When the freshly populated WpfElement is returned back to the visualizer its child elements are added back to its Children property. This can cut down the amount of time it takes to get the property information and snapshot for a WpfElement, especially if that element has a very large number of descendant elements.
The new bits are available here: http://www.codeproject.com/useritems/WoodstockForWPF.asp
November 18, 2007
Karl Shifflett pointed out a nice improvement to the way I am associating a WpfElement and a DependencyObject in Woodstock. Instead of using an attached ID property, I now keep a Dictionary<int, DependencyObject> in WpfElementTree and use that in the lookup process. It’s not a bug fix, but just an optimization and a cleaner way of implementing that logic. Thanks Karl!