Inherited forms weirdness

[Mike]

I've got a base form in my library DLL, and an inherited form in the
client exe. This works wonderfully, until I go to make a change to the
inherited form. For example, if I resize the child form it'll
re-create object declarations in InitializeComponent(). So, if I have:
Protected myObject as SomeComponent in the parent form, it'll
automatically re-create the same declaration in the child form.
Sometimes it'll just come up as Friend myObject as SomeComponent,
others it'll be set to private and so on. And it'll recreate the code
for initializing, so it'll do myObject = new SomeComponent() twice.

This doesn't always happen, but it happens often enough that it's
becoming a problem.

I've seen this happen with various controls, but it really messes up
when I use ComponentOne controls (e.g. the toolbar control).

Has anyone else dealt with this? Have you found a workaround? This
seems like a pretty bad bug to leave in the IDE.

 

[Mike]

I neglected to mention that I'm using .NET 1.1/Visual Studio 2003 for
this.

 

[Marius Groenendijk]

Hi Mike,

Seen that too but now I can't reproduce this problem...

I've definitely seen it happen (VB.NET).
If it happens, start with a clean slate.
- throw away the derived form
- quit and re-open IDE
- rebuild sln
- try adding the inherited form again.

If the controls in your base form are 'protected' you may find
code in InitializeComponent of the inherited form. This reflects
the mods you made in the designer of the inherited form.

If the controls in the base are 'private' this obviously doesn't
happen. Therefore I'd make all inherited controls in the base
form 'private' and selectively expose properties that you may want
to modify in inherited forms.

In our scenario the OK, Cancel and Help btns are private.
The inherited forms only access the Enabled property of the Ok button.
So we only expose the Enabled property of the Ok button.
Nothing else is known about the buttons. So no code in the
inherited form.

Also have a look at BrowsableAttribute() to avoid exposing the custom
properties to the designer. Not sure it helps.

If in the IDE you switch access of a base-form control between
protected and public or vv. the IDE may get into trouble and
generates redundant code in the inherited forms (maybe the resource files
that are used to generate the code in InitializeComponent - I really dunno)

HTH & regards,
Marius.

 

[Mike]

Thanks Marius.

Using your suggestions I think I've hit upon a solution (this is a
library for my co-workers, so I have to minimize the amount of
busy-work they have to do when developing). I made the offending
controls private as you suggested and then exposed their parent
container control via a property (we need to be able to add controls to
the container on the client side). The up side is that I can access
the base controls and container, which has yet to give me a problem,
through code and modify their properties. The downside is that I can't
modify the base controls through the designer, but I can modify their
container via the designer, so we can still add controls on the client
side. It's a trade off, but it'll have to do for now.

Thanks for your help,
Mike