SNOOP with Integration.ElementHost control

Jun 3, 2010 at 7:28 PM

I am not all that surprised, but SNOOP does not work on a WPF control that is hosted in a System.Windows.Forms.Integration.ElementHost.  It would be a very nice feature to add at some point in time.

Sam

Coordinator
Jun 3, 2010 at 7:32 PM

Actually, it should work. This is exactly the scenario that motivated me to work on Snoop in the first place.

Maybe I missing something though. Do you have a simple test harness that illustrates how Snoop is not working for you? If so, email it to me at my first name followed by my last name at gmail.com.

Jun 3, 2010 at 8:15 PM

Sort of funny, what I am trying to test is my test harness. The test harness is anything but trivial, though.  I can think of two things that might be an issue:

I am implemented my own System.Windows.Forms.ApplicationContext: To get to the WinForms dialog that contains the WPF, one must go through three other WinForm dialogs.  Rather than simply stacking dialogs on top of each other, which I simply HATE, the custom implementation of ApplicationContext creates a dialog, hooks the FormClosed of the form.  When the event fires, then it determines if it should be exiting or opening the next form.

I am using a 3rd party set of WPF Controls.

I would not imagine either of these being an issue.  Since this is open source, any suggestions on how I can debug this?

Sam

Coordinator
Jun 3, 2010 at 8:28 PM
Edited Jun 3, 2010 at 8:37 PM

Hmmm. I wonder if you have a situation where Application.MainWindow is no longer valid ... since it was one of the first forms in a sequence ... before you actually got to the WPF part. The only thing you need to keep in mind if you are debugging this yourself ... is that Snoop injects its main Snoop UI (the window with the property grid) into the Snoop(ed) or spied upon process.

Thus, you need to do the following:

  1. Launch the application that you want to Snoop.
  2. Launch Snoop (only the application chooser ... don't try to Snoop anything just yet).
  3. Bring up the Snoop project inside of Visual Studio and Debug/Attach to Process on the application you want to Snoop (the thing you launched in #1).
  4. Set a breakpoint somewhere in the Snoop code. I would suggest SnoopUI.GoBabyGo.
  5. Finally, use Snoop's application chooser to select and Snoop the application you've been trying to Snoop (again, the thing you launched in #1).
  6. Your breakpoint should get hit.

Good luck, I hope you figure it out.

If you do, I will still be wanting a test harness so that I can verify any bug fixes that I end up integrating. The hope, of course, is that once you figure it out, it might be very easy to create a simple test harness ... and one that doesn't have any dependency on a 3rd party set of WPF Controls (so that I can check it in to the source code here too).

Jun 3, 2010 at 9:09 PM

Actually, it wasn't that Application.MainWindow was no longer valid, it was that Application.MainWindow was never set!  Thank you!

Coordinator
Jun 3, 2010 at 9:34 PM
So are you good then? Are you changing your application? If so, how? I don't think we had to worry about manually setting the Application.MainWindow manually in our scenario (but I could be wrong on that).
Jun 3, 2010 at 10:16 PM

Sorry, you are correct, I am good now.  In the Application class there was one function which wired up all the events on the form and showed the form, I simply set the Application.MainWindow there, too.  All is golden now!

As far as the rules around Application.MainWindow, I am not sure.  In the constructor of my derived Application class is where I first called the function I modified, then as the form closes, I determine what form comes next, if none, I called Application.ExitThread().  Oh, and when I called Run from the static main, I ran my Application class, not a form, which is why I don't think Application.MainWindow ever got set.  When you call Run on a actual form, I think the default Application class sets the MainWindow for you.

Sam