Well, here is another piece of evidence!

The other day, a developer, Bruno Martinez, from Uruguay contacted me and wanted to contribute to Snoop by making it so that there was only 1 version, instead of the 4 currently required at that point.

If you recall …

1. You needed a version for WPF 3.5 and 32-bit.
2. You needed a version for WPF 3.5 and 64-bit.
3. You needed a version for WPF 4.0 and 32-bit.
4. You needed a version for WPF 4.0 and 64-bit.

Yuck! Of course, it was better than not being able to Snoop in those situations.

Well, after integrating Bruno’s changes … you just need:

1. Snoop

Yeah, that’s right. There are no labels! Thank you, Bruno!

I’m obviously tickled by this … since it was a usability nightmare trying to figure out what version you needed to run … but there are host of other fixes/improvements as well. In particular, the Snoop start-up process is much more robust than it used to be and it can handle some fringe cases that it wasn’t able to before.

Please go to http://snoopwpf.codeplex.com for more info, and of course, the download/release area for version 2.6.0.

Happy Snooping!

Share/Save

If you try to Snoop a WPF 4.0 application with the WPF 3.5 version, you will get the following error message:

I speculate that this is because there is a brand new CLR with .NET 4.0 (WPF 4.0) applications. Yes, that’s right, a brand new CLR. We haven’t had one of those for a while.

If someone can confirm this or provide a better understanding of why I can’t Snoop WPF 4.0 applications without retargeting Snoop to .NET 4.0 … please shed some light for me.

So, there are now 4, count them, 4 versions of Snoop:

1. Snoop 32-bit for WPF 3.5
2. Snoop 64-bit for WPF 3.5
3. Snoop 32-bit for WPF 4.0
4. Snoop 64-bit for WPF 4.0

You need to use the right version of Snoop in each particular situation … otherwise … thar will be problems, matey!

I have also added another label to the app chooser so that you know which version you currently have up. Take a look … this is what it looks like for the 64-bit/WPF 4.0 version:

Let me know if you have any problems by creating a discussion (or participating in a current one) on the http://snoopwpf.codeplex.com site.

Enjoy and happy Snooping!

Share/Save

Snoop is now on CodePlex at snoopwpf.codeplex.com

The community reception to my efforts (blog posts: 1, 2, 3) on Snoop have been wonderful. Some like Anvaka have offered additional feature suggestions; others have just encouraged me.

In my last post, a fellow commented asking why it wasn’t up on CodePlex. Well, this was a great suggestion and one that I had actually already considered. That prompted me to email Pete Blois (the original author) for his permission. He graciously gave it and so I then proceeded to put it up there.

It took me a little while, but I now have the initial bits uploaded … that is, the same stuff that is available here at my blog.

Now, there are a bunch of things on the todo list. Most notably, I’ve already modified Snoop so that it works for WPF 4.0 … and definitely want to share that with the world.

So, please be patient, I’ll get to it. Those silly day jobs!

Some Info

If you are going to download the source code and build it, some comments are in order (I’ll put this out at the CodePlex site too).

There are (go to Build->Configuration Manager) 3 solution platforms (x86, x64, Any CPU) and 2 solution configurations (Debug, Release). The x86 platform is for 32-bit, the x64 platform is obviously for 64-bit, but … what is Any CPU?

Well, Any CPU is only around for Blendability. That is, for some odd reason, I couldn’t bring up the Blend designer Snoop’s window unless it was in this configuration. I have intentionally marked the ManagedInjector project to not be built under the Any CPU configuration. Since Any CPU will run as 32-bit on 32-bit operating systems and as 64-bit on 64-bit operating systems, using Any CPU will likely cause a mismatch (and a headache ) with the ManagedInjector dll.  The project which builds the ManagedInjector.dll is a C++ project and there isn’t an Any CPU setting for those (they can only be specifically built to Win32 or x64).

Or, in other words, make sure you switch into another platform, before you build or the build will fail.

Here’s a chart for quick reference:

Call to Action

If you have a feature request or want to be involved somehow (maybe as a contributor), please don’t hesitate to contact me.

For near future though, I’m going to keep the project closed until I can change the copyright info to Ms-PL and clean up the code a bit.

Thanks

Finally, I want to publicly thank Pete Blois for first creating this awesome tool and for giving us the permission to get it going on CodePlex. A big thanks Pete!

Share/Save

