Monthly Archives: August 2012

Things are looking good for the Runner bean plants

Lots of flowers have now turned into lots of little beans:
But will they all come at once and overwhelm us? See how many you can count.

So far we’ve had a handful of meals from them and they’ve paid for themselves already, but if this crop really comes on then they’ll have been a huge success.

WPF Window (or do I mean View) Navigation (or do I mean switching, opening, closing…) part 2 #wpf

Following on from my post WPF Window (or do I mean View) Navigation (or do I mean switching, opening, closing…) I thought I would quickly cover a slight variation on the open and close view I was doing. Essentially you might want to merely temporarily show a different view or quickly switch between views without recreating it.

To do this I updated my button and added a new button like so:

<Button Content="Switch" HorizontalAlignment="Left" Margin="0,0,0,160" VerticalAlignment="Bottom" Width="75" Command="{Binding Switch}"/>
        <Button Content="Switch Hide" HorizontalAlignment="Left" Margin="0,0,0,190.04" VerticalAlignment="Bottom" Width="75" Command="{Binding SwitchHide}"/>

The old button is now called Switch and the new button SwitchHide. I bound SwitchHide button to the SwitchHide command which is defined like so:

SwitchHide = new RelayCommand(() => { ((App)App.Current).SwitchHideWindow(); });
public RelayCommand SwitchHide { get; set; }

I then wrote the code for SwitchHideWindow in App.xaml.cs and updated the code for SwitchWindow like so:

        internal void SwitchWindow()
            // If we have extra windows the close any hidden ones
            if (Windows.Count > 1)
                foreach (Window w in Windows)
                    if (!w.IsVisible)
                        w.DataContext = null; // Ensure w no longer has a binding to the ViewModel, so we can reuse it at our leisure

            Window w0 = Windows[0];
            Window w1;

            if (w0 is MainWindow)
                w1 = new AnotherWindow();
                w1 = new MainWindow();

            w0.DataContext = null; // Ensure w0 no longer has a binding to the ViewModel, so we can reuse it at our leisure

        internal void SwitchHideWindow()
            Window w0 = Windows[0];
            Window w1;

            // Ensure we have two windows
            if (Windows.Count < 2)
                if (w0 is MainWindow)
                    w1 = new AnotherWindow();
                    w1 = new MainWindow();
                w1 = Windows[1];

            if (w1.IsVisible)

If you set breakpoints in the MainWindow and AnotherWindow constructors you will see they are not called once there are two windows and we SwitchHide between them.

Sure, we have more code now, but nothing difficult, just some demo code to show the principle.

Next time I hope to cover the swapping of controls in a view, we’ll see.

WPF Window (or do I mean View) Navigation (or do I mean switching, opening, closing…) #wpf

The motivation for this post is to explore WPF view navigation, since my most recent work had a nice (custom) framework in place where I never had to do any of the navigation I thought it was time to revisit this subject as I found myself asking a basic question, “how do I switch from this View to that View?”.

Starting at the start, I used:
– Microsoft Windows 7 Enterprise
– Microsoft Visual Studio 2010 Ultimate (Service Pack 1)
– Microsoft Expression Blend 4
– The MVVM Light Toolkit

I created an MvvmLight (WPF4) project using the Visual Studio template (installed by the toolkit), I compiled and then ran it. Great, a simple MVVM app up and running, but no app of any complexity has a single View, so I next wanted to implement another view (erm, window?) then some navigation between them.

I added a new MvvmView (WPF) and a MvvmViewModel (WPF).
Here I noticed the views are in the root level, so I did some housekeeping, giving me the following structure:
Nav (my project name)
Nav\ViewModels\AnotherViewModel.cs (mine)
Nav\Views\AnotherWindow.xaml + .cs (mine)
Nav\Views\MainWindow.xaml + .cs

The AnotherViewModel was not yet supported by the Locator, so I added the following to ViewModelLocator.cs using the mvvmlocatorproperty snippet:

        /// <summary>
        /// Gets the Another property.
        /// </summary>
            Justification = "This non-static member is needed for data binding purposes.")]
        public AnotherViewModel Another
                return ServiceLocator.Current.GetInstance<AnotherViewModel>();

And this bit into the static constructor:


Next I wired up the Binding in the AnotherWindow.xaml to use AnotherViewModel:

DataContext="{Binding Another, Source={StaticResource Locator}}"

So the view I created is now using the correct ViewModel, which is always good. And I wanted the same skin as MainWindow, so I also added the following:

                <ResourceDictionary Source="../Skins/MainSkin.xaml" />

The last few steps will be required each time a new View and ViewModel is added.

Next (more to illustrate how this thing holds together than anything else) I re-wired the App.xaml to start AnotherWindow at first:


