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.

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. 

My Prism Journey (Part 1)

I’m not going to describe what Prism is because you can just do a search :)  I’m going to post my experiences in trying to leverage the Prism libraries to create a modular application.  The tutorials that come with the library are very helpful so people should definitely read the chm file for help.  I’m also trying to be as MVVM as possible so hopefully I don’t completely mangle my application.

One of the components that I’m adding to my application requires COM Interop… yay.  I did the obligatory aximp call on my ActiveX component, but for some reason I got a file not found exception whenever I tried to access the component at runtime.  Adding the references created by aximp didn’t seem to work.

I had to actually create a new WinForms control library, add the component to my toolbox, drag the component to the control, and then I was able to access the component at runtime.  No worries, I just copied the interop dlls and placed them in a folder so that those can be used instead of the aximp generated ones.

To include interop ActiveX components in your WPF application, you need to host the ActiveX component in a WinForms control.  No problem, add WindowsFormsIntegration so you can use the WindowsFormHost control in your WPF app/control.  You can then add the component to the WindowsFormHost.Child and it will display.  Pretty straight forward…

After getting the above sorted out, I got my interop control to display in the specified region in my shell.  However, it was displaying incorrectly… I set the ActiveX.Dock = Fill, but it wasn’t filling the region.  I sat there for a good hour or so trying to figure this one out… No matter what I did, it just wouldn’t fill the damn region. 

I then decided to create a little test program to see where the issue could possibly be.  I added a WindowsFormHost and a reference to the ActiveX component.  It filled fine!  Ok, maybe it’s because the region in my application is wrapped with a Tabcontrol.  I wrapped the WindowsFormHost with the TabControl and it still filled correctly.  Wait, to add a region to your shell, you need to specify what the region is hosted in, which is either an ItemsControl or ContentControl. 

It turns out that I used ItemsControls to host my regions (because the tutorial used those as well).  I then tried switching my region hosts to ContentControls and now my ActiveX component fills as it should… Sheesh.