Complex Windows Applications in C# -- how high is the bar?

[Norm Powroz]

Obviously, this is kind of a newbie question, but bear with me...

I am looking for information/opinions on the level of complexity that
can be handled in C#, given the current state of the GUI support,
using WinForms or WPF. Here's why:

I have an application that is several years old, constructed in C++
using MFC and the BCG Library. It creates (potentially) hundreds of
child windows containing various Windows controls, handles docking
windows, uses multiple toolbars, ODBC, direct database connections
with raw SQL, and so on and so forth. The best way to visualize it is
to think about Visual Studio itself -- it looks a lot like that.

Now the issue -- I need to carry out some major work on this
application in order to stretch it to handle an enitrely new database
structure. Because of some philosophical changes in the database
structure, it will be easier to scrap the existing application and
build a new one from scratch.

This leaves me with a decision -- do I reimplement in C++/MFC/ODBC, or
should I take advantage of new toys, and either target Managed C++, or
shoot the works and do it in C#. I am not a C# virgin, but neither do
I have the same level of confidence/competence with it as I do with
C++. I know that the basic program logic will be completely portable,
and the database bits can all be handled with either ADO.NET or LINQ.
My main concern is the GUI -- this is a very complex application in
terms of its user interaction, since it reduces the construction and
maintenance of a large database to drag-and-drop simplicity by way of
the user interface.

I have dabbled with both WinForms and WPF, but I am still uneasy about
how "down-and-dirty" I'll be able to get. Therefore, I am open to
suggestion, comment, opinion, flames, recommendations...any
information gladly accepted with thanks.

Cheers
Norm

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Obviously, this is kind of a newbie question, but bear with me...

Now the issue -- I need to carry out some major work on this
application in order to stretch it to handle an enitrely new database
structure. Because of some philosophical changes in the database
structure, it will be easier to scrap the existing application and
build a new one from scratch.

So basically you are going to create a new app from scratch.

This leaves me with a decision -- do I reimplement in C++/MFC/ODBC, or
should I take advantage of new toys, and either target Managed C++, or
shoot the works and do it in C#. I am not a C# virgin, but neither do
I have the same level of confidence/competence with it as I do with
C++. I know that the basic program logic will be completely portable,
and the database bits can all be handled with either ADO.NET or LINQ.
My main concern is the GUI -- this is a very complex application in
terms of its user interaction, since it reduces the construction and
maintenance of a large database to drag-and-drop simplicity by way of
the user interface.

It depends a lot of your expertise, if you are going to build it and you do
not have that much experience ni C#/.NET it would be slower than if you do
it in C++ (assuming you have experience on it).
Regarding the GUI , I have never have experience implementing very complex
interfaces but IMHO it should be at least the same doing it in C# than in
MFC, an uninformed opinion of mine is that it should be easier in .net than
in MFC.

I have dabbled with both WinForms and WPF, but I am still uneasy about
how "down-and-dirty" I'll be able to get. Therefore, I am open to
suggestion, comment, opinion, flames, recommendations...any
information gladly accepted with thanks.

WPF is a completely different approach to buildnig apps, not sure how
easy/fast it's to build a complex interface like the one you need. IMHO WPF
is more oriented to "new media" interfaces. not for something like VS

 

[Peter Duniho]

[...]
I have dabbled with both WinForms and WPF, but I am still uneasy about
how "down-and-dirty" I'll be able to get. Therefore, I am open to
suggestion, comment, opinion, flames, recommendations...any
information gladly accepted with thanks.

On the whole, I wouldn't expect rewriting an application that was already
implemented in MFC to be a problem in .NET.

The one thing you might run into is if you were subclassing existing
Windows controls, that can be harder in .NET because of the way it wraps
the unmanaged controls. Anything that is implemented directly in the
unmanaged control, you'll need to override using the WndProc rather than
the normal .NET class structure.

There are, of course, the conceptual issues. You can only decide for
yourself whether you're prepared to go through the learning curve of
adjusting to the new paradigms. .NET borrows a lot of concepts from the
native Win32 API, but it's not the same. Knowing the native Win32 API is
a big help, but you're still going to need to know all of the standard
mechanisms seen in .NET. Especially concepts like delegates, events, and
the "OnXXX" overrides in the Control classes.

If you consider yourself skilled in MFC and/or unmanaged Win32
development, I don't think you should have too much trouble adjusting.
But there's always going to be a learning curve.

Of course, all of this begs the question as to whether rewriting the
application from scratch is really a good idea. Assuming it's been under
constant development for the entire "several year" lifetime of the
application, it could easily take several more years to rewrite it in
..NET. I like .NET because it makes a lot of really basic, repetitive
stuff very easy. But the more custom behaviors you have, the less that
that advantage is going to help speed development up.

"Several years old" is really all that old for a major application. It
may make sense to consider more seriously the possibility of retrofitting
the existing application according to the needs of the new database
structure.

Pete

 

[Jeroen Mostert]

Obviously, this is kind of a newbie question, but bear with me...