This is my way of showing MainWindow is nothing special. Or is it? Well it does have the extra code in MainWindow.xaml.cs:

Closing += (s, e) => ViewModelLocator.Cleanup();

I don’t need this, nor do I care about cleanup in this case as the ViewModelLocator will exist till the bitter end, so I commented it out.
I then ran it up, a nice blank window this time, as planned.

I decided I wanted my App to handle the window switching, so I wrote a little method to do this for me (in App.xaml.cs):

        private int selectedWindow = 0;

        internal void SwitchWindow()
            Window cw = Windows[0];
            Window nw;
            if (selectedWindow == 0)
                nw = new MainWindow();
                selectedWindow = 1;
                nw = new AnotherWindow();
                selectedWindow = 0;

You can bind a ViewModel command to a button easily enough, so I added a RelayCommand to AnotherViewModel that called the SwitchWindow:

        /// <summary>
        /// Initializes a new instance of the AnotherViewModel class.
        /// </summary>
        public AnotherViewModel()
            Switch = new RelayCommand(() => { ((App)App.Current).SwitchWindow(); });

        public RelayCommand Switch { get; set; }

Sure I’m casting App.Current to App here, I could have created SwitchWindow as a static member of App, this would remove the need for that, but I didn’t.
I rebuilt the solution then (in blend) I added a button to AnotherWindow.xaml and drag and dropped the Switch RelayCommand onto the button, this added the following xaml:

<Button Content="Button" HorizontalAlignment="Left" Margin="272,0,0,190.04" VerticalAlignment="Bottom" Width="75" Command="{Binding Switch}"/>

I rebuilt, ran and tested I could switch one way, then I needed to add the same code to MainViewModel and button on MainWindow.xaml. On this occasion copy and paste was fine to test it and it worked going both ways as expected, the Switch code could of course be moved into a new ViewModel base class in future.
So what have I achieved here, not a lot, but in sticking the switch code into the App class I have removed any inter ViewModel dependency I would otherwise introduce, I guess I am looking at App as being my navigation controller at the moment, but this logic could of course be moved elsewhere.

Next up is to revisit view switching (within the same window), from my ASP.NET background this to me is swapping user controls. I hope to cover this in a follow up blog post.

It’s a nice warm day, time to relax

So while I was digging potatoes in the heat (yes, finally a nice day in Great Britain), the cat snoozed on the path in the shade:

It’s alright for some.

August last of the potatoes and onions

The last of the potatoes:
and some small onions which are the best of a disappointing crop:

Also, is this another ladybird or a beetle of some kind:

Either way, it is welcome if it keeps the aphids off the beans. The runner beans are still looking good, more have been eaten by the wife and a visitor without me seeing them. So there’s only tiny beans growing left, but a lot of them, so fingers crossed they mature nicely and we get overrun.

More runner beans so soon #gardening

Four more runner beans after only a few days:

The wife is happy, at this rate they’ll have paid for themselves by the weekend!
(seeds cost £1.54 from Wilkinsons of course)

Resize a VirtualBox fixed size VDI (VirtualBox Disk Image) file

If you try and resize a fixed size VDI using the command
"C:\Program Files\Oracle\VirtualBox\vboxmanage" modifyhd "C:\vms\My.vdi" --resize 45000
in a command window you would see this error:
Progress state: VBOX_E_NOT_SUPPORTED
VBoxManage.exe: error: Resize hard disk operation for this format is not implemented yet!
(of course your filename, path and resize value would be different)

There is a workaround, but you will need a lot of spare disk space…

The process is:
1) Copy / clone the VDI file to a Dynamically allocated VDI using the Virtual Media Manager (output in my case is My_copy.vdi)
2) Run the command above on the copy VDI file (i.e. "C:\Program Files\Oracle\VirtualBox\vboxmanage" modifyhd "C:\vms\My_copy.vdi" --resize 45000)
3) Release and then Remove your original VDI file (i.e. My.vdi) using the Virtual Media Manager, keep the file
4) Rename your original VDI file or back it up somewhere
5) Attach the copy VDI file (i.e. My_copy.vdi) to the VM (so it will appear in the Virtual Media Manager)
6) Copy / clone the copy VDI file to a Fixed size VDI (with the original file name, i.e. My.vdi) using the Virtual Media Manager
7) Release and then Remove the copy VDI file using the Virtual Media Manager, delete the file
8) Attach the new VDI file
9) Test
10) Remove the original renamed or backed up original VDI file when you are happy

Once complete you can re-partition, extend or whatever you wanted to do in the first place.
Of course, if you wanted to, you could leave out the copy back into a Fixed size VDI and leave it as a Dynamically allocated VDI.