[Mono-list] Windows forms

Dominic Pease handor@peaseassociates.com
Tue, 9 Jul 2002 06:13:27 -0500

Has anyone considered getting in contact with the ECMA and attempting to
get the ball rolling on a standard windowing specification? Certainly,
MS is heavily involved in TC39-TG3 (as they ought to be), so they might
not be receptive to such proposals; but, after all, the website states
that the group's second priority (after the core specifications were
completed) is: 

'2. Upon completion of item 1, to investigate the future direction of
CLI standards, and to evaluate and consider proposals for complementary
or additional technology [1]'

Might be worth a shot. If it accelerates the process (which I feel is
inevitable), it could be good for everyone.

-----Original Message-----
From: mono-list-admin@ximian.com [mailto:mono-list-admin@ximian.com] On
Behalf Of Mike Kruger
Sent: Tuesday, July 09, 2002 1:33 AM
To: mono-list@ximian.com
Subject: Re: [Mono-list] Windows forms


>    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
> > 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
to implement a forms
designer or docking you simply can't in pure Windows.Forms (.NET has a
designer build in,
but I mean programming a forms designer on your own) because you can't
'deep enough'. With
Java Swing you've more power (you could overwrite what you want). A
wrapper is something
other than a C# implementation, but Windows.Forms suffers from not
good user ideas. I assume
that the GTK# coders accept ideas/changes when they're good and improve

Ok now to some points which come into my mind :

- Bad idea : ImageLists. They may be more performant or may save memory
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
option which allows customize the
buttons. But other classes have the same problem the messagebox was only
example out of many.

- Bad idea : Not mighty enough. You simply can't do anything in .NET
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
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
their control model here. It is always bad, if you don't
follow your own model. (A MainWindow is a Control, therefore it should

+ 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
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
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

>     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
> 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
be hard. SharpDevelop is highly modularized
I could port a thin subset first and then step by step. I have
the GUI layer (because I've thought
that the day dumping Windows Forms would come ...) to make the port


Mono-list maillist  -  Mono-list@ximian.com