> These AddRange statements do give errors as AddRange and DataSource mode
> of
> operation for comboBoxes are not compatible. But the key question is why
> the
> runtime attributes need to be forced-in at the design time.

"essgee" <essgee@discussions.microsoft.com> wrote in message
news:AA7DF62A-B53D-4381-AE30-E9673CD71294@microsoft.com...
> Inheriting Forms (aka Visual Inheritance) is quite useful. However, I have
> found VS2005 facilitation of this feature a little bit quirky. (It may
> also
> be true for VS2003)
>
> Firstly one has to presume that some controls on the base Form will be
> declared as Protected. (Purists may argue against it and would suggest
> exposing only via get/set etc.) There is no problem creating an inherited
> Form, but as soon as you want to add additional controls, some undesirable
> baggage may start appearing in InitializeComponent. It appears that along
> with the Protected Control from the base Form, its state is also hauled
> in.
> For example, a protected comboBox which is being populated (from Database)
> by
> Form_Load event, will have values added statically (using AddRange) in the
> InitializeComponent. Why?! Yes, the combobox needs populating but that
> should
> happen when constructor for the base Form is run (and at that time values
> in
> the underlying database may be different). Moreover this stuff will hang
> around until you do a further control change to the derived Form that
> triggers InitializeComponent rearrangement.
>
> These AddRange statements do give errors as AddRange and DataSource mode
> of
> operation for comboBoxes are not compatible. But the key question is why
> the
> runtime attributes need to be forced-in at the design time.
>