VS2010 IDE vs Stand Alone Execution Weirdness (Mouse Wheel)

So I’m doing some ActiveX Interop with my WPF application.  As most people know, it’s more of a two step process with WPF since you have to host the ActiveX control inside of a WindowsFormsHost object before you can introduce it into a WPF Control or Window.

Anyway, I was testing my component in the IDE and it seemed to be working fine.  Next, I ran the application by itself because it’s faster than through the IDE and I found that my mouse wheel was not working.  What gives? Why would it work properly in the IDE, but not by itself?

I got frustrated and posted a question on the MSDN forums about it.  Since my ActiveX component has license restrictions, I couldn’t provide a proper sample application.  I then got the suggestion to host the Interop component in a Winforms application as a test.  My Winforms sample project works as it should inside and outside of the IDE.

I then tried to just start a simple WPF application with the Interop control and the same behavior occurs as in my main project: Mouse Wheel works in the IDE, but not stand alone.  At this point it seems like it’s a WPF/ActiveX Interop issue.

Another suggestion I got was to use Spy++ to see my component was responding to the Mouse Wheel messages.  I opened up Spy++, but before I did anything I noticed that my application was now handling the Mouse Wheel messages.  Now here’s what’s confusing me, as soon as I closed Spy++, my application stopped handling Mouse Wheel messages again.  Why does the simple fact of having Spy++ open make my ActiveX component work correctly???  I didn’t event start logging the component!

According to Spy++, my component was indeed handling Mouse Wheel messages as indicated by the log and also because the component was scrolling as it should… I’m waiting for a response to my forum post, hopefully someone can tell me what’s going on.

Visual Studio 2010, When “Save All” Doesn’t Mean “Save All”

I found a minor bug related to the Save All functionality while updating our build definitions.  A new project was added to our TFS and this needed to be cloaked for all of our existing build definitions.  No problem, just add the path, set it to cloaked, and copy the line so you can easily paste it in your next build definition without having to pick the path. 

I did this for five of our definitions and I decided to go back to the first one for some reason to double check.  Why didn’t the path get saved?  I hit Save All and didn’t get a prompt when I closed the build definitions, so what gives?  Okay, maybe it was a glitch or something so I did it again, this time I tried using the regular Save instead of Save All.  This time my build definitions were updated. 

It seems like there’s a bug with Save All and updating build definitions.  I submitted the issue to Microsoft, but they want a video… I’m always wary about submitting anything work related to the public domain so I had to decline.  Hopefully the issue gets resolved, but in the meantime if anybody else is having the same issue, just hit Save instead.