How-to create user control replacing main application form

[Markus]

Hello all,

I'm wading my way into .net by writing some custom
controls. I would like to provide a parent class to these
controls to give them easy access to common information.
Initially tried this as a panel, but find that I can't
drop non-visual components onto panels (they fall through
to the main form). So now I am wondering is it possible to
override the main application form with a user-authored
form?

I tried to do this by inheriting from
System.Windows.Forms.Form, but when I instantiate such a
control in the IDE, it actually appears to spawn a new
thread consisting of an independent windows form which
can't be accessed using the normal designer interface.

Unrelated question - anyone know of a good online
reference on Attributes?

Thanks,
Markus

 

[John Cottrell]

I've implemented a custom form that inherited from
System.Windows.Forms.Form and it worked without a
problem. There is one caveat I found in the documentation
that may be your problem. You have to compile your custom
form into it's own assembly (or at least an assembly
separate from the one you're trying to use it in) and then
reference that assembly in the project that you want to
implement your custom form in.

I hope this helps!

 

[Markus]

(this is more for information - I believe I have a
solution - see the end of this post.)

I am writing several controls which are meant to work
together and require minimal coding in the main
application - i.e. when writing the application most of
the work is done through the designer.

I'll try to give a reasonably short example of two design
components:

I have a component we'll call ImageServer which has a
picture filename property (just a string) and a couple
integer properties: X & Y. X & Y divide the bitmap into a
2D-array (e.g. if the bitmap is 64x64 and X & Y are both
2, then you would have four 32x32 bitmaps). This component
includes methods to create the bitmap from a file, to
rescale it when the main form is resized, and to create
sub-bitmaps on demand which are actually glyphs used to
decorate a button-style control. The component can also
establish a path string to the filename from the
properties of a parent control, assuming it is dropped
into an appropriate container.

I then have an ImageButton type control. I would like it
to link to an instance of ImageServer and only require a
few additional numbers which will automate how it will be
painted for any given state (e.g. enabled, disabled,
etc.). The application author can also link it to
variables in the main application which will control its
state at runtime via a timer (the final application is the
front end for a real-time motion control display). This
update is also automated - so the application author only
needs to configure the timer's interval property and link
the control via the IDE.

I would like for both of these components to fit on the
same form which will provide common information (e.g. the
filename path) and also default behavior (& code) for
various events such as resizing.

So far, I implemented a panel which automatically takes up
the full client area of any form it is dropped into and
has the base information I want. It works well for visual
controls, but as I go along, it would seem what I really
want is a custom application form - one which already has
all the extra properties I want and get rid of some of the
clutter of being one layer removed from what I really want
to control.

I would settle for a panel control, but I can't figure out
how to drop non-visual objects (e.g. the ImageServer,
derived from System.ComponentModel.Component) onto a
panel. Is there an attribute for this?

Actually, as I wrote this, I thought of a possible
solution which from my 15second test seems to work -

I changed the parent class of my control from panel to
form. Now when creating my main application, instead of
selecting "Add Windows Form", I selected "Add Inherited
Form" and inherited from the custom control. I didn't
realize I could do that, but it seems to work so far. Now
to just conquer all these Attributes so I can have
appropriate controls, properties, descriptions, etc.
appear in the appropriate locations.

Thanks for your input,
Markus

 

[Gregory Persson]

Markus,

Sounds like you're on the right path. I use inherited forms extensively at
my job and they work reasonably ( but not perfectly ) well.

Here's an example of an attribute I might put above a property in my parent
form:

[
Category(cnstCategory),
Description("This description shows up in the designer"),
DefaultValue(false)
]

That's just a simple example, there's much more you can do with attributes.

Oh, and remember that the parent Form's default constructor ( and
InitializeComponents ) is called before the child constructor. If you need
to put code in the parent Form but want it to run after the child's controls
have been initalized, you can put it in the parent Form Load event.

~Greg