Inheritance of controls and forms ...

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

Hi all

It is maybe a stupid question, but I have some
trouble with Inheritance.

For example:
I create a new class with one form.
On this form I place on the bottom a Panel
and on this Panel on the right side a button.
On both controls I set Anchor (bottom, right).

Then I create a new Windows Form application.
I add a reference to my base class and add new form.
I change to the code view of the new form and I change from
"public partial class Form2 : Form"
to
"public partial class Form2 : MyBaseClassForm"
it is changeing the form as expected.

Then the problem:
I only change the size (making it bigger) of the new form,
save and close it.
When I now open the new form again, the panel and the button
are somewhere on the form, not on the buttom as expected.

What am I doing wrong ??
Thanks for any comments.

Best regards
Frank

[Peter Duniho]

On Tue, 22 Jul 2008 08:36:01 -0700, Frank Uray
<Fr*******@discussions.microsoft.comwrote:

[...]
Then the problem:
I only change the size (making it bigger) of the new form,
save and close it.
When I now open the new form again, the panel and the button
are somewhere on the form, not on the buttom as expected.

I assume "buttom" is supposed to be "bottom", and not "button"?

As for what you're doing "wrong", I'm not sure there's a good answer to
that. I understand why you would expect the Panel and Button to remain
where they were. But the Designer is only going to edit the Designer.cs
file for the Form sub-class currently being designed. Your Panel and
Button locations are actually declared in your base class's
InitializeComponent() method, and dragging the sub-class's size in the
Designer won't affect that.

One wouldn't think that this would matter, but because of the way the
Designer-generated code lays things out, it does. In particular, it
suspends layout during all of the initialization of the form itself, and
when layout is suspended, anchored items don't respond to changes in the
form size.

So, your form goes through two size changes: once in the base class, and
then later in the sub-class. During both of those size changes, layout is
suspended, and so the anchored controls just remain where they are, even
when the sub-class size changes after the base class controls have been
positioned and anchored.

I don't personally have a great solution to that issue. It's a difficult
issue for Designer to address, One might think that it's a bug in the
Designer to allow the anchored controls to move when you resize the
sub-class form. After all, since the actual run-time sizing will happen
with layout suspended, it seems like layout also ought to be suspended
during Designer editing. It wouldn't do what you want, but at least the
Designer would more correctly reflect what's going on.

But having layout suspended in the _same_ class where the controls are
declared isn't a problem, and you _do_ want the controls' position to be
updated during Designer editing, because the Designer can manage those
just fine (after all, they're in the class being designer, so the Designer
has write access to them). Just detecting the sub-class case and
disabling layout during dragging wouldn't even be sufficient, because of
the same need to move the controls that are declared within the form class
the size of which is actually be modified.

An alternative approach the Designer might take would be to explicitly
search for anchored child controls in base classes and add code to the
sub-class's InitializeComponent() method to handle them, but that starts
to get pretty messy.

In other words, I feel your pain, and I agree that it's frustrating for
the Designer to not give true "WYSIWYG" results. But I'm also not sure
that there's an obvious, simple way to fix the Designer so that it gives
the results you want. For better or worse (to some extent, mostly worse
:) ), dealing with design of sub-classes of designed forms is problematic,
for a variety of reasons. This just happens to be one of them.

Possible workaround I see include:

-- making the sub-class form non-resizable (not applicable in all
situations, of course).
-- explicitly managing anchoring behavior yourself (in the base class
constructor, examine and store the current offsets related to anchoring
for all the current child controls that are anchored, and then reapply
those offsets later, such as in the OnLoad() method).

Hope that helps.

Pete

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

So a concise version of the previous post is that the layout is suspended
while the form is sized so the panel and button dont track the form size
changed and are positioned at the same top and left as they are in the base
for. The only way to get round this is with docking. Docking the panel bottom
and the button right would make the work.
You can mess around witht the maximum size to keep the button from looking
strange and hugging the corner so tightly or use a FlowLayoutPanel docked
bottom with layout right to left.
--
Ciaran O''Donnell
http://wannabedeveloper.spaces.live.com
"Peter Duniho" wrote:

On Tue, 22 Jul 2008 08:36:01 -0700, Frank Uray
<Fr*******@discussions.microsoft.comwrote:

[...]
Then the problem:
I only change the size (making it bigger) of the new form,
save and close it.
When I now open the new form again, the panel and the button
are somewhere on the form, not on the buttom as expected.

I assume "buttom" is supposed to be "bottom", and not "button"?

As for what you're doing "wrong", I'm not sure there's a good answer to
that. I understand why you would expect the Panel and Button to remain
where they were. But the Designer is only going to edit the Designer.cs
file for the Form sub-class currently being designed. Your Panel and
Button locations are actually declared in your base class's
InitializeComponent() method, and dragging the sub-class's size in the
Designer won't affect that.

One wouldn't think that this would matter, but because of the way the
Designer-generated code lays things out, it does. In particular, it
suspends layout during all of the initialization of the form itself, and
when layout is suspended, anchored items don't respond to changes in the
form size.

So, your form goes through two size changes: once in the base class, and
then later in the sub-class. During both of those size changes, layout is
suspended, and so the anchored controls just remain where they are, even
when the sub-class size changes after the base class controls have been
positioned and anchored.

I don't personally have a great solution to that issue. It's a difficult
issue for Designer to address, One might think that it's a bug in the
Designer to allow the anchored controls to move when you resize the
sub-class form. After all, since the actual run-time sizing will happen
with layout suspended, it seems like layout also ought to be suspended
during Designer editing. It wouldn't do what you want, but at least the
Designer would more correctly reflect what's going on.

But having layout suspended in the _same_ class where the controls are
declared isn't a problem, and you _do_ want the controls' position to be
updated during Designer editing, because the Designer can manage those
just fine (after all, they're in the class being designer, so the Designer
has write access to them). Just detecting the sub-class case and
disabling layout during dragging wouldn't even be sufficient, because of
the same need to move the controls that are declared within the form class
the size of which is actually be modified.

An alternative approach the Designer might take would be to explicitly
search for anchored child controls in base classes and add code to the
sub-class's InitializeComponent() method to handle them, but that starts
to get pretty messy.

In other words, I feel your pain, and I agree that it's frustrating for
the Designer to not give true "WYSIWYG" results. But I'm also not sure
that there's an obvious, simple way to fix the Designer so that it gives
the results you want. For better or worse (to some extent, mostly worse
:) ), dealing with design of sub-classes of designed forms is problematic,
for a variety of reasons. This just happens to be one of them.

Possible workaround I see include:

-- making the sub-class form non-resizable (not applicable in all
situations, of course).
-- explicitly managing anchoring behavior yourself (in the base class
constructor, examine and store the current offsets related to anchoring
for all the current child controls that are anchored, and then reapply
those offsets later, such as in the OnLoad() method).

Hope that helps.

Pete

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

Hi Pete

Thanks a lot for your loong comments.

As the other comment was writing, I tried
to do it with docking, and this is better.
It has to be a combination of docking
and anchoring.
In my example, I dock the panel to the
bottom and anchor the button to bottom/right,
this seams to work.

Thanks and best regards
Frank Uray
"Peter Duniho" wrote:

On Tue, 22 Jul 2008 08:36:01 -0700, Frank Uray
<Fr*******@discussions.microsoft.comwrote:

[...]
Then the problem:
I only change the size (making it bigger) of the new form,
save and close it.
When I now open the new form again, the panel and the button
are somewhere on the form, not on the buttom as expected.

I assume "buttom" is supposed to be "bottom", and not "button"?

As for what you're doing "wrong", I'm not sure there's a good answer to
that. I understand why you would expect the Panel and Button to remain
where they were. But the Designer is only going to edit the Designer.cs
file for the Form sub-class currently being designed. Your Panel and
Button locations are actually declared in your base class's
InitializeComponent() method, and dragging the sub-class's size in the
Designer won't affect that.

One wouldn't think that this would matter, but because of the way the
Designer-generated code lays things out, it does. In particular, it
suspends layout during all of the initialization of the form itself, and
when layout is suspended, anchored items don't respond to changes in the
form size.

So, your form goes through two size changes: once in the base class, and
then later in the sub-class. During both of those size changes, layout is
suspended, and so the anchored controls just remain where they are, even
when the sub-class size changes after the base class controls have been
positioned and anchored.

I don't personally have a great solution to that issue. It's a difficult
issue for Designer to address, One might think that it's a bug in the
Designer to allow the anchored controls to move when you resize the
sub-class form. After all, since the actual run-time sizing will happen
with layout suspended, it seems like layout also ought to be suspended
during Designer editing. It wouldn't do what you want, but at least the
Designer would more correctly reflect what's going on.

But having layout suspended in the _same_ class where the controls are
declared isn't a problem, and you _do_ want the controls' position to be
updated during Designer editing, because the Designer can manage those
just fine (after all, they're in the class being designer, so the Designer
has write access to them). Just detecting the sub-class case and
disabling layout during dragging wouldn't even be sufficient, because of
the same need to move the controls that are declared within the form class
the size of which is actually be modified.

An alternative approach the Designer might take would be to explicitly
search for anchored child controls in base classes and add code to the
sub-class's InitializeComponent() method to handle them, but that starts
to get pretty messy.

In other words, I feel your pain, and I agree that it's frustrating for
the Designer to not give true "WYSIWYG" results. But I'm also not sure
that there's an obvious, simple way to fix the Designer so that it gives
the results you want. For better or worse (to some extent, mostly worse
:) ), dealing with design of sub-classes of designed forms is problematic,
for a variety of reasons. This just happens to be one of them.

Possible workaround I see include:

-- making the sub-class form non-resizable (not applicable in all
situations, of course).
-- explicitly managing anchoring behavior yourself (in the base class
constructor, examine and store the current offsets related to anchoring
for all the current child controls that are anchored, and then reapply
those offsets later, such as in the OnLoad() method).

Hope that helps.

Pete