Create a new project in Visual Studio 2008. Use the Visual C#->Micro Framework->Window Application project template, give the project a meaningful name and click OK.  One thing that I do not like about the template is that the Program.cs file contains the Main method and the window definition. I prefer to separate the functionality but if you want to leave it alone feel free. The only thing that you really need in your Main method is:

Program myApplication = new Program();// Start the application
myApplication.Run(new MainWindow());

I delete the rest of the stuff. Now to the MainWindow. I add a new class called MainWindow to the project. The MainWindow must inherit from Window. Add these using statements:

The first field sets up a PersistentStorage object for out SD card. The second line sets up a port to provide us an interrupt when the SD card is insert and removed. In this case we are going to use IO36, with a glitch filter, using a pull up resistor on the input and finally we want a notification for high and low transitions. If you look closely at the development board, there is a double row of headers down near the lower left side of the board with one side labeled JP1. The sixth pin down from the top is labeled SD Detect and that line is tied to the switch in the SD card connector. By itself it doesn’t do anything, you have to tie that line to an input for the processor. I chose IO36 which is conveniently located right next door to the SD Detect line.  You will need to run a jumper wire from SD Detect to whatever IO line you want to use.  Be very careful!

Width = SystemMetrics.ScreenWidth;
Height = SystemMetrics.ScreenHeight;
Background = new SolidColorBrush(0x000000);

_sdDetect.OnInterrupt += OnSdInterrupt;

private void OnSdInterrupt(uint data1, uint data2, DateTime time)
{
     if (data2 == 0)
     {
          _sdcard = new PersistentStorage("SD");
          _sdcard.MountFileSystem();
     }
     else
     {
          if (_sdcard != null)
          {
              _sdcard.UnmountFileSystem();
          }
     }
}


private void GetFiles()
{
     if (!VolumeInfo.GetVolumes()[0].IsFormatted)
     {
           return;
     }

     string[] files = Directory.GetFiles(VolumeInfo.GetVolumes()[0].RootDirectory);
     foreach (string s in files)
     {
            Debug.Print(s);
     }
}

When you install the Micro Framwork SDK it installs some new project templates into Visual Studio. We are going to use these templates to base our program on because creating a project from scratch in the Micro Framework is a bit of a pain. Fire up Visual Studio and create a new project using the Micro Framework Window Application template. In truth, it probably doesn’t matter if you choose the Console or Window template since we are going to delete everything and build it up step by step.

Click Ok and let the project get created.   You should wind up with something like this:

 The template files are all well and good but you should know exactly what the template contains and what it does. Select the Resources folder, GPIOButtonInputProvider.cs, Program,cs and Resources.resx file and delete them. That should pretty much wipe out everything, except for the references.  Right click the project in the solution explorer, select Add and then click Class.   Name the class Program and click Ok. This class is going to be the startup class. Add a public static Main method that returns void to the Program class and have Program derive from Application. Then add the following lines to the Main method:

     program.Run(win);

Nothing to it right? The first line instantiates the Program class. The second line instantiates the MainWindow. The third line tells the program to run using win as the main window. The entire program class looks like this :

Now we need to add another class that will be our main window. Add a new class to the solution and call it MainWindow. MainWindow needs to derive from the Window class. Window is contained within the Microsoft.SPOT.Presentation namespace so add that using statement to the top of the file. Add a constructor for MainWindow and add these lines to it:

The first two lines setup the window width and height. The third line sets the background color to blue. Note that the hex values for color are backwards from RGB. The hex values are BGR.

Lines 5 – 10 are an intializer for the Text class. Text is the equivalent of a Label in Winforms or TextBlock in WPF. I guess if they named it same as in WPF then there wouldn’t be anything new to learn….

The Font for Text is set by getting the font from the resources. TextContent is the Text property. Then the horizontal and vertical alignments are set. In this case we are setting the text to be centered in the screen.

The last line sets the Window child to the Text control. The entire MainWindow class look like this:

The last thing that we need to do is to add a Resource file to contain the font that we are going to be using. Right click the Project, select Add and then click New Item.  Then select the Resources File to add.  Once the file is created, click the Add Resource drop down and select Add Existing File.  Browse to the .NET Micro Framework installation directory, default location is C:\Program Files\Microsoft >NET Micro Framework\v4.0. Open up the Fonts folder and select the small.tinyfnt file and click Ok. The default installation of the Framework only comes with two fonts. You solution should now look like this: You should be able to build your solution now.

