bypassing the Windows Form Designer

[TomC]

I want to bypass the Windows Form Designer in VS, to create a form
programmaticall y. The elements of the form are to be arranged in a
table, and I want the size of the table (and therefore the number of
elements) to be determined at runtime, so dragging and dropping on the
Form Designer won't cut the mustard.

I'm coming from a Java background, and have almost always built my
GUI's programmaticall y, but I realize that in C# this practice is the
exception, rather than the rule.

I created a version of what I'm trying to create in the Forms
Designer, and I've been studying the generated code. I think that I
have a decent idea regarding most of what I need to do, but I'm not
sure if I should tinker with that code, or eliminate that file from
the solution and start my own file. I'm also not clear whether that
file is subclassing the System.Windows. Form class, or just
instantiating an instance of it. I also thought I'd better ask if
there are any particular "gotcha's" that I need to look out for.

TIA
Tom

[=?Utf-8?B?TW9kZWxCdWlsZGVy?=]

RE: bypassing the Windows Form Designer

I can understand your perspective coming from the same background. In
general, until some of the newer Java IDE's came along, most people did that.
The newer Java kids though are going to the IDE and leaving our ways in the
past.

You can certainly build a class that inherits from System.Windows. Forms, and
builds itself programatically . I don't know any gotchas, but maybe someone
else does.

I think the biggest drawback to your plan would be for your manager and the
person who has to maintain your code if you were to move onto another
project. This never would happen of course, from most of our perspectives
:), but, understanding your code as an outsider might be more difficult if it
were not built visually.

"TomC" wrote:

I want to bypass the Windows Form Designer in VS, to create a form
programmaticall y. The elements of the form are to be arranged in a
table, and I want the size of the table (and therefore the number of
elements) to be determined at runtime, so dragging and dropping on the
Form Designer won't cut the mustard.
>
I'm coming from a Java background, and have almost always built my
GUI's programmaticall y, but I realize that in C# this practice is the
exception, rather than the rule.
>
I created a version of what I'm trying to create in the Forms
Designer, and I've been studying the generated code. I think that I
have a decent idea regarding most of what I need to do, but I'm not
sure if I should tinker with that code, or eliminate that file from
the solution and start my own file. I'm also not clear whether that
file is subclassing the System.Windows. Form class, or just
instantiating an instance of it. I also thought I'd better ask if
there are any particular "gotcha's" that I need to look out for.
>
TIA
Tom
>
>

[TomC]

Re: bypassing the Windows Form Designer

On Jul 22, 7:28 pm, ModelBuilder
<ModelBuil...@d iscussions.micr osoft.comwrote:

I can understand your perspective coming from the same background. In
general, until some of the newer Java IDE's came along, most people did that.
The newer Java kids though are going to the IDE and leaving our ways in the
past.

I suspect that those that go beyond the basics will eventually need to
know how to write their own GUI code regardless of what language they
are using, or what IDE they are using. For example, in my current
project, what I need cannot be done in the Form Designer since I
cannot know what the form needs to look like at design time. It has
to be created at runtime.

You can certainly build a class that inherits from System.Windows. Forms, and
builds itself programatically . I don't know any gotchas, but maybe someone
else does.
>
I think the biggest drawback to your plan would be for your manager and the
person who has to maintain your code if you were to move onto another
project. This never would happen of course, from most of our perspectives
:), but, understanding your code as an outsider might be more difficult if it
were not built visually.

I understand the point that you are making. However, this is a
personal project, so I am both my manager, and the person who will
have to maintain the code, so that isn't a concern. However, even if
that were not the case, what I am trying to create cannot be done in
the Form Designer, so coding it myself is my only option.

Thanks for your input.

[Fred Mertz]

Re: bypassing the Windows Form Designer

In terms of code, all the form designer does for you is write some code and
stick it into a partical class. Then, when a VS user wants to modify the
form or controls on it, the form designer reads the code from the designated
partial class and updates the designer surface accordingly; to give the user
a preview of the runtime appearance of the form and its controls. But
there's nothing magical about the code itself - and no hidden code is
generated by the form designer. So there's nothing preventing you from
writing similar code and setting the particular controls and their property
values at runtime (perhaps from a database). Just don't expect the form
designer to be able to work with your code files (which you apparently don't
want to do anyway).

You might want to emulate the partial class situation implemented by Visual
Studio where form and control layout code (generated by the form designer)
is placed in one partial class (file) while code for event handlers and
other UI-specific logic goes into another partial class (file). This is one
way to "separate the concerns." You can have more than two partial classes
(files) - and the compiler merges them into one class in the output
assembly.

-HTH

[Peter Duniho]

Re: bypassing the Windows Form Designer

