[Mono-list] Windows forms
Tue, 9 Jul 2002 08:33:07 +0200
> I am glad that you joined the discussion, because you have a lot of
> experience with Windows.Forms.
> > It's a lot of work, but Windows.Forms suck and when GTK# is good it may
> > worth the effort.
> There are two things I would like to explore from you:
> * What pieces of Windows.Forms are good.
> * What parts of Windows.Forms you think are bad.
Unfortunately there aren't many good pieces. Windows.Forms is a bit like
Java.AWT with some
more classes. All is good if you're programming 'low level' but if you want
to implement a forms
designer or docking you simply can't in pure Windows.Forms (.NET has a forms
designer build in,
but I mean programming a forms designer on your own) because you can't go
'deep enough'. With
Java Swing you've more power (you could overwrite what you want). A control
wrapper is something
other than a C# implementation, but Windows.Forms suffers from not including
good user ideas. I assume
that the GTK# coders accept ideas/changes when they're good and improve the
Ok now to some points which come into my mind :
- Bad idea : ImageLists. They may be more performant or may save memory or
something else, but giving
a reference to a Bitmap is more flexible in my opinion. This old windows
technlogy shouldn't live on.
- Bad idea : The most classes are only 'toys'. Like the RichTextBox, you
can't even scroll the scrollbars on your own.
- Bad idea : Too many enums instead of a more flexible approach like the
strategy pattern. Java Swing is here much better. Sometimes it were much
nicer if they've taken a more
flexible approach. Example : The MessageBox.Show, you can have buttons :
yes/no/cancel, OK, yes/no etc. but not
your custom buttons. I think that is bad. It would be more nice to have an
option which allows customize the
buttons. But other classes have the same problem the messagebox was only one
example out of many.
- Bad idea : Not mighty enough. You simply can't do anything in .NET what
you could do with MFC.
I agree that this point is difficult when you write a wrapper but free
software is flexible enough to change
the faults. Per example : You can't set the context menu of a form caption
bar. The MainMenu is not flexible
enough you can't change the drawing of the 'form' which shows the menu
items, only the menuitem drawing, you can only
put it on top with a property in the Form. I think that they don't follow
their control model here. It is always bad, if you don't
follow your own model. (A MainWindow is a Control, therefore it should be
+ Good idea : Easy to use (but this is almost any OOP GUI Framework I
encountered). But they've a easy model with docking/anchors etc. Not having
layout managers or something like this makes
it a lot easier to 'draw' a Form. (but it has well known downsides too ...)
+ Good idea : It's hard for me to say which ideas are good, because the bad
ideas are more appearant.
I can't even list the controls which are good, because almost every
Windows.Forms control (even
the button) is rewritten by someone else who found that someone is missing.
> I want to know what is good, because perhaps we could implement
> those pieces at least, and people could use a combination of the good
> pieces, with pieces from a differen toolkit (simplifying for example the
> effort to port SharpDevelop).
I don't know, if it is good to mix up APIs. I like consistent APIs :)
One of the callenging parts of the SharpDevelop port is the port of the
TextArea Control ... when that is
finished the rest is piece of cake ... it's a bit of work but it shouldn't
be hard. SharpDevelop is highly modularized
I could port a thin subset first and then step by step. I have abstracted
the GUI layer (because I've thought
that the day dumping Windows Forms would come ...) to make the port