Article about WPF element trees

I just published an article on CodeProject which discusses subtleties of the visual tree and logical tree in WPF.  It is accompanied by a small application which can be used to research the topics in more detail.  If you want to check it out, here’s the link:

http://www.codeproject.com/useritems/WpfElementTrees.asp

Advertisement

Forget about Woodstock, get Mole!

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!

Woodstock snapshot image bug fix

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:

http://www.codeproject.com/useritems/WoodstockForWPF.asp

Woodstock runs in VS2008

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

Woodstock element snapshots improved

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

Woodstock is now much faster

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

Minor tweak to Woodstock

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!

Enormous improvements to Woodstock

I solved the BIG problem in Woodstock today.

It dawned on me that I can lazily load the element property information and snapshot images, by having two-way conversations between the debugger and debuggee processes, just by using the standard Visualizer API! This means that the whole timeout problem is gone, because a huge amount of data is no longer being serialized all at once. And, this enabled me to add in support for viewing snapshot images of every element in the tree, not just the one you initially selected!!

I added a thorough explanation of how all this works to the article in the “Lazily Loading Element Information” subsection, under the “How It Works” section. I’m so glad that I finally resolved this crippling issue. Now Woodstock is a truly reliable, robust, fast, and dependable WPF debugging tool.

The only remaining issue that I know of is if you let it run for a long time. Eventually a RemotingException is thrown while some GDI+ code is executing, and the visualizer crashes. I don’t think there’s a way for me to work around that bug…

Go get it! http://www.codeproject.com/useritems/WoodstockForWPF.asp

Looking for advice about Woodstock

[EDIT]

Shortly after I wrote this post I realized how to solve this problem without trying to resort to anything crazy like named pipes or writing files to disk (which didn’t work anyways).  To see how I overcame this problem, check out this post.

[/EDIT]

I have been working feverishly on Woodstock, my debugger visualizer for WPF. The one fundamental problem I have is the fact that Visual Studio has a timeout for the function which does the heavy lifting of processing every element in the visual tree. Since that function can take a long time to complete, Woodstock can become unusable on a very slow machine or an app with a gigantic visual tree because VS keeps reporting “Function evaluation timed out.” In fact, my new machine running Vista Pro at work is so horribly slow and clunky that Woodstock almost always times out. Oddly enough, my old XP machine at home almost never times out… (thanks for the killer new OS, Microsoft!)

The method which has a timeout applied to it is my ElementTreeVisualizerObjectSource.GetData(). I think the timeout is there for deadlock detection, but I’m not sure. Regardless, I need to figure out a way to have the visualizer (which lives in the debugger’s process) and the ElementTreeVisualizerObjectSource (which lives in the process of the code being debugged) communicate outside of using GetData(). That way the method calls won’t be subject to a timeout. I tried opening a WCF service in GetData(), assuming that I could somehow have the two processes communicate via named pipes, but my complete ignorance of WCF made it impossible.

I also tried spawning a worker thread in GetData() which wrote the visual tree data out to a file, which the visualizer would then read in and deserialize, but for some reason the worker thread never started executing. I have no idea why.

So, I’m raising my arms with complete humility and humbly asking the world at large to help me figure this out. If you know of a way to do this, please let me know. I’m thinking that there must be a way to use a named pipe with WCF here, but I could be way off. If I am, what’s the problem?

Any useful advice will be most appreciated.

Woodstock is now more user-friendly

Last night Karl Shifflett gave me an excellent suggestion to improve the usability of Woodstock.  He pointed out that the UI can take a while to open up, which can make some people less inclined to use the tool.  I completely agree, so I took his advice and changed the order of things when the Woodstock window opens.  Now the Window immediately pops open and displays a fun little splash screen, while loading the visual tree data on a worker thread.  It makes the whole experience much more responsive.

I cleaned up the code a bit and added comments.   Also, I realized that the DataGridView’s row headers are not necessary for Woodstock, so I got rid of them.  Now the display area for data in the grid is a little better.

I can’t believe how much positive feedback, constructive criticism, and kudos I’ve received over the past few days.  It’s really amazing to see this kind of excitement in the WPF community!