I've created a suite of custom controls/components. I have 3 assemblies, as
follows:
- Definitions.dll:
This contains classes and interfaces that are common to the other 2
assemblies. There are no controls/components in this dll
- ControlA.dll:
Contains the "root" control. Only has a reference to the Definitions dll
- ControlB.dll:
This control has a property of type ControlA. As such, if there is an
instance ControlA already on the form, you should select it via a dropdown
in the property editor of ControlB. There are different varieties of
ControlB, which all implement an interface contained in Definitions.dll,
which is why ControlA and ControlB are not bundled together. ControlB.dll
contains references to Definitions.dll and ControlA.dll.
If I add ControlA to a form in a test project first, it will automatically
add a reference to Definitions.dll in this test project and one to it's own
ControlA.dll (interesting aside: The fully qualified name for
Definitions.dll is title-case capitalized in the references list, however
the ControlA.dll fully qualified name is all lower case). However, when I
add ControlB and go to the property that is type ControlA, the existing
ControlA does not show up in the dropdown list. It appears as though it
doesn't recognize the type (i.e., some kind of invalid cast)
If I add ControlB first, it too adds the Definitions.dll to the references,
along with a reference to ControlA.dll and it's own ControlB.dll
(interesting aside part 2: now, the fully qualified names for
Definitions.dll and ControlA.dll are title-case capitialized, while
ControlB.dll is all lower case).
Then I add ControlA to the form. Now when I go to the property of ControlB
that is of type ControlA, the existing ControlA does show up in the
dropdown.
For some reason, the order in which the controls are added matters - why is
this???
If I don't use the property grid, and set the property of ControlB via code,
there is no type mismatch (regardless of the order of instantiation). You
would think that if the designer didn't pick up on the ControlA type, that
there would be some sort of invalid cast exception...
Thanks for any insight,
Derrick