On Sun, 22 Jul 2007 19:01:08 -0700, TomC <tom.cowdery@bi gfoot.comwrote:

>In fact, as you have probably already noticed, all that the VS Designer
>does is write the code that generates the GUI programmaticall y. The GUI
>is still generated programmaticall y; it's just that you don't have to
>explicitly write the code to do it if you don't want to.

>
Perhaps I should have worded it differently. My point is that I need
the design to be generated dynamically, which the Form Designer code
obviously cannot do.

I understand that. The point to which you're replying is simply that all
of the GUI creation is still effectively done programmaticall y. As
opposed, for example, to the native Win32 mechanism of using dialog
resources to define a template used to instantiate a dialog or other
window, all of the GUI information is declared in code when using the VS
Designer.

If you wanted to do things programmaticall y in native Win32 code, even
using the dialog resource editor would not give you anything that is
useful as a starting point, because the dialog resource editor doesn't
generate code that you can copy and paste. But with the .NET Forms
Designer, because the tool is generating code, you can easily copy and
paste it as needed.

That's all I'm saying.

[...]

>When you create a new Form in the Designer, you are subclassing the Form
>class, as you can see by looking at the class declaration for your form
>(by default, the first form in the project is called Form1, and the
>declaration looks like "class Form1 : Form").

>
I don't see that declaration, but I may not know exactly how to find
it all yet. I'm still getting accustomed to the VS editor. But the
code in the Main method in Program.cs (Application.Ru n(new Form1())
made me think that Form1 must be a subclass of Form.

It is.

By default, the first form in a project is called Form1, and inherits
Form. The code can be found in two different files: Form1.cs, and
Form1.Designer. cs. The first file is where your own code goes, while the
second is where the code written by the Designer goes. Using the Solution
Explorer in VS, you can open either of these files; to open the Form1.cs
file, you need to right-click on Form1.cs and choose "View Code",
otherwise you just get the form designer itself.

In _both_ of those files, at the top of the file, the very first class
declaration will be for Form1, and will include the ": Form" showing that
Form is inherited.

Pete

[Ben Voigt [C++ MVP]]

Re: bypassing the Windows Form Designer

In _both_ of those files, at the top of the file, the very first class

declaration will be for Form1, and will include the ": Form" showing that
Form is inherited.

Pretty sure the base class is listed in only one of the partial class
definitions... checking some designer generated code... yup.

By default, the file XYZ.Designer.cs won't list the base class. XYZ.cs
will, or you can use .NET Reflector against the compiled assembly to verify
it.

>
Pete

[Peter Duniho]

Re: bypassing the Windows Form Designer

On Mon, 23 Jul 2007 10:32:03 -0700, Ben Voigt [C++ MVP]
<rbv@nospam.nos pamwrote:

>In _both_ of those files, at the top of the file, the very first class
>declaration will be for Form1, and will include the ": Form" showing
>that
>Form is inherited.

>
Pretty sure the base class is listed in only one of the partial class

Okay. Rephrase then: "in at _least_ one of the those files..."

The point being that designed forms are inherited from Form.

I can't even imagine trying to reimplement an entire Form-like class from
scratch, even deriving from Control instead of Form. Oh, the pain...

Pete

[Fred Mertz]

Re: bypassing the Windows Form Designer

RE:
<< I can't even imagine trying to reimplement an entire Form-like class from
scratch, even deriving from Control instead of Form. Oh, the pain...>>

But that's what a "real man" would do... no messing with ridiculous
"training wheels" like Visual Studio or it's sissy designers. I write all of
my .NET-compliant code in assembler - yep - I'm a real man. Even wrote my
own slimmed down version of the CLR... has only what I need and nothing
else... no bloatware comes from my shop.

[TomC]

Re: bypassing the Windows Form Designer

On Jul 23, 12:55 pm, "Peter Duniho" <NpOeStPe...@nn owslpianmk.com>
wrote:

On Mon, 23 Jul 2007 10:32:03 -0700, Ben Voigt [C++ MVP]
>
<r...@nospam.no spamwrote:

In _both_ of those files, at the top of the file, the very first class
declaration will be for Form1, and will include the ": Form" showing
that
Form is inherited.

>

Pretty sure the base class is listed in only one of the partial class

>
Okay. Rephrase then: "in at _least_ one of the those files..."
>
The point being that designed forms are inherited from Form.
>
I can't even imagine trying to reimplement an entire Form-like class from
scratch, even deriving from Control instead of Form. Oh, the pain...
>
Pete

Well, I'm not planning on recreating the Form class from scratch, just
writing my own subclass from scratch. I've been following your
suggestions and I'm happy with the results. I can't see anything in
the Form Designer since the layout isn't determined until runtime, but
when I run the code what I've got so far looks pretty good.

Thanks for your help!