I am looking for information/opinions on the level of complexity that
can be handled in C#, given the current state of the GUI support,
using WinForms or WPF. Here's why:

It's Turing-complete, innit? Should be unlimited.

OK, all flippancy aside...

I have an application that is several years old, constructed in C++
using MFC and the BCG Library. It creates (potentially) hundreds of
child windows containing various Windows controls, handles docking
windows, uses multiple toolbars, ODBC, direct database connections
with raw SQL, and so on and so forth. The best way to visualize it is
to think about Visual Studio itself -- it looks a lot like that.

Now the issue -- I need to carry out some major work on this
application in order to stretch it to handle an enitrely new database
structure. Because of some philosophical changes in the database
structure, it will be easier to scrap the existing application and
build a new one from scratch.

I've heard, seen and *done* this so many times that I feel confident in
saying that you're almost certainly wrong. Almost.

It always feels easier to programmers to scrap the whole thing and start
anew. It sure is more *fun*. And once every so often, when the system has
truly reached critical mass and maintenance has become extremely costly,
this is actually true. But think very hard about whether you're doing it for
this reason, or because you've got shiny new tools and the existing
application looks ugly to you. Have you *really* thought about how much time
and effort it would cost to adapt what's there, irrespective of how much
you'd enjoy it?

See also http://www.joelonsoftware.com/articles/fog0000000069.html

This leaves me with a decision -- do I reimplement in C++/MFC/ODBC, or
should I take advantage of new toys,

Apt wording.

and either target Managed C++, or shoot the works and do it in C#.

If you're going for a full rewrite with sparkles on top, and you're planning
to do everything anew, then I'd pick C# over Managed C++. Managed C++ is
great for what it is, but it's everything and the kitchen sink. It's great
if you need to leverage existing C++ code while still profiting from the
managed world, but at the same time this mixing of ideas can cause overhead,
clutter and lots of annoying glue. It's not my language of choice for new
projects.

I am not a C# virgin, but neither do I have the same level of
confidence/competence with it as I do with C++.

If you've got prior Java experience, this helps a lot, since C# and Java are
practically twins (the philosophies behind them differ in quite a few ways,
though).

If you're a good C++ programmer, C# should not give you much trouble. If
you're a *great* C++ programmer, C# might give you more trouble, as it
doesn't invite you to frolic around with esoteric features as much. Most
people consider this a win, though.

I know that the basic program logic will be completely portable, and the
database bits can all be handled with either ADO.NET or LINQ. My main
concern is the GUI -- this is a very complex application in terms of its
user interaction, since it reduces the construction and maintenance of a
large database to drag-and-drop simplicity by way of the user interface.

Now here's where you might run into trouble. Although WinForms is solidly
based on Win32 windowing, it's obviously much higher level. If you're
looking at MFC with a lot of low-level glue (as most apps seem to end up),
reusing that logic is pretty much pointless, so you're going to have to redo
the GUI quite thoroughly. But hey, you wanted a rewrite.

You could consider using Managed C++ anyway and rewriting only those things
that can really profit from managed code. There's nothing wrong with letting
the complex GUI stuff remain in the hands of Win32 code and use managed code
for the database access, for example.

I have dabbled with both WinForms and WPF, but I am still uneasy about
how "down-and-dirty" I'll be able to get.

This isn't that much of a problem, since the good old WindowProc overriding
is still present in .NET. You *can* get down to the individual msg if you
need to. But of course, the whole point of WinForms and WPF is that you
don't have to do that -- unlike with MFC, where it was very hard to avoid.
The problem will lie more in getting thoroughly acquainted with what
WinForms and WPF are comfortable doing, and what'll need some careful
programming.

 

[TheSilverHammer]

Being somewhat familiar with MFC and somewhat familiar with C#, but not being
an expert in either, I think my point of view might be valid.

For me, using C# and making a nice GUI APP is at least a magnitude easier in
C# then in C++ using MFC. Seriously, stuff that was cryptic and required
special tricks in MFC is a total cake-walk in C#.

There is one issue I have, which I will be writing a post about shortly,
with regards to window messaging in C#. In C# I do not know how you can
send a control a message (or a window for that matter). Thankfully, this
is rarely a problem, but once in a while it rears its ugly head. You need
to dip down into the WinProc (which is still there) and you can see where
there is a complete absence of the normal C# API polish and you have to write
the same cryptic code you do for MFC apps.


With regards to the rest of the issue, do you re-write or just fix the old
code base. Only you can answer that. Do you have the time to re-write it?
Do you think you could clean it up and make it easier to maintain? If the
answer to ether is no, then a re-write isn't an option.

If you are still on the fence, look for my question which will be posted in
this forum shortly, it may highlight an issue you may have and help you
decide what to do.

 

