Can Cinch Extend and Replace?

Oct 15, 2010 at 8:15 AM


I've just finished going through all the Cinch V1 and V2 articles and I think this framework has some great features that we want to use in our project. The problem is that what we are wanting to extend a current large Winform project with new WPF MVVM views and piece by piece replace winforms with views until the application is fully WPF MVVM. The first catch I can see is of the boot strapper for the single main WPF window. We've got proof of concept applications working that has a Winform calling WPF Views that create their own ViewModels, but to use Cinch I can only think of creating the Cinch boot strapping and MainWindow on the Winform statup and make the Main WPF Window invisible and have public methods in it to create each view/view model as needed. Can you advise if this is sort of thing is possible with Cinch?


Oct 17, 2010 at 9:36 AM

if you look at the Cinch boot strapper code (take WPF boot strapper code for example), you will realise this could be run anywhere. So for your Winforms app, in the constructor of the main form or something like in main method, (you may have to show a splashscreen if it takes too long for you)


Here is the code: 

namespace Cinch
    public static class CinchBootStrapper
        public static void Initialise(IEnumerable assembliesToExamine)
                //now pass the same Assemblies to the ViewResolver so it can
                //resolve the workspace Types
            catch (Exception ex)
                throw new InvalidOperationException("Bootstrapper.Initialise() failed", ex);

All this does is populate 2 dictionaries in the ViewResolver and PopupResolver static classes using attributed on popups and views. 


So in theory that bootstrapper code can be run anywhere you like, just so long as you know about all assemblies that use these Cinch attributes, all is cool


Oct 18, 2010 at 3:16 PM

Actually reading your message again, you will probably want to use CinchV1, as it is ViewModel 1st approach, which you can still do with Cinch V2, but CinchV1 did it more like you would with WinForms, where each View can be created like SomeView x = new SomeView() and the ViewModel was created in code behind in the view. 


CinchV2 is different beast altogether and is really designed with the single shell window idea (as are most WPF apps)

Oct 19, 2010 at 12:33 AM

I was hoping to not use CinchV1 as the features of CinchV2 are preferable and also using Blend for the View layout. I was off sick yesterday so haven't created a proof of concept with your boot strapping code above.

Maybe it's because of too many years with LOB WinForms and a not so favourable experience using MDI but why is there this fairly common idea of WPF single window concept? I conceptualise UI's as interconnected black boxes. Having views as just regions of a window seems very limiting on UI real estate space options. The users like rather busy looking UI focusing on the task at hand with very little non-important "visual noise". This is especially true for the ones that have to use the keyboard only and yes the application that we're extending has a mouseless section.

Oct 19, 2010 at 2:08 PM

Yeah its just that WPF and the binding system seems to be more suited to use a single shell window. Window states and their DialogResult/Owner is a hard thing to manage using MVVM, Blend was actually 1st big WPF app, and that was Shell idea and then came PRISM, which was designed around Shell idea.


Cinch will work with loads of standalone windows, the only thing that maybe hard is managing the Owners of the popup windows, the UIVisualiserService can be used for this, I do cater for DialogResult also, but this is one failing of MVVM in my opinion, that is does not deal with disparate windows, and the binding offered by WPF makes it easier to use ObservableCollection<SomeViewModel> and bind that to a TabControl items source say, than it would be to create popups and manage their state and ownership. Put MVVM in the mix and you will soon see why single shell is better suited for MVVM.

Oct 20, 2010 at 12:42 AM

Thanks for that. I'm creating some test apps to see how I can get my head around this? I'm thinking of a Base View Window that has public methods which the Winform app can call which then creates the WPF user control views as needed.

I'm trying to do a simple thing that I've created in previous apps of creating a Keyboard binding to the Escape key to close the current view. Previously I did this with a relay command and created the event hook in the view code behind, but what would be the Cinch way of doing this?

Oct 20, 2010 at 2:01 AM

I've been scratching my head on the Single Window issue and I'm not sure how to solve a problem in our scenario. With regards to the mouseless UI's we would need to use the workspaces with a TabControl or the like and only make visible the last opened tab. This is because to close the view we must either use the Escape keybinding for no save and close or the Enter keybinding for save and close.

Whereas if I used the seperate View stand alone windows, then couldn't I use (as you said) the DialogResult and Mediator Messaging and I wouldn't need any popup windows as they are all effectively popup windows?

Nothing like learning to swin by jumping into the deep end...

Oct 20, 2010 at 8:52 AM

I think to truly get an idea of how a single windows app could work, just check out Blend. Also have a look at PRISM (that Patterns & Practices, so should be based on best practices allegedly), which is also based on single window idea. Also have a look at transitionals hosted here at codeplex, and check out my BreadCrumb article on my blog, that uses a single content control, and transitions it in using transitionals:


here is link to transitionals:

here is link to my breadcrumb atricle (watch the video) using transitionals:


You can do what you want, its just not done that way too much, most WPF apps WILL be single window apps, even massive LOB ones, we are doing entire Fx trading system, and backoffice handliing for it, and that is 1 window app.