Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

WinForms inadequate for large applications?

I'm an old hand at MFC programming, and I'm considering moving to WinForms. Microsoft has proclaimed from the top of all the mountains that WinForms is "The One True Way" to write new Windows client applications. However, WinForms provides considerably less functionality than MFC. In particular, it's missing features such as:
- Command unification (activating the same command in multiple ways, e.g. from a menu item and a toolbar).
- Command routing (the same command can be handled in multiple places. The rules that determine *who* will get the command at any given moment can be quite complicated).
- Automatic enabling/disabling of commands (using OnUpdateXXX() methods).
... etc.

This is very annoying. WinForms expects the program to hardwire the connetions between all command Sources and Targets; it's as if the Design Patterns movement never happened.

My question is: has anyone used WinForms to write a large(ish) application? Did you decide to rewrite the missing functionality yourself, or make do without?

Tuesday, September 7, 2004

You might find some of what you're looking for in the Genghis Project,

Mike Gunderloy
Tuesday, September 7, 2004

I've been using WinForms for our database application, and had to wrestle with the issues that you mention surounding Commands. I have ended up building my own command framework, which wasn't very much work once I had the inspiration!

Samuel Jack
Tuesday, September 7, 2004

I'm using WinForms for a medium sized application, more or less succesfully. But I don't really have a lot of Commands at all. No toolbar, and only maybe half a dozen menu options that are used frequently.

But if I DID have a lot of Commands, yes, I'd miss what WinForms lacks, though Mike G's link is a good place to start.

You may also want to look at CommandBar ( ) though it's not as comprehensive a library as Genghis is going for.

Having messed around some with OS X/Cocoa before launching into this project, I'm sorry that WinForms doesn't really do MVC either, though I'm managing to roll my own OK.

Adam Vandenberg
Tuesday, September 7, 2004

In short, .NET is great for server but not so great for clients. I know from somebody comming from VB or hard-code C++ is a improvenment, but working with .NET, Visual FoxPro, Delphi for real and large applications i can say from my experience that .NET is the worst of all for build non-server/no-librarys applicacations. Delphi won for a very large shot (in fact, .NET and CommandBar are a copy from Delphi Actions Bands).

Also, .NET Winforms is a dead end: is deprecated by avalon (and is very sad to know that Avalon is the thing, deprecating technology BEFORE be launch!). Is slow, paint slow, perform slow (mainly: lack of support for that hyper great 200 US graphics card: Winforms support for hardware aceleration - inluded integrated 4 mb chips- = NONE)

Today, i see that the practical approach is build the server with .NET and use a BEST tool for GUIS (Delphi, V FoxPro, Dreamweaver). If you need "upgrade" to .NET in the GUI side, Delphi today is the only way (can use/share code and GUI forms)....

If want to take the .NET rute, i suggest HEAVILY look for good thirdy-party tools....Is unpractical go with the included framework, except for toy tools

Monday, September 13, 2004

"Also, .NET Winforms is a dead end: is deprecated by avalon"

Not again this nonsense! .NET 2.0 includes a great many new features for WinForms. Also, Avalon won't be available for quite some time, and then it won't be compatible with pre-XP systems.

Besides, WinForms is simply a wrapper around Win32 so what you're saying is that the UI libraries of .NET competitors like Delphi are "deprecated" as well...

"Is slow, paint slow, perform slow (mainly: lack of support for that hyper great 200 US graphics card: Winforms support for hardware aceleration - inluded integrated 4 mb chips- = NONE)"

You misunderstood something here. It's GDI+ which does not yet have full hardware support, and that may cause poor performance with customized visual effects. But if you stick to standard WinForms or libraries built on top of it, that's not an issue since they get exactly the same hardware acceleration or lack thereof as any old Win32 application, including FoxPro or Delphi.

When WinForms are slower than raw Win32 it's because of the managed wrapper classes stacked on top of them, not because of the actual drawing.

Chris Nahr
Tuesday, September 14, 2004

*  Recent Topics

*  Fog Creek Home