I’ve done this many, many times because it is the only way I’ve been able to Snoop applications on my Windows 7 64-bit operating system. And, I thought, “Boy, this is stupid. I should be able to build a 64-bit version of Snoop such that I don’t have to do this anymore.”

And that is exactly what I did.

Now … presenting Snoop 32-bit!

And Snoop 64-bit!

Here are the binaries for the 32-bit version and here are the binaries for the 64-bit version.

(The binaries are now (see posts: 1, 2) up on CodePlex. Please go download it from there as those binaries will contain the latest and greatest bits.)

It was rather a simple matter really. I just needed to change all the project configurations so that they targeted the x64 platform … for the x64 version of Snoop … and all the project configurations so that they targeted the x86 platform … for the x86 version of Snoop.

This was so easy and worked so nicely … that I searched the internet to see if anyone had done this already … and I found Dan Hanan’s nice post on the matter.

The problem, though, was that he did it for original version of Snoop … and not the nicely styled and improved version that Pete Blois currently is making available since property editing was originally (still?) broken in that version. However, he also had several nice usability features that I was drooling over and wanted for my very own. And I, of course, have already fixed the property editing issue in my version (see previous posts: 1, 2) with a little help from Mark Kharitonov (see this forum post for more info on that).

So, I emailed him, got his permission to integrate those changes, and promptly did so. I also added a few improvements myself.

The Improvements

Here is what has been improved (over and above Pete Blois’ current version):

Improvement	Originator
Handles WPF interop scenarios (both Windows Forms hosting WPF and WPF hosting Windows Forms).	Cory Plotts
Fixed the ability to edit properties.	Mark Kharitonov
Modified Snoop so that it can handle visual trees that have nesting greater than 255 levels deep.	Mark Kharitonov
Modified the project configurations so that you can build a 32-bit version and a 64-bit version. This is what the blog post is all about! Ha!	Cory Plotts Dan Hanan
Turned off the showing of properties at their default value (by untoggling the Show Defaults toggle button).	Dan Hanan
Turned auto refresh off in the AppChooser. Snoop was previously polling every 20 seconds for new applications.	Dan Hanan
Added a checkbox to turn auto refresh back on (if you so desire).	Dan Hanan
Added a label to the AppChooser to indicate 32-bit versus 64-bit.	Dan Hanan
Added a wait cursor when the AppChooser is busy iterating over the applications to possibly Snoop.	Dan Hanan
Added the capability to bring the selected tree view item into view.	Dan Hanan
Added the capability to filter properties based on predefined sets of properties.	Dan Hanan
Added the ability to pop the target (after a delve) with the back button on the mouse.	Dan Hanan
Modified the selected item in the tree view to be a light blue even when it doesn’t have focus.	Dan Hanan
Added the ability to pop the target (after a delve) with the alt-left arrow keyboard sequence.	Cory Plotts
Added the ability to remember window position, size, and the maximized/minimized/normal state for all three Snoop windows.	Cory Plotts
Removed the filtering of ‘devenv’ out from the list of applications that you can Snoop.	Cory Plotts
Modified the project configurations so that it never builds the installer. I just copy the Snoop executable and the ManagedInjector dll from place to place. Don’t know if this an improvement.	Cory Plotts
Fixed the x86 installer and created an installer for x64. Snoop is no longer being added to the GAC and the assemblies are thus no longer strong named. The installers for both platforms should now work.	Cory Plotts
Integrated Anvaka’s great suggestion below (see the comments). That is, I moved the long label that tells a user how to ctrl-shift click on the application being Snoop(ed) (to a tool tip on the tree view) … and replaced it with a label that tells the user what the immediate following hyperlink is … that is, the Keyboard.FocusedElement. Also added another label and hyperlink for the current selection’s focus scope.	Andrei Kashcha (Anvaka)

I chose not to integrate a couple of Dan Hanan’s changes. First, I did not integrate the ‘indexer delve’. Well, actually I did, but then noticed that Pete Blois’ new version already allowed you to delve into items in a collection … and so I backed it out.

Second, I did not integrate the ‘use 2nd monitor if present’ feature. I liked that feature but thought that I would try to improve upon it by remembering the position and size of all the windows … regardless of the number of monitors. So, with a little help from this StackOverflow question and this MSDN sample … that is what I did. It seems to work nicely. Let me know if you have any problems with it.

Snoop(ing) Visual Studio 2010

Finally, ever since I’ve installed Visual Studio 2010, I’ve wanted to take a peek under the covers with Snoop (remember … Microsoft used WPF in this latest version of Visual Studio). I originally thought I couldn’t Snoop it … because it was running as a 64-bit application and I only had a 32-bit version of Snoop.

