bypassing the Windows Form Designer

  • Thread starter Thread starter TomC
  • Start date Start date
T

TomC

I want to bypass the Windows Form Designer in VS, to create a form
programmatically. 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 programmatically, 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
 
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.
 
[...]
I'm coming from a Java background, and have almost always built my
GUI's programmatically, but I realize that in C# this practice is the
exception, rather than the rule.
Click to expand...

An exception, maybe. Probably not as uncommon as you might think though.

In fact, as you have probably already noticed, all that the VS Designer
does is write the code that generates the GUI programmatically. The GUI
is still generated programmatically; it's just that you don't have to
explicitly write the code to do it if you don't want to.
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.
Click to expand...

One advantage of starting with the designer-based code is that you can
create "template" instances of the controls you intend to use, and then go
to the designer-generated code to copy and paste all of the code related
to the instantiation of that template instance into a new method in the
form to create an arbtitrary instance of the template.

Then you can simply go back to the designer and delete the template
instance from the form, so that it's only created when you call the method
you just created based on the designer-generated code. (Actually, you
could edit the designer-generated code by hand, but it's pretty easy to
mess something up and get yourself into a frustrating state of having the
designer complain that the code isn't right).
I'm also not clear whether that
file is subclassing the System.Windows.Form class, or just
instantiating an instance of it.
Click to expand...

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 also thought I'd better ask if
there are any particular "gotcha's" that I need to look out for.
Click to expand...

Nothing comes to mind, really. Just make sure you follow the pattern that
the Designer is using in its auto-generated code, and you'll be fine.

Pete
 
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.
Click to expand...

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.
Click to expand...
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.
 
[...]
I'm coming from a Java background, and have almost always built my
GUI's programmatically, but I realize that in C# this practice is the
exception, rather than the rule.
Click to expand...

An exception, maybe. Probably not as uncommon as you might think though.

In fact, as you have probably already noticed, all that the VS Designer
does is write the code that generates the GUI programmatically. The GUI
is still generated programmatically; it's just that you don't have to
explicitly write the code to do it if you don't want to.
Click to expand...
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.
One advantage of starting with the designer-based code is that you can
create "template" instances of the controls you intend to use, and then go
to the designer-generated code to copy and paste all of the code related
to the instantiation of that template instance into a new method in the
form to create an arbtitrary instance of the template.

Then you can simply go back to the designer and delete the template
instance from the form, so that it's only created when you call the method
you just created based on the designer-generated code. (Actually, you
could edit the designer-generated code by hand, but it's pretty easy to
mess something up and get yourself into a frustrating state of having the
designer complain that the code isn't right).
Click to expand...
The latter is what I feared. Sounds like I made the right decision
not to edit it. Instead, I created a separate class, subclassed Form,
and copied/pasted/modified what I needed.
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").
Click to expand...
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.Run(new Form1())
made me think that Form1 must be a subclass of Form.
Nothing comes to mind, really. Just make sure you follow the pattern that
the Designer is using in its auto-generated code, and you'll be fine.

Pete
Click to expand...
Thanks for the input. I just figured it couldn't hurt to ask if there
are any known problems. At this point, I'm not familiar enough with
C# to be able to debug every mistake I might make.
 
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
 
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.
Click to expand...

I understand that. The point to which you're replying is simply that all
of the GUI creation is still effectively done programmatically. 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 programmatically 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").
Click to expand...

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.Run(new Form1())
made me think that Form1 must be a subclass of Form.
Click to expand...

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
 
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.
Click to expand...

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.
 
Pretty sure the base class is listed in only one of the partial class
Click to expand...

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
 
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.
 
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
Click to expand...

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!
 
Back
Top