Almost done. Now you want to see the result of all that work right? Remember this is for embedded systems. So what if you don’t have an embedded system to run it on? Or you have your system on order but have not go it yet? The Micro Framework comes with an emulator that you can use to run your program in. Click the Project menu item and select Properties. Select the .NET Micro Framework tab. On that page you will see a combo box labeled “Transport”. This is where you would select where to run your program. If you have Emulator already selected then you are good to go. Press F5 to start your program. Visual Studio will build and “deploy” the program to the emulator. And the final outcome should look like this: 

Plug the EMX into an available USB port on your computer. The New Hardware Wizard should start if this is the first time that you have plugged the board in. When Windows finally figures out that it doesn’t know what the drivers would be, direct the wizard to the installation directory for the GHI Electronics SDK, by default C:\Program Files\GHI Electronics\GHI NETMF v4.0 SDK\USB Drivers\GHI_NETMF_Interface.

Once you have done that, you have to put the EMX into the correct mode to update the firmware. Hold down the Up and Select buttons on the development board and press the Reset button.

Run the MFDeploy too that was installed with the .NET Micro Framework, by default C:\Program Files\Microsoft .NET Micro Framework\v4.0\Tools.

Select USB from the Device combobox

Then click the Browse button and browse to the firmware directory for the development board, by default C:\Program Files\GHI Electronics\GHI NETMF v4.0 SDK\EMX\Firmware, and select all of the .HEX files.

Click the Deploy button and wait until it has finished doing its thing and you are done!

The first thing that you will probably want to do is to update the firmware on the development board. This is accomplished in two steps and involves placing the EMX board into two different operating modes.

Updating the bootloader

Plug the development board into an available USB port on your computer using the supplied USB cable. If the computer asks to install any device drivers, ignore that for now. To access the bootloader update mode, you would hold down the Up, Down and Select buttons on the development board as you power up the board or push the reset button. So patience is called for here. Unless you have teeny tiny fingers, it’s very difficult to hold all three buttons down at the same time. You know you have it when the screen does not display the boot up messages and is washed out with white.

If this is the first time that you have accessed this mode, the Hardware wizard should start up and want to install device drivers.  The drivers you want to install at this time are located at C:\Program Files\GHI Electronics\GHI NETMF v4.0 SDK\USB Drivers\GHI_Bootloader_Interface if you used the default location when you installed the GHI SDK. This driver allows you to connect to the board through the USB port using a terminal program. Once the driver is installed you are ready to go.

You need to use a terminal program to upload the new program to the processor. GHI reccommends Terra Term to use to upload the bootloader, you can download the program from their site. Personally, I have not had any success using Terra Term. I had heard that they have had problems with their 1K XModem protocol and I could never get it to work properly. I have used HyperTerminal that comes with Windows successfully. Start up your terminal program and connect to the EMX board. Hopefully you will be able to figure out which comport you need to use. Use 115200 8-N-1 and no flow control as your parameters.

Once you have connected, use the ‘E’ command to erase the memory. Note that you have to use upper case characters. Then press ‘Y’ to confirm the erase command. Wait until the board memory has been erased. While the erase is going on * characters are printed to the screen. They that stops you are ready to upload the new bootloader.

Press ‘X’ to begin the upload procedure. Again, remember upper case! The terminal program will start printing C characters to the screen indicating that the board is waiting for the upload. If you are using HyperTerminal, click the Transfer menu and Send File. Browse to the bootloader program to upload. In this case you want to go to C:\Program Files\GHI Electronics\GHI NETMF v4.0 SDK\EMX\Firmware\TinyBooter and select the TinyBooter.GHI file. Be sure to select XModem 1K to use for the transfer. The transfer only takes a few seconds. After the transfer is complete, the board will reboot itself in preparation for the next step.