So, when I got the 64-bit version of Snoop going, I quickly tried Snooping Visual Studio 2010. No luck! Bringing up task manager, I quickly remembered that Visual Studio runs as a 32-bit application on 64-bit operating systems. See this post by Rico Mariani for more info.

As I have recently been invited into the WPF Disciples group, I posed the question there. Imagine my surprise to find out that devenv.exe was manually being filtered out (since Visual Studio 2008 would load WPF assemblies … but Snoop would fail since Visual Studio 2008 wasn’t built with WPF).

That gave me quite the chuckle. Or, more like, duh! So, promptly removed that and Snoop(ed) Visual Studio 2010 to my delight (check out the red Snoop adorner):

And, of course, the Snoop AppChooser:

And, finally, the main Snoop user interface:

I think that is so cool. Ok, I know … I need mental help.

The Source Code

In the past, I have not released the source code since I have wanted to get Pete’s permission before I do so. I actually met him at PDC 2009 this year. I brought up the fact that I had modified Snoop to handle interop scenarios … but I forgot to ask him about the source code!

There are so many changes now … that I think it would be counter-productive to not release it … in case someone else wants to take Snoop even further than I (and Dan and Mark) have. If you do modify it … and take it further … please let me know! I would love the chance to determine whether to integrate the changes into this version.

So, here it is: the source code.

(The source code is now (see posts: 1, 2) up on CodePlex. Please go download it from there as that code will contain the latest and greatest bits.)

Enjoy!

p.s. If you were one of the few who pulled down the binaries immediately after I posted it, then you may not have gotten the Snoop.exe.config file. Unfortunately, in this case, Snoop does not seem to close down all the way (i.e. I had to manually kill it through task manager). You’ll want to get the latest binaries that do include the Snoop.exe.config file … or manually rebuild them yourself with the source code.

An Update

See above (in the table of improvements), but I fixed the installers and integrated a nice idea by Anvaka. All the attached binaries (which should be installers now) and source code have been updated.

Share/Save

Now, onto the meat of post: I have found a couple more places where you need to insulate yourself from not having a current Application … and I was able to fix the keyboard issue!

Let’s tackle the keyboard issue first as that is the big one. In the Inspect method of the SnoopUI class, you need to call the static method ElementHost.EnableModelessKeyboardInterop and you need to do that when in an interop scenario, that is, when the current Application is null.

The MSDN documentation for this method states that this method allows a System.Windows.Window to receive keyboard messages correctly when opened modelessly from Windows Forms (our interop scenario). Hmm. Sounds exactly like what I was looking for!

public void Inspect(object target)
{
    this.rootObject = target;
    this.Load(target);
    this.CurrentSelection = this.root;

    this.OnPropertyChanged("Root");

    if (Application.Current != null)
    {
        this.Owner = Application.Current.MainWindow;
    }
    else
    {
        ElementHost.EnableModelessKeyboardInterop(this);
    }
    this.Show();
}

This also requires you to add a reference to WindowsFormsIntegration.dll and to add a using statement:

using System.Windows.Forms.Integration;

With the above changes, you should be able to use the keyboard once again to change property values in the property grid that comes up when you Snoop something. Whew! That copy/paste trick was getting old, really fast.

Now, onto the additional places where you need to protect yourself from not having an Application instance. First, the Previewer was broken … and you need to modify the HandleMagnify method of the Previewer class:

private void HandleMagnify(object sender, ExecutedRoutedEventArgs e)
{
    Zoomer zoomer = new Zoomer();
    zoomer.Target = this.Target;
    if (Application.Current != null)
        zoomer.Owner = Application.Current.MainWindow;
    zoomer.Show();
    e.Handled = true;
}

Second, you need to modify the ProcessFilter method of the SnoopUI class so that it uses the Dispatcher for the current thread versus grabbing it off the non-existent Application instance:

private void ProcessFilter()
{
    this.filtered.Clear();

    // Blech.
    if (this.filter == "Clear Filter")
    {
        Dispatcher dispatcher = null;
        if (Application.Current == null)
            dispatcher = Dispatcher.CurrentDispatcher;
        else
            dispatcher = Application.Current.Dispatcher;

        dispatcher.BeginInvoke
        (
            DispatcherPriority.Loaded,
            new DispatcherOperationCallback
            (
                delegate(object arg)
                {
                    this.Filter = string.Empty;
                    return null;
                }
            ),
            null
        );
        return;
    }
    if (this.filter == "Visuals with binding errors")
        this.FilterBindings(this.root);
    else if (this.filter.Length == 0)
        this.filtered.Add(this.root);
    else
        this.FilterTree(this.root, this.filter.ToLower());
}

