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.

VB + C# Adventures (Part 5)

I Miss This

VB definitely makes certain things easier than C#.  This may go back to the whole VB making me lazy thing, but I miss being able to do this and not having to worry about a null reference exception:

...

Dim i As Integer = Len(Trim(SomeString))

...

Note that if the code above were to changed to SomeString.Trim.Length, a null reference exception could occur in either language.

Conversion methods are available in the System.Convert namespace, but in VB you can do the old CBool(SomeObject), CInt(SomeObject), etc.  I’m not saying that using the System.Convert methods are bad or anything, just that I need to get used to certain things. 

 

Style

I’ll be blunt, I hate sloppy code.  I try to be consistent in my style and cleanliness regardless of the language I’m programming in.  I think that C# definitely has more possibilities as far as clean styles go.  For example:

...
if (someCondition)
    DoThis();
...
if (someCondition){
    DoThis();
}
...
if (someCondition)
{
    DoThis();
}
...

I find all three of the above styles readable.  However, given the syntactic flexibility of C#, messiness is just as easy:

...
if (someCondition) DoThis(); if(someOtherCondition) {DoThis();AlsoDoThis();}
int i = 0;

I’ve always hated code that sat on one line, even way back in college when I was learning C/C++.  Sure it can be more succinct, but I find it harder to read.