Hi Kathleen,

> >And the UI code has little to do with window
> > procedures and messages; there no real advantage from using the WinForms
> > designer. If
> > there had been classes like those in the WinForms namespace all along,
> > nobody would have
> > taken VB's UI capabilities seriously. We're just used to it, that's all.

> "No real advantage from using the WinForms designer"?? Are you exaggerating
> or do you really see no advantage? I think that drag and drop visual
> development is still the best thing going in the programming world (have
> created enough forms manually in my life. Add to that the resizing and
> inheritance capabilities of VB.net and you have a far more powerful
> mechanism for Windows development than we have had before.

Well, I exaggerated; maybe I don't like the designer because it's ... v e r y s l o w ...
in Beta 2. Maybe it's because I touch-type and hate to use the mouse ...

Mostly, form creation comes down to setting a few properties and hooking up handlers. It
depends on the type of form (data form or document like form), the number of controls,
whether layout can be "automatic" (using the Dock property). Often, using the designer
will be faster. But mainly, when I have to talk to the controls in the code anyway, I
might as get used to it right away. IntelliSense does most of the typing, and the
"specifics" (like a button caption) have to be typed anyway.

I think the inheritance issue is important. The designer creates one big "kitchen sink"
sub, called "InitializeComponent". If I design a form that allows for inheritance, I'd
like to have more fine-grained control over the form creation/initialization process. For
example, a form base class might create some default context menu, but inheritors might
want to - not only extend the context menu - but maybe replace its items altogether. So,
in this case, protected overridable subs that break the whole thing into smaller pieces
can be useful.