By the way, I would love to hear (by leaving a comment on the blog here), if this helps you at all. I was truly missing the ability to Snoop our WPF interop application myself.

Enjoy!

p.s.

I would love to make my source code modifications to Snoop readily available to the general public, but I have been unable to contact Pete Blois and obtain his permission to do so. Sorry!

(The source code and binaries for Snoop are now (see posts: 1, 2) up on CodePlex. Please go download it from there as that code will contain the latest and greatest bits.)

Share/Save

Coming from the land of Windows Forms, I have grown addicted to having tools like wfSpy and Hawkeye. A software engineer at the presentation layer needs to have tools like these in order to inspect the objects in a running application and change properties on the fly.

Very soon after jumping in head first into WPF, I discovered Pete Blois’ utility: Snoop. It was definitely what I was looking for. Unfortunately, after playing with it for a while, I learned that it didn’t support our WPF interop scenario. In particular, our application is a Windows Forms application that is hosting WPF content through ElementHost. When you use ElementHost, you don’t have an Application object and Snoop coughs up a hairball because of that.

After that, Josh Smith created Woodstock and Mole soon followed. These are both debugger visualizers, and in particular, Mole is extremely nice and powerful. The Achilles tendon of debugger visualizers, however, is that you have to be running in the Visual Studio debugger. There are many cases where you can’t or don’t want to do this.

Josh Smith realized this and has created Crack.NET. This is a heap walker in the vein of Snoop and Mole … but it can be run outside of the debugger. It is a useful tool in its own right, and of particular note, you can modify the object you’ve ‘cracked’ using IronPython in the tool’s Scriptorium area.

However, even given the above, I was still missing the functionality of good, old wfSpy. Snoop was very close to what I wanted, it just didn’t handle the WPF interop story.

So, after reading this post in the WPF forums, I finally broke down, dove into the source code and figured out why. It was rather easy to fix, actually, and here is what I had to do.

The Fix:

In the Enqueue method of the DelayedCall class, you need to get hold of the Dispatcher from something other than the Application.Current object. Here is the whole Enqueue method:

public void Enqueue()
{
    if (!this.queued)
    {
        this.queued = true;

        Dispatcher dispatcher = null;
        if (Application.Current == null)
            dispatcher = Dispatcher.CurrentDispatcher;
        else
            dispatcher = Application.Current.Dispatcher;

        dispatcher.BeginInvoke
        (
            this.priority,
            new DispatcherOperationCallback(this.Process),
            null
        );
    }
}

In the Inspect method of the SnoopUI class, you once again need to protect yourself from not having an Application object:

public void Inspect(object target)
{
    this.rootObject = target;
    this.Load(target);
    this.CurrentSelection = this.root;

    this.OnPropertyChanged("Root");

    if (Application.Current != null)
        this.Owner = Application.Current.MainWindow;
    this.Show();
}

After those two changes, you can Snoop WPF content hosted in a Windows Forms application through ElementHost. Do I hear a ‘hallelujah’?

On a related note:

One thing I should mention is that property editing is broken in Snoop 2.0. In the WPF forum post mentioned above, Mark points out how to fix this. You just need to add the following line in the correct place in the PropertyInformation constructor:

binding.Mode =
	property.IsReadOnly ?
	BindingMode.OneWay :
	BindingMode.TwoWay;

However, this doesn’t seem to fix it completely when you are running in a WPF interop scenario … because there is still an issue to find and fix. Namely, you can’t use the keyboard to modify the property values. However, I have discovered that you can paste a value in using the clipboard. If you find out how to fix this, please let me know.

Finally:

Mark also has fixes for a couple other items. One takes care of an issue when the nesting gets too deep and another is a fix for popping the context after you ‘delve’ in on something.

I hope this helps someone. I personally am happy to the point of tears that I will now be able to Snoop our application!

Update:

I have found the keyboard issue and have fixed it. I have also uncovered a couple other changes that you need to make. For example, the Previewer wasn’t working. See my next blog post for details.

Update:

(The source code and binaries for Snoop are now (see posts: 1, 2) up on CodePlex. Please go download it from there as that code will contain the latest and greatest bits.)

Share/Save