[Peter Bromberg [C# MVP]]

SharpDevelop is a Visual Studio -like open source IDE that is completely
written in C#. it is quite sophisticated. You can even download the source
code and explore it.
-- Peter
Site: http://www.eggheadcafe.com
UnBlog: http://petesbloggerama.blogspot.com
MetaFinder: http://www.blogmetafinder.com

 

[Fredo]

Obviously, this is kind of a newbie question, but bear with me...

I am looking for information/opinions on the level of complexity that
can be handled in C#, given the current state of the GUI support,
using WinForms or WPF. Here's why:

The GUI for this is written entirely in C#:
http://publib.boulder.ibm.com/infoc...iisinfsv.overview.doc/topics/cisoiausing.html

Here's some more about it with some more screen shots:
http://blogs.ittoolbox.com/bi/websphere/archives/information-analyzer-out-in-march-we-hope-14783

All of the controls are custom controls, many built on the WinForms controls
(which in turn, are generally built on regular windows controls). There are
exceptions. The grids and charts are based on other grid and chart controls.
Some of the controls are written from the ground-up.

As for how complex and app you can write in C#, you can do pretty much
anything.

I have an application that is several years old, constructed in C++
using MFC and the BCG Library. It creates (potentially) hundreds of
child windows containing various Windows controls, handles docking
windows, uses multiple toolbars, ODBC, direct database connections
with raw SQL, and so on and so forth. The best way to visualize it is
to think about Visual Studio itself -- it looks a lot like that.

As for the database stuff, actually Information Server has most of that
handled in Java, but you can do pretty much anything in .NET that you can do
outside of it and there's always the ability to call unmanaged code, so if,
for some reason, you can't do it in .NET, you can always write a little C++
..DLL that implements the functionality and call that from .NET.

[snip]

This leaves me with a decision -- do I reimplement in C++/MFC/ODBC, or
should I take advantage of new toys, and either target Managed C++, or
shoot the works and do it in C#. I am not a C# virgin, but neither do
I have the same level of confidence/competence with it as I do with
C++. I know that the basic program logic will be completely portable,
and the database bits can all be handled with either ADO.NET or LINQ.
My main concern is the GUI -- this is a very complex application in
terms of its user interaction, since it reduces the construction and
maintenance of a large database to drag-and-drop simplicity by way of
the user interface.

I found diving into .NET for heavy-duty programming to be far easier than I
would have expected. That said, like anything else, it has its quirks and it
takes time to learn your way around them, especially when it comes to
building custom-controls. That said, I'm about 3x or 4x as productive in C#
as I ever was in C++. I found C++ incredibly tedious and C# does a lot to
get rid of the tedium (function prototyping, dealing with strings, etc)...

I have dabbled with both WinForms and WPF, but I am still uneasy about
how "down-and-dirty" I'll be able to get. Therefore, I am open to
suggestion, comment, opinion, flames, recommendations...any
information gladly accepted with thanks.

For doing custom controls in C#, there are, fortunately, a lot of open
source examples out there to help you along. I think, in the long run,
you'll be much happier going the C# route than sticking with C++. I
certainly am!

 

[Paul Werkowitz]

Am Wed, 23 Jan 2008 13:15:41 -0500 schrieb Norm Powroz:

Hello Norm,

you have substantial new requirements to implement, so it should be clear
that you should rewrite the application from scratch. And it is absolutely
no question to use the .NET platform.

I faced the exact same problem one year ago: implement a bunch of new
functionality into our existing, large C++/MFC application, or rewrite the
whole stuff anew. I decided to to the latter, and the longer it takes, I
see that this decision was absolutely correct.

The difference is not so far a language question. I assume that any decent
C++ programmer can learn C# in days. It is more the paradigm-change that
you have to master, and which will take some time. When I look at code that
I wrote one year ago, I often immediately feel the need to rewrite it
again. It was "C++ style", and in .NET we do things differently. (I can't
go into more detail here - that would fill a book).

If you have to reimplement the data access layer, look into ADO.NET, and
compare that to the old ODBC-way....

With WinForms you can do everything you can do with MFC. Both use the
standard Windowws controls, not more, and not less. So, if your system can
handle the amount of windows in your old software, chances are that there
will be no problems with a reimplementation that uses WinForms.

WPF is different. It uses a radically different implementation model für
the GUI, as you sure know. I did some tests here and did not find any
significant problems, except that there is no DataGridView equivalent. We
do not need the fancy stuff WPF allows, but there are things that are
really nice. I like the new event model very much, as well as the new
property system. Both make solving certain problems in our software much
easier. So, WPF has advantages bsides a new GUI system.

And don't forget Silverlight. Even if our software is not intended to be
used over the net, with WPF we could easily provide that.

So, I am really happy to have decided to switch from unmanaged C++/MFC to
..NET/C#/Winformas. At the moment I consider to also use WPF-features. I
hope that next year I can say that this step was also correct. Good luck!

Paule








That is the theory. In practise, there are some considerations:

-




Whether to use "old style" C++/MFC/unmanaged etc or "new style"
C#/WinForms/WPF etc is easy






I think that there are many developers facing the same problem. Legacy
Software of some age written in C++ with MFC, ODBC etc. must be maintained.
Sooner or later management or developers ask whether it is better to
rewrite from scratch.

The decision is easy when you have substantialy new requirements to
implement, like mayor changes in the database structure, as you said. In
the long term you usualy save a lot of time when you rewrite the code.