Vanishing Custom User Control Bug

  • Thread starter Thread starter Phil Cullum
  • Start date Start date
P

Phil Cullum

Hi

I am currently designing a Windows form which inherits from a basic
custom dialog form. The new form uses custom user controls. When the
form is compiled, the custom controls disappear and the message

"There is already a component named 'myControl'. Components must have
unique names, and names must be case-insensitive. A name also cannot
conflict with the name of any component in an inherited class"

appears for each disappeared control in the task window. This is very
confusing because the form that is inherited does not contain any
instances of myControl, only two windows buttons and an error
provider.

Has anyone a clue as to why this may be happening?

Regards, Phil
 
I've said it before, and I'll say it again: Visual Inheritance is lame. It
is buggy, and everyone has issues with it. If you're using it, and you have
'wierd' issues, don't be supprised.

J
 
I figured out the problem with this one...

The disappearing control is added to its parent control before its
Properties are set.

There are two ways to solve this.
1. Delete the parent object and add it again in the design mode.
2. Go into InitializeComponent(), and change the order of the
disappearing component initialization to be before its parent control.
This involves changing the order where it is declared, where the
variable is initialized, and where the properties are set.

Sincerely,
Brian Takita
 
Jeremy,

Most of the 'wierd' issues I've had, had to do with the ordering of the
generated code.
The way to fix these 'wierd' issues is to manually change that the
controls are initialized.

Brian Takita
 
Thanks Brian, I'll try this out.

We actually now seem to have solved this problem through changing our
compilation process. When I first saw this problem all our binaries
were copied to one central folder as part of the build. If a project
depended on another project in the solution then the reference was set
to the appropriate DLL in this binaries folder. Now each dependent
project simply references another project in the solution, with the
result that we haven't seen this problem since. If anyone knows why
this has had an effect I would be interested to know.

Regards, Phil
 
Back
Top