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:


8 Responses to Woodstock snapshot image bug fix

  1. M says:

    Hi, I haven’t read all the comments to all of your posts about Woodstock, so I don’t know if this has been mentioned yet. I’m new to WPF so excuse any ignorance on my part!
    What is the feasibility of being able to change property values in the Woodstock visualizer, passing it to the debugger process, re rendering the visual and the updating the snapshot in Woodstock, whilst debugging? The idea is kind of like re-evaluating a variable in the watch window.

  2. Josh Smith says:


    That’s a really hard feature to implement. The main problem is the fact that I’d have to somehow create editors for every type of object that you might want to modify. Since a property can be of any type, I’d practically need an endless number of editors. For example, I would need to provide a way for you to edit Style, IList, IEnumerable, DataTemplate, bool, Brush, IDictionary, etc., etc. etc.

    The actual transfer of data back to the debuggee process is not that hard, there are such visualizers out there. But they only work with a very limited set of types which you can edit.


  3. Ben Vanik says:

    It’d be possible to use the WPF built-in converters for most things, like Margin, Thickness, Brush, etc. They exist to convert the XAML string values in to actual instances. I’m pretty sure that’s how Snoop does it. If no one has plans to add this, I may look in to it, as my #1 use of Snoop is to tweak margins/positions/etc.

  4. Josh Smith says:


    That’s true for the WPF types. But I’m still not sure how that would work for collections, such as the Triggers of a Style, etc. Granted, I haven’t really researched this problem space much, so I might be missing a simple solution at this point.


  5. Ben Vanik says:

    Snoop just doesn’t show those. For most simple cases, the built in ones work fine. More often than not it’s tweaking some sizes, colors, booleans, etc. I don’t think it’s expected to be able to rewrite the XAML on the fly – although that would be cool 😉

  6. Karl Shifflett says:


    I’ve been working with Josh on a new project that we have not relased yet. I like whtat you have said.

    Can you write up sort bulleted list of the desired user expierence.

    example :
    1. View Border properteis.
    2. Change Border Thickness.
    3. View Border in views and XAML viewer.

    Since I use Expression Blend, this would not be required, but without Blend, I can see where this would be a HUGE help.

    Thank you for your input.


  7. Karl Shifflett says:

    Josh & Ben,

    I was thinking about this a little more. Since our Visualizers all the user to basically naviage to any object in the tree, when we run the ReplaceObject to write it back to Visual Studio, I think we will only be able to EDIT the actualy object that was initially selected.



  8. Josh Smith says:


    I think you’re right about that. The replacement data can only affect the object being debugged, or sub-objects of it. I don’t see a way to replace/edit an arbitrary element element in the visual tree. But, we’ll have to look into that more closely to be sure that we’re not missing something.


%d bloggers like this: