Inherited forms weirdness

Thread view:

Enable EMail Alerts

Start New Thread

Thread rating:

Mike - 09 Mar 2006 01:02 GMT

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.

Reply to this Message

Mike - 09 Mar 2006 01:04 GMT

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

Reply to this Message

Marius Groenendijk - 09 Mar 2006 14:21 GMT

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.

> 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
[quoted text clipped - 14 lines]
> Has anyone else dealt with this? Have you found a workaround? This
> seems like a pretty bad bug to leave in the IDE.

Reply to this Message

Mike - 09 Mar 2006 16:37 GMT

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

Reply to this Message

Inherited forms weirdness

Free Magazines