I did find this blog entry here, http://blogs.msdn.com/jgoldb/archive/2008/02/04/finding-memory-leaks-in-wpf-based-applications.aspx, that disuss many memory leaks and fixes for them but nothing there exactly described my situation, or the meaning was not clear. The demostration application for the leaks has the leak in there but I am not doing what he did (that I know of) and he does not demonstrate how to work around the problem. Then I ran across this question on StackOverflow, http://stackoverflow.com/questions/801589/track-down-memory-leak-in-wpf, which described exactly what I was seeing. Which also pointed back to the first blog. So, after not thinking about it over the weekend and coming in fresh on Monday I looked again. I found this entry on StackOverflow, http://stackoverflow.com/questions/1705849/wpf-memory-leak-on-xp-cmilchannel-hwnd, which points out a very simple solution.

Apparently somewhere along the line, the application is getting confused as to who is doing the rendering. So messages are being allocated and sent, but no one is consuming them so they pile up until you run out of memory. The work around is to create a new HwndSource in the application constructor and that reregisters the window class with Windows and does not cause the confusion.

public partial class App : Application

{

public App() 
   { 
       new HwndSource(new HwndSourceParameters()); 
   } 

}

This appeared to work for me and hopefully will help someone else.

Coming from a C/C++ and diving into the .NET, I am constantly surrounded by strange phrases, three letter acronyms and concepts that take a long time to get used to. One of those concepts is the Model-View-Presenter (MVP).  There are plenty of articles about MVP around the Web. Most are pointers to Martin Fowler (http://www.martinfowler.com/eaaDev/uiArchs.html) or the MSDN (http://msdn.microsoft.com/en-us/library/cc304760.aspx). There are also many articles on Code Project (www.codeproject.com). The problem that I have had in the reading of these articles is that most use big $.25 words and unfamiliar phrases that mean nothing to the beginner, along with diagrams that are just plain confusing. Nothing I found that was in plain simple English. After a lot of trial and error and study I think I finally have something that I can understand. I do not pretend that this is the “right way” or the only way but it works for me.

This is the first part of five. Links to the other parts are:

     Part II

     Part III

       Part IV

       Part V

MVP

The goal of using the MVP design pattern is to separate the responsibilities of the application in such a manner as to make the application code:

·         Testable in an automated manner

·         Make the application more maintainable

·         Make the application more extensible. 

The first bullet means that there are many tools out there in the world that can be used to test code in an automated manner, called “unit testing”. These tools cannot test code that is in form code-behind modules. So the aim is to take that code out of the form code and place it in a DLL that can be tested.

I do not know about anyone else, but for me application code is way more maintainable when it is separated out into modules that have a specific purpose. If some unexpected feature does make it through the unit testing, then you will have a pretty good idea where to look just based on knowing what the various classes’ responsibilities are.

The extensibility part comes in when you have this separation of concerns, adding additional functionality is made easier because the code modules are not closely tied together also known as “loose coupling”.

What does it all mean?

The first thing is to understand the meaning of what the terms mean.

View: A view is any form or window that is shown to the user of the application.

Presenter: The presenter is an entity that presents the data to the view that is to be shown to the user.

Model: The model is the actual data that the Presenter will request and gets displayed in the View. The Model is responsible for obtaining the data. So the Model is the one that reads files, or connects to a database or if you are really ambitious, gets the data from a data service object.

The pattern is typically drawn like this.

Looks simple doesn’t it? Well what all those other articles, and examples, didn’t tell me was how to turn that simple diagram into a working application.

Get on with it already!

The first thing to do is to setup the solution. Open up Visual Studio and create a new Windows Forms Application.

Once Visual Studio is through creating your new project, add a class library to the solution to hold all of the various classes. Right click your solution object in the Solution Explorer, select Add then Add new project.

I named mine Common.Lib.dll you can name yours whatever you want to. I have seen some people that create a class library to contain the business logic and another one to contain the data layer. I think is overkill for this simple example. Go ahead and delete the Class1.cs file that Visual Studio created for you.

I like to compartmentalize things so I group like classes together. Right click on the class library project; select Add then Select New Folder. Name the new folder, Interfaces. Repeat twice more and name the other two new folders Models and Presenters. Your project should now look like this.

This is the end of Part 1. After starting the article it quickly grew to 14 pages and I was not done yet so I elected to post a series of pages.

This is the project skeleton so far. Change the extension from .doc to .zip before you open it. This is a workpress requirement. projectskeletonzip

 One of the most valuable skills a developer can develop is the ability to seperate UI modules, business rules and data access modules so that they are more maintainable. This separation means that the modules can be developed independently of each other without the changes having any impact on other modules. After several years in the business you get kind of tired of making a change and then having to chase down a bug that made its way in your application affecting modules that you never thought your change would touch you will come to appreciate separating out the code into different modules. Prism actually makes this pretty simple.

The first design pattern that will be demonstrated is the Supervising Presenter pattern that most closely resembles the Model-View-Presenter pattern so if you understand the MVP pattern then you should have no problem understanding this. For more information on the Supervising Presenter pattern see the Supervising Presenter topic in the Prism documentation.

A simple diagram for the MVP pattern looks like this:

MVP diagram

The second design pattern that will be demonstrated is the Presentation Model or Model-View-ViewModel pattern.  For more on the Presentation Model pattern see the Presentation Model topic in the Prism documentation.

A simple diagram of the Presentation Model pattern looks like this:

MVVM diagram

The foundation for this demonstration is the final project from the Getting Started article which you can get here.

First the MVP pattern

The first thing to do is to decide what kind of data that we are going to display in the view and how we are going to display it. For this simple example we are going to display some strings in a ListBox. So the final ChildOneView will look like this:

The second thing to do is to create some folders within the project to hold the various files that we are going to be creating. This helps to keep the clutter down.  Right click on the ChildOneModule project and add a NewFolder named “Interfaces”. Add two more folders and name them “Presenters” and “Services”. Now we are going to need to create three interfaces, one for the View, one for the Model and one for the Presenter.  After that your project will look something like this

The interfaces are very simple. The Model interface will expose a collection strings that the view will bind to.

    public interface IChildOneService

    {

        ObservableCollection<string> GetStrings();

    }

The Presenter interface will need to have a reference to the View:

    public interface IChildOnePresenter

    {

        IChildOneView View { get; set; }  

    }

And finally, the View will need to have a reference to the data that the Model is going to expose:

    public interface IChildOneView

    {

        ObservableCollection<string> Model { get; set; }

    }

That pretty much does it for the interfaces. The next thing to do is to create a class that will serve as the Model. Right click the Services folder and add a new class named “ChildOneService”. The service will need to implement the IChildOneService interface that we created earlier.

    public class ChildOneService : IChildOneService

    {

        public ObservableCollection<string> GetStrings()

        {

            ObservableCollection<string> strings = new ObservableCollection<string> { “one”, “two”, “three”};

            return strings;

        }

    }

The GetStrings method will return the string collection and that is what is going to be displayed in the View. It’s important to realize that the data that is displayed could come from anywhere, a file, a database, a web service, etc.

The Presenter class is also very simple. Create a ChildOnePresenter class in the “Presenters” folder and have it implement the presenter interface. The Presenter will need a reference to the view and the model passed to it in the class constructor.

    public class ChildOnePresenter : IChildOnePresenter

    {

        public IChildOneView View { get; set; }

        public ChildOnePresenter(IChildOneView view, IChildOneService model)

        {

            View = view;

            View.Model = model.GetStrings();

        }

    }

Open the view code-behind file. Modify the class definition to implement the IChildOneView interface. The view interface is implemented as a property that is used to data bind to. The data is transferred from the ChildOneService class to the View by the Presenter.

   public partial class ChildOneView : UserControl, IChildOneView

    {

        public ChildOneView()

        {

            InitializeComponent();

        }

        public ObservableCollection<string> Model

        {

            get

            {

                return DataContext as ObservableCollection<string>;

            }

            set

            {

                DataContext = value;

            }

        }

    }

Open the View XAML file and modify the view to include a listbox and bind the listbox item data source to the string collection.

    <StackPanel>

        <Label Content=”Child one” />

        <ListBox ItemsSource=”{Binding}” />

    </StackPanel>

The last step is to modify the module class. We need to include a reference to the container so that we can notify the container that we have additional classes for it to instantiate. Once that is done, then we register the Model, View and Presenter with the container

    public class ChildOne : IModule

    {

        private readonly IRegionManager _regionManager;

        private readonly IUnityContainer _container;

        public ChildOne(IUnityContainer container, IRegionManager regionManager)

        {

            _regionManager = regionManager;

            _container = container;

        }

        public void Initialize()

        {

            _container.RegisterType<IChildOneService, ChildOneService>();

            _container.RegisterType<IChildOnePresenter, ChildOnePresenter>();

            _container.RegisterType<IChildOneView, ChildOneView>();

            ChildOnePresenter presenter = _container.Resolve<ChildOnePresenter>();

            _regionManager.Regions["LeftChild"].Add(presenter.View);

        }

    }

If you compile and run the application at this point, you should see a window like the picture up top. That is how to implement the MVP pattern in Prism.

Model-View-ViewModel

The MVVM pattern is implemented in almost the same way. The only real difference is the way the View displays its data. MVVM relies heavily on data binding and Commands to get things done. This article is not going to cover Commands. That is something for another time.

To begin, create folders in the ChildTwoModule project named Interfaces, Services and ViewModels. You should turn out with something that looks like this:

For this example we will need three interfaces, IChildTwoModel, IChildTwoView and IChildTwoViewModel. As in the previous example, the Model will export a list of strings so our interface for the Model will look like this:

    using System.Collections.ObjectModel;

    public interface IChildTwoModel

    {

        ObservableCollection<string> GetStrings();

    }

The interface for the ViewModel will need to have a Property that exposes the list of strings to the View. The ViewModel will also need a reference to the View so our interface for the ViewModel will look like this:

    public interface IChildTwoViewModel

    {

        ObservableCollection<string> ModelStrings { get; }

        IChildTwoView View { get; }

    }

 The interface for the View will need a way to set the data to display. Since the ViewModel is exposing the data, the View needs a way to data bind the ViewModel to the View:

    public interface IChildTwoView

    {

        void SetModel(IChildTwoViewModel model);

    }

Now, on to the implementation. The Model class needs to implement the IChildTwoModel interface so create a new class in the Services folder named ChildTwoModel and then implement the interface. Remember that the interface is a method named GetStrings and returns a collection of string objects. So your Model class will look like this:

    using Interfaces;

    using System.Collections.ObjectModel;

    public class ChildTwoModel : IChildTwoModel

    {

        public ObservableCollection<string> GetStrings()

        {

            ObservableCollection<string> strings = new ObservableCollection<string> { “one”, “two”, “three” };

            return strings;

        }

    }

For the moment, I am going to skip over the ViewModel class as it is the most involved. Open up the View class and modify it to implement the IChildView interface. That brings in a method SetModel that will setup the data binding:

    public partial class ChildTwoView : UserControl, IChildTwoView

    {

        public ChildTwoView()

        {

            InitializeComponent();

        }

        public void SetModel(IChildTwoViewModel model)

        {

            DataContext = model;

        }

    }

Now open up the ChildTwoView.xaml file. Change the Grid layout panel to a StackPanel, and then add a ListBox to the StackPanel. Set the ItemsSource to the bind to the ModelStrings.

    <StackPanel>

        <Label Content=”Child two” />

        <ListBox ItemsSource=”{Binding ModelStrings}” />

    </StackPanel>

Now we come to the ViewModel class. The ViewModel class in the MVVM pattern takes on a lot of responsibility. The ViewModel not only provides data to the View but it also keeps track of the View state and acting as a go-between to the Model. One thing that is a really nifty feature is that the ViewModel can automatically update the Views data just by raising a property changed event. Okay so our ViewModel class needs to implement the IChildTwoViewModel interface and the INotifyPropertyChanged interface. The class constructor will need a reference to the View and the Model and set the ViewModel in the View:

        private readonly IChildTwoView _view;

        private readonly IChildTwoModel _model;

        private ObservableCollection<string> _modelStrings;

        public ChildTwoViewModel(IChildTwoView view, IChildTwoModel model)

        {

            _view = view;

            _model = model;

            _modelStrings = new ObservableCollection<string>();

            _modelStrings = _model.GetStrings();

            View.SetModel(this);

        }

 The SetModel method sets the data binding to the ViewModel. Now if you remember the View data binds the ListBox to something called ModelStrings so we need to implement a Property to expose the model strings:

        public ObservableCollection<string> ModelStrings

        {

            get

            {

                return _modelStrings;

            }

            set

            {

                _modelStrings = value;

                OnPropertyChanged(“ModelStrings”);

            }

        }

The OnPropertyChanged event notifies the View that the data has changed (if it does) and to update the data in the View.

        public event PropertyChangedEventHandler PropertyChanged;

        private void OnPropertyChanged(string propertyName)

        {

            PropertyChangedEventHandler handler = PropertyChanged;

            if (handler != null)

            {

                handler(this, new PropertyChangedEventArgs(propertyName));

            }

        }

The final thing is to modify the ChildTwoModule class to register the interfaces and the classes with the container just like we modified the ChildOneModule class.

        public void Initialize()

        {

            _container.RegisterType<IChildTwoModel, ChildTwoModel>();

            _container.RegisterType<IChildTwoViewModel, ChildTwoViewModel>();

            _container.RegisterType<IChildTwoView, ChildTwoView>();

            IChildTwoViewModel view = _container.Resolve<IChildTwoViewModel>();

            _regionManager.Regions["RightChild"].Add(view.View);

        }

Now you should be able to compile and run that application and get a window similar to this:

This concludes out whirlwind (and simplistic) tour of the Model-View-Presenter pattern and the Model-View-ViewModel in Prism. Hopefully you have a foundation from which to build and explore more in Prism. The final demonstration project (VS2008) can be found here. Rename the doc to zip before you open the archive. This is a wordpress.com requirment.

Prism is a set of libraries that allow developers to compose applications from separate components into a composite application. Composite meaning that the application functionality is split up into different modules that do not necessarily know about each other and then brought together to create an application.

 From the Prism documentation: “Composite applications provide many benefits, including the following:

·         They allow modules to be individually developed, tested, and deployed by different individuals or sub-teams; they also allow them to be modified or extended with new functionality more easily, thereby allowing the application to be more easily extended and maintained. Note that even single-person projects experience benefits in creating more testable and maintainable applications using the composite approach.

·         They provide a common shell composed of UI components contributed from various modules that interact in a loosely coupled way. This reduces the contention that arises from multiple developers adding new functionality to the UI, and it promotes a common appearance.

·         They promote re-use and a clean separation of concerns between the application’s horizontal capabilities, such as logging and authentication, and the vertical capabilities, such as business functionality that is specific to your application.

·         They help maintain a separation of roles by allowing different individuals or sub-teams to focus on a specific task or piece of functionality according to their focus or expertise. In particular, it provides a cleaner separation between the user interface and the business logic of the application—this means the UI designer can focus on creating a richer user experience. ”

The Prism documentation is actually very good with showing you how to accomplish individual tasks. Where the documentation falls short is when you want to bring the differing concepts together. For example, the documentation does lead you through creating an application and showing a view, what it does not show you is how to create a view that possibly contains multiple “child” views

The goals for this article are

a.       Build the Prism library

b.      Setup an application shell that shows the main window

c.       Create a module that shows a view in the main window

d.      Create a module that shows a view in the first module

e.       Create a module that shows a second view in the first module

f.       Load the modules from a configuration file

But before we get to that we have to know;

How to get and setup Prism

Head on over to the Prism web site, http://www.codeplex.com/Prism, and download the Prism package. The site also serves as the community portal to ask questions of the Prism development team. Unzip the archive to the folder of your choice then open that folder up in explorer to view the files. The folder will contain several batch files that will conveniently open up several different sections of the Prism project. The two batch files that we are interested in at this time are named “Desktop & Silverlight – Open Composite Application Library” and “Desktop only – Open Composite Application Library”. The first batch file will open up a solution that will compile the libraries to use in WPF and Silverlight. If you are not doing any Silverlight application that you can use the second batch file. But you cannot use the libraries interchangeably (I think, I have not verified this as I do not do Silverlight development but otherwise there would be no need for separate projects). So, double click the batch file of your choice and the Prism solution will load up into Visual Studio 2008 (as of this writing). Then build the solution. The output libraries will be placed in <Prism root>CAL->Desktop

Creating the shell

I am going to assume that you know how to create an application solution, reference libraries and create class libraries in Visual Studio so I am not going to explain those details in depth. If you do not, you should study those items first. The first thing to do is to fire up Visual Studio 2008. Then create a new WPF application and name it whatever you want. For the purpose of this article I will name my solution “PrismArticle”. This is going to be the “shell” for our application. The shell is just a container to display the primary user interface. The shell can contain one of more views that are displayed to the user. Note that some of the code presented is more or less boilerplate code and copied from the Prism documentation.

1.      In the solution explorer, rename Window1.xaml to Shell.xaml.

2.      Then open the code behind file and rename the class name from Window1 to Shell

3.      Open Shell.xaml and change the Title attribute to “PrismArticle” or whatever you want.

4.      Add the CompositeWPF namespace to the Shell.xaml file, xmlns:cal=”http://www.codeplex.com/CompositeWPF”

5.      Remove the Grid tags from the XAML and add a ContentControl named “MainRegion” and set the region name to “MainRegion” for Prism:

a.        <ContentControl Name=”MainRegion” cal:RegionManager.RegionName=”MainRegion”/>.

6.      Add a new class to your project named Bootstrapper.cs.

7.      Add references to the Prism libraries:

a.        Microsoft.Practices.Composite

b.      Microsoft.Practices.Composite.UnityExtensions

c.       Microsoft.Practices.Composite.Presentation

8.      Add these using statements to the top of the Bootstrapper file.

a.  using Microsoft.Practices.Composite.Modularity;

b.  using Microsoft.Practices.Composite.UnityExtensions;

c.  using System.Windows;

9.      Change the Bootstrapper class to inherit from the UnityBootstrapper class.

class Bootstrapper : UnityBootstrapper

10.  Override the CreateShell method in the Bootstrapper class.

        protected override DependencyObject CreateShell()
        {
               Shell shell = new Shell();
               shell.Show();
               return shell;
        }

11.  Override the GetModuleCatalog method.

        protected override IModuleCatalog GetModuleCatalog()

        {

            ModuleCatalog catalog = new ConfigurationModuleCatalog();

            return catalog;

  }

12.  Open the App.xaml.cs and override the Startup event.

        protected override void OnStartup(StartupEventArgs e)

        {

            base.OnStartup(e);

            Bootstrapper bootstrapper = new Bootstrapper();

            bootstrapper.Run();

        }

13.  Open the App.xaml file and remove the StartupUri since we are manually starting up the window in the bootstrapper.

Solution skeleton

Your final solution should look something like this. If all went well you should be able to build and run the application. But…

What the heck did we just do?

Everything up to step 8 should be pretty much self explanatory except for step 5.

Step 5 is where we setup a ContentControl in the shell window and named it “MainRegion”. Prism uses a concept called a Region that defines an area where a view is going to be displayed. If we had a module that mapped itself to the MainRegion, then that view would appear in that region. We will be doing just that in the next section.

Step 9 is where the application main window is created and shown.

Step 10 is where a catalog of the modules that the application uses is created. There are several different ways to accomplish this but for our example we are going to use a ConfigurationModuleCatalog which reads a configuration file and loads the modules defined in that file.

Step 11 is where the application starts up and instantiates the Bootstrapper.

Creating the first module

Before we create our first module we need to do a bit of configuration. Remember that we wanted to load our modules at runtime. To do that we have to have a place for the modules to be. So, in the solution folder create a “bin” folder, and then inside that folder create a “modules” folder. The bin folder is where we will put the executable and the modules folder is where the modules are going to go. Open up the project properties and on the Build tab set the output path to the bin folder that we just created.

Now for our first module. One thing that I deviate from the Prism documentation is that the Prism docs describe creating the regions to show the views in the shell. What I am going to do is to create a module that is shown in the main window and defines the regions for the application. This way the shell application remains static and the modules define the application. So our first module is the view that is going to be shown in the MainRegion that we defined before.

Add a Class Library project to the solution. For the sake of this example, I named my module project “MainWindowModule”. Open the Project properties select the Build tab and then change the output path to the modules folder under the bin folder that we created earlier.

Rename the Class1.cs file to MainWindow.cs. This will also rename the class to MainWindow. Add a reference to the Microsoft.Practices.Composite.dll. Then add a using statement to the top of the file:

 using Microsoft.Practices.Composite.Modularity.

Add a private variable to the class named _regionManager of type IRegionManager. The RegionManager allows us to access the regions defined in the application. Add a constructor to the class that accepts an IRegionManager parameter. Inside the constructor, make the _regionManager equal to the IRegionManager passed in.

Edit the class definition so that the class inherits from IModule. IModule is the interface that Prism uses to discover and initialize the modules. The method that we need to implement is the Initialize method. Inside the Initialize method, add the MainWindowView to the MainRegion through the region manager:

            _regionManager.Regions["MainRegion"].Add(new MainWindowView());

Now we need a MainWindowView to show in the MainRegion. Just to make things a bit tidy, add a new folder to our solution named “Views”. Inside the Views folder, add a new WPF user control named MainWindowView. To make everyone happy, you have to add another using statement to include the Views now.

using MainWindowModule.Views;

  Now, after all that what do you think will happen when you build and run the application now? Well, try it and see what happens. Go ahead. I will wait. Ready? What you should have seen is the same window we saw before we created the module and jumped through all those other hoops. If you set a break point in the Initialize method of the module you will find out that the method in not called. So what is up with that? Well before we can see the view in the main window we have to…

Configure the module

To configure the application to load our modules we have to add a configuration file to the executable project. So add a New Item -> Application Configuration File. I named my file App.config. This is the configuration file that the application is going to read to create the ConfigurationModuleCatalog in the Bootstrapper class. Add the following code to the app config file:

  <configSections>

    <section name=“modules“ type=“Microsoft.Practices.Composite.Modularity.ModulesConfigurationSection, Microsoft.Practices.Composite“ />

  </configSections>

  <modules>

    <module assemblyFile=“Modules/MainWindowModule.dll“ moduleType=“MainWindowModule.MainWindow, MainWindowModule“ moduleName=“MainWindowModule“ />

  </modules>

The Modules section defines what module to load and where to load it from. The “assemblyFile” attribute defines from where to load the module from. In this case we are loading the module from the Modules folder. The “moduleType” attribute is the name of the class that we want to load. The Prism docs call this a “type” which might be misleading for a beginner. This is the namespace and name of the class that implements the IModule interface. The last attribute simply defines the module name. There are other attributes that I will leave for another time. This is sufficient to get us going.

Now if you run the application you show at least get a stop at the break point you set earlier. But, chances are that you will see a blank window. Unless you open up the MainWindowView XAML file and put something in the window you won’t see anything. Go ahead and experiment and when you are finished playing around we will go on to the next phase.

Child views

Now that we know how to create and load a module the next thing that we want to do is to create a couple of child windows that we will display in the MainWindowView. We are not going to do anything fancy. Adding child views to the MainWindow is relatively painless. It’s basically the same as what we did for the MainWindowModule expect that the regions that we are going to define are in the MainWindowView. So, open up the MainWindowView XAML file and delete any content that you might have put there to experiment with. If you did do any experimenting you might have noticed that the contents of the MainWindowView were confined to a specific size when you resized the window. This is because of the Width and Height attributes in the view being set to 300. Go ahead and delete those two settings so that the view will fill the parent window.

 Now add a Grid layout control and define two columns. Add a content control to column zero and add another content control to column 1. Being so imaginative I named the region in column 0 “LeftChild” and the region in column 1 “RightChild”. Of course you are free to improve on that design J

Add 2 more class libraries to the solution; name one “ChildOneModule” and the other “ChildTwoModule”. The setup for these modules pretty much mimics the steps we followed to create the MainWindowView. The code for both is about the same except for the region names.

Here is what I did. Feel free to experiment. The ChildOneView I simply changed the background color and added a label to identify the view. I did the same to the ChildTwoView except I made the color different.

·         Remember to change the output path for the two modules

·         Remember to add the Prism libraries to the module projects.

·         Remember to add the module definitions to the app.config file. Note that the order in which the modules are listed matters! If you list the child modules after the MainWindowModule , Prism will throw an exception saying that the RegionManager does not contain the <name of region> region. After running around in circles for about 2 hours, you will discover that the modules appear to be loaded from the bottom up. So the MainWindowView has to get initialized first so the other views have a region to get loaded into.

The final application will look like this when it’s all said and done.

Final result from all this

Conclusion

There we have downloaded and complied the Prism Library. Created a project that created a shell window using Prism, added a module to serve as the main window view and then finally added two more modules that served as two child views and loaded into the application dynamically loaded at runtime. This allows the UI views for the application to be developed separately from each other and to be totally independent code. Hopefully this is just the beginning of an exploration of the Prism framework. Depending on my work load and motivation I may continue writing about this. Next I think that I will explore getting our two child views to communication with each without them having to know anything about each other.

Here are links to the code for this article. Rename the archive from .doc to .zip before opening, this is a wordpress requirement. The code is presented as is with no warranty implied or guaranteed.

prism-article-part-1 This is the code for the initial project

prism-article-part-2 This is the code for the second part of the article

prism-article-part-3 This is the final code solution