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

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!

>-----Original Message-----
>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
>.
>

(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
>-----Original Message-----
>Markus,
>
>I'm not really sure what you are trying to do. Are you
trying to give all
>your custom controls common functionality ( like a
ToString method )? Are
>you trying to give all of your custom controls common
information( such as a
>default text value )? Are these custom controls ( custom
from the
>ground-up), composite controls ( kind of like a reusable
panel ), or are
>they extending from the base Microsoft controls( like a
custom TextBox ).
>
>attributes:
>http://msdn.microsoft.com/library/default.asp
url=/library/en-us/cpguide/htm
>l/cpcondesign-timeattributesforcomponents.asp
>
>~Greg
>
>
>"Markus" <(E-Mail Removed)> wrote in message
>news:04f101c36686$aa9e2e90$(E-Mail Removed)...
>> 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
>
>
>.
>

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
"Markus" <(E-Mail Removed)> wrote in message
news:033b01c36697$121de5f0$(E-Mail Removed)...

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