New Composite Winform Effort?

Aug 21, 2008 at 1:22 PM
Composite WPF is great and works well for WPF. It seems CAB is dead (or at least nothing new is happening on it and as far as I know, nothing is planned). I think the concepts of how Composite WPF work can be carried over to WinForms.

So the question is, is there a plan to revamp Composite WinForms and combining it with WPF or something so we're not forced down a single path for building composite applications? I mean, yes, WPF is a different programming model but like I said, you can take some of the concepts (for example using PresentationModel vs. MVP) and carry them over to WinForms. You could build a "better" CAB for WinForms using some of the principals that Prism uses.

I just feel in a bit of a lurch since it's wonderful and great using this project for WPF, but you can't use WPF for everything and frankly, it's a hard sell to build business apps using WPF when there's no real special UI needed. Yes, you can pull off a business looking app with WPF (like the Outlook UI clone) and WPF isn't all about the UI. However in discussions with managers, they're focused on the UI and see a few issues using WPF for business apps. Namely a) WPF apps generally *look* like Web 2.0 apps and are more suited to that type of look and feel b) To get some really good looking WPF apps you need to employ a designer and use additional tools (Expression Blend) and c) from a business perspective, WPF apps can look different and are a bit of a hard sell to users who are used to the traditional WinForms look and feel.

Looking for a discussion on this. I think the framework here is great, but I personally am having a hard time selling WPF and frankly I'm doubtful myself it should be used for business apps (unless the app lends itself well to a visual paradigm) and would like to open a conversation on this. What do we do? Have two paths for building apps (or three if you count web). RYO for WinForms since CAB has it's own set of problems and this project for WPF? Lots of questions in my head but no real answers.
Aug 21, 2008 at 4:48 PM
I think you'll find that CAB is not dead (and probably won't be as long as people are still building Winform apps). It might seem that way but the truth is that the framework is close to being complete (and bloated :D) and therefore there isn't much current development activity there. I have used CAB with great success in the past and would definitely still be using it if I was building Winform Apps.

Stick with SCSF/CAB if you want to build a composite client using Winforms. It even has WPF support built in so you can "sneak" a few wpf components in.
Aug 21, 2008 at 9:00 PM
Edited Aug 21, 2008 at 9:02 PM

[bsimser] looking for a discussion on this.

I remember in the Foxpro days (we were the orphans), the VB guys had a big playing field (resources) while we had to play in a small box.   It was during one of the Foxpro conferences, that we attended every year, that the red flag was raised; .NET was a big topic (in 2003) so I jumped on the C# .NET wagon - I was tired of being an orphan....  Imagine my surprise when Microsoft threw it's poster child (VB) off the cliff while Foxpro (which I haven't developed in for years) is still being supported - I can still get it on my MSDN subscription...   Microsoft has been burning bridges lately, some times while I'm still on it, i.e. Visio for architects was abandoned for VS2008 and  Notification Services for SQL Server 2008 doesn't exists. In 5 years I saw a lot go away (rightfully so); WPF is amazing and when the tools and IDEs are there methinks Winforms will be going on a stroll with Microsoft to the cliff's edge.  Odd thing is...  LINQ looks a lot like Foxpro ;)

That is my humble opinion - here is one from a guy who carries far more weight than I do :)

Glen Block wrote the following when he was part of the P&P team - I found it somewhat reassuring since I had the same impression of SCSF/CAB over a year ago (that it would be dead soon), particularly since it was practically retired with the emergence of Acropolis (and revived when Acropolis folded):

4. Win Forms is not dead. I've actually had emails from customers saying that Win Forms was being retired this year . This myth must be dispelled. Win Forms  is very much alive and there are future investments in Win Forms yet to come. Win Forms is the recommended breadth solution for LOB application development for the foreseeable future.

What about Migration?

I am sure there many who are reading this post and thinking "I need to migrate  my existing application to WPF".

My first instinct is to ask  "Why?"  Honestly. I see so many developers moving to WPF  for no better reason than that it is the new thing.  They are unable to articulate a business need. 

Many  developers believe they can take their Win Form development skills into WPF and have a similar development experience with the added benefit of much richer animations, styling, etc.  It is not that easy in our experience. We  strongly advise that you invest a significant evaluation effort before you commit down  this path.  If you cannot make this investment, we recommend that you stick with WinForms until the  support for  WPF  development evolves. For more information about using WPF for LOB applications, see David Chappel's whitepaper found here.

Aug 22, 2008 at 7:31 AM
Hi Bil

These are good questions. Throughout the development of  Prism we had thoughts around whether or not it would be applicable for Winforms. Most of the concepts we think do make sense, though we didn't put a lot of energy into thinking in that direction. We did deliberately not make things depend on WPF unless there was an absolute need. So for example we kept the module loading, event agg and few other things separated. We also had several advisors who have brought up the idea of using Prism bits for Winforms. Though I am no longer on the team, this has not been something we were serious looking at. WPF is definiately the future, while Winforms though supported, is not going to get a lot of new investment. For this reason, we haven't seen a big push to invest back in Winforms. However, if you think this is something we should do, by all means go add a WorkItem, and have others in the community vote on it.
Oct 24, 2008 at 5:55 PM

Hi, bsimser


You may find interesting Brian Noyes’ blog post Composite Extensions for Windows Forms. It provides a set of libraries to use the Composite Application Library in Windows Forms.


Hope it helps.


Ignacio Baumann Fonay

Oct 27, 2008 at 6:52 PM

Regarding the PresentationModel vs MVP example, although you could use this concept in Winforms, it would be very hard to build and mantain.
Winforms does not have a powerful binding mechanism (although it has a very basic one in some controls), so it's not straightforward to provide Presentation Models that you would be able to bind to, without having to fill your view's code-behind with binding code to overcome this limitation.

From Martin Fowler's description of Presentation Model:
    Compared to Passive View and Supervising Controller, Presentation Model allows you to write logic that is completely independent of the views used for display. You also do not need to rely on the view to store state. The downside is that you need a synchronization mechanism between the presentation model and the view. This synchronization can be very simple, but it is required. Separated Presentation requires much less synchronization and Passive View doesn't need any at all.

Julian Dominguez