A Time Of Transition...

My time at KPMG has come to an end... As I reflect back on these past 3+ years, I've certainly learned more here than I ever have in my career. I attribute a lot of my success to one person.

I certainly owe a huge debt of gratitude to Greg. Through him, I was allowed to use the latest technologies, think outside of the box, and work on highly critical projects with a huge sense of responsibility.

Thanks, Greg. You've certainly been the best manager I've ever had (pretty sad huh :P), but not only that, you've also been a great mentor and friend. I really could not have gotten luckier when I landed the job at KPMG and became a part of your team. Thanks again.

VB + C# Adventures (Final Part)

Now that I’ve been using C# continuously for my current project, I can honestly say that I can switch between VB.NET and C# easily.  As I’ve said before, I learned .NET in C# a long time ago and personal projects are done in C#, but most of my production experience has been using VB.NET. 

Do I regret having to use VB.NET?  Not at all, because it’s all about the framework, not the syntax.  I like being able to use both languages and achieve the same outcome.  Of course I can’t say that I know C# inside and out, but I can’t say the same about VB.NET either.  I also feel a sense of pride being able to do more than one language and not complain about it.  I still find it funny when my developer friends say something like “Oh I hate VB.NET.” or “I can program in C# about 3x faster than VB.NET.”

So which language do I prefer?  I have always preferred C# over VB.NET, but I’ve never complained and never will, if I have to use VB.NET for a project.  Sometimes there’s no choice in what language you have to use and knowing both is a useful skill to have.  Maybe one day if we need to develop some kind of math intensive library, F# will be thrown my way :)

Closing a WPF Window Through Your ViewModel

I ran into the issue of properly closing a Window (View) from my ViewModel a while ago.  How does one do this without breaking MVVM or adding too much complexity?  Since I’m developing my current project using Prism and my IUnityContainers are injected into my ViewModels, why not just inject this.Close() also?

/**** Window (View) ****/

...

public Window(IUnityContainer unityContainer)

{    

   InitializeComponent();    

   this.DataContext = new ViewModel(unityContainer, this.Close);

}

/**** End Window (View) ****/

/**** ViewModel ****/

public class ViewModel

{    

   public ViewModel(IUnityContainer unityContainwer, Action closeAction)    

   {        

      ...        

      CloseCommand = new DelegateCommand(closeAction);    

   }    

   public DelegateCommand CloseCommand    

   {        

      get;        

      private set;    

   }

}

/**** End ViewModel ****/

Does this break MVVM at all?  Is testability decreased because I injected the this.Close() method into my ViewModel?  I would argue not since I’ve used the Action delegate.  This seems to be the easiest/simplest way to do what I (and many others) want.  Now there may be some purists out there that don’t want any user entered code in the code-behind, but as you might have guessed, I’m no purist.

WPF, MVVM and TextBoxes

Overall, I like WPF and MVVM.  That’s not to say that I think MVVM is a perfect design pattern.  I find myself breaking the purity of MVVM sometimes because I think there’s a lot of compromise needed to do what I want to without adding complexity.

Anyway, one of the biggest gripes about MVVM and TextBoxes is that the data for bound TextBoxes is updated when the TextBox control loses focus.  But that makes sense, right?  Well, what if you’ve updated a TextBox and hit a MenuItem to save your data.  Guess what?  The TextBox doesn’t lose focus and your save takes the stale TextBox data.  Needless to say this is VERY frustrating…

One solution would be to move the focus off of the TextBox like so:

((System.Windows.UIElement)System.Windows.Input.Keyboard.FocusedElement).MoveFocus(new System.Windows.Input.TraversalRequest(System.Windows.Input.FocusNavigationDirection.Next));

You can call that before you actually execute your save command, but even that seems like a bit too much effort to do what should logically be done anyway… I’ve done the above in some of my projects, but there has to be some other way to do what I want…

Instead of using the vanilla Menu control, I turned to Infragistics’ xamMenu.  I was hoping that their menu would take into account something like the issue I was having with my TextBox data.  I was right… sort of.  It turns out that if I use their xamMenu like so:

<ig:xamMenu>
    <ig:xamMenuItem Header="Save">
          <ig:XamMenuItem.InputBindings>
              <MouseBinding MouseAction="LeftClick" Command="{Binding SaveCommand}"/>
          </ig:XamMenuItem.InputBindings>
    </ig:xamMenuItem>
</ig:xamMenu>

The above doesn’t do what I want either… After some experimenting, I found that if I use the vanilla MenuItem elements instead of Infragistics’ XamMenuItem elements, my TextBox data updates and saves.  It seems weird to me that using a combination of the Infragistics xamMenu and the vanilla MenuItem causes the data to update correctly, yet using all Infragistics’ elements doesn’t.

<shrug> In the end I ended up using vanilla Button elements in the xamMenu because using the vanilla MenuItem elements caused spacing issues:

<ig:xamMenu>    
    <Button Command="{Binding SaveCommand}" Background="Transparent" BorderBrush="Transparent">
        <StackPanel Orientation="Horizontal">
            <Image Stretch="None" Source="{StaticResource Image}"/>
            <TextBlock Background="Transparent" Margin="4,0,0,0" Text="Save"/>
        </StackPanel>
    </Button>
</ig:xamMenu>

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.

My Prism Journey (Part 3)

It’s Me, Not You

WPF’s bare controls are decent, but not always as robust as people need or want.  I initially setup my Shell using the basic Grid component on a Window.  Of course I was and still am in the learning phase, but as my project becomes more “real”, I realize that I should probably start using the components that’ll actually be needed once my project hits our production environment.

Since I’ll be using floating panes, I turned to Infragistics.  We use their controls in many of our WinForms applications so it seemed logical to use them for my Prism project.  I figured this would be easy since Prism can inject views into any control that hosts an ItemControl or ContentControl. 

There was a bit of a learning curve to get Infragistics’ Dock Manager to work the way I wanted.  Although I was easily able to place ConentControls in the various dock regions, for some reason I couldn’t get the Dock Manager to fill its parent container.  This behavior wasn’t expected because the WinForms equivalent did fill in the area as expected.  I also followed the Getting Started sample from scratch in a new project and the control didn’t fill…

I did some searching and it looked like others were having the same issue.  The post I found was dated 2009 with no answer so I figured that this issue wasn’t resolved.  I was pretty irate that the expected behavior wasn’t implemented over a year later.  I even went so far as to gripe to the boss about it and asked if I could look at other companies’ components.

After my grumbling session, I took a step back.  Infragistics has been in the controls game a long time (remember Sheridan and VB pre .NET?), they couldn’t have let something like this slip.  I did some more searching and I found that all I needed was a single property: LayoutMode=”FillContainer”

Open hand facing upwards and forcefully place forehead into hand…

 

Views, ViewModels, And Events

Not all applications have simple UIs.  I have a registered library that handles some of my Region management based on certain requirements.  This manager will inject a View+ViewModel into a Region, nothing complicated here.  In my ViewModel I subscribe to certain events, which again is nothing complicated. 

I noticed something odd when I retrieved data through my application.  Every time I retrieved data, the time it took to display multiplied.  At first, I thought it was because my View wasn’t being properly removed from my Region. Nope, the ActiveView count is 0 as it should be.  I then placed break points in my data layer and found the culprit. 

The expected behavior is that if I request data, a new data layer is instantiated, and my data is returned.  However, every time I requested data, a data layer was instantiated, and the data was returned, but the previously instantiated data layer never got destroyed and was also retrieving data! 

This immediately made me look at the fact that I subscribed to a retrieval event, but never unsubscribed from it.  Prism’s event system must have still had a reference to the CallBack and was still calling it.  This explained the multiplicative time increase.  I ended up having to make sure that my Region manager library unsubscribes from any events when removing Views from my Regions.