StrataFrame Forum » .NET Forums » General .NET Discussion » Question about inheritance and designer behaviour

Question about inheritance and designer behaviour

Greg McGuffey — Wed, 17 Jun 2009 16:14:36 GMT

I'm confused about how properties work within the designer.

If I have a form and I add a public property to the form, after I build the assembly, the property is there in the property window.

However, if I have a BO or a UserControl and I add a property, after I build the assembly, the property isn't in the property windows of the UserControl or BO itself. It will be in the property window of an instance I've dropped on a form or some other container, but not in the designer for the object itself. The property will also show up in the property window of any sub-classed objects.

So, what determines what ends up in that little property window?

RE: Question about inheritance and designer behaviour

Trent L. Taylor — Wed, 17 Jun 2009 16:14:36 GMT

LOL...most likely this is what I mentioned in my previous post. Let me know if you want to tinker with this some more. It will require some time to get it setup and troubleshoot...but I already know that it has to do with reflection.

RE: Question about inheritance and designer behaviour

Keith Chisarik — Wed, 17 Jun 2009 15:19:26 GMT

Here is is, for the time being I got around the problem by declaring it again as SHADOWS in my 2nd level BO, at least if I decide to change it someday that will give me a nice fat compile error.

''' <summary>

''' Sets the required field dispay type

''' </summary>

<Category("SDSI: Custom Settings")> _

<Description("Set the type of required field indicator.")> _

<DefaultValue(True)> _

Public Property sdsi_RequiredFieldIndicatorType() As RequiredFieldIndicatorType

Get

Return Me.p_RequiredFieldIndicatorType

End Get

Set(ByVal value As RequiredFieldIndicatorType)

Me.p_RequiredFieldIndicatorType = value

End Set

End Property

RE: Question about inheritance and designer behaviour

Trent L. Taylor — Wed, 17 Jun 2009 15:13:05 GMT

What does your property definition look like? Do you have a ReflectionPropertyDescriptor (or any property descriptor) setup for these custom properties? If so then you may be fighting good ol' reflection and inheritance issues. There are times that you have to "re-expose" a property....however, it depends on how the properties are declared. I would need some more information to be able to give you any real suggestions.

RE: Question about inheritance and designer behaviour

Keith Chisarik — Wed, 17 Jun 2009 14:52:15 GMT

update: this works fine (as described above) if A, B, and C BO's are in the same assembly together, then instantiated from another.

If I move A to another assembly I get the behavior described above.

RE: Question about inheritance and designer behaviour

Keith Chisarik — Wed, 17 Jun 2009 14:31:48 GMT

If I may expand up on this a little to address multiple layers of inheritance.

I have a base BO with properties defined, business objects that inherit from this base class have the properties visible in the designer when dropped on a form. Cool. Good stuff, no news here.

I now need to add another layer of inheritance so that:

BASE BO A - has a defined property that should be available to ALL BO's

BASE BO B - inherits from A and will have additional properties that only some BO's will ever need

BO C - inherits from B

My instance of B on the form does not have property as defined in A available in the designer, but I can reference/set it via code.

Why.. and how to fix?

RE: Question about inheritance and designer behaviour

Trent L. Taylor — Wed, 04 Mar 2009 07:40:49 GMT

Yup...you got it ;)

RE: Question about inheritance and designer behaviour

Greg McGuffey — Tue, 03 Mar 2009 22:07:50 GMT

Oh...I think the light bulb just went off!

So, when I look at a BO in design view, where I can get to the properties window, the BO I'm on isn't really being instantiated yet, thus properties of that BO aren't shown. The same for a control or component, because the control itself isn't instantiated by the designer of that control.

However, when plopped on a form or user control, the BO/control/component is instantiated by the designer and now the properties are available.

The reason that form/user control properties would show up in the designer is because the form/user control is actually instantiated by the designer, thus the properties are shown in that case.

I think that is what's going on in any case.

RE: Question about inheritance and designer behaviour

Trent L. Taylor — Tue, 03 Mar 2009 13:24:31 GMT

Inheritance can play a factor. For example if you add properties to a form then inherit that frorm, they will be visible wihtin the designer. However, ifyou create a control and never inherit it, as soon as you drop it on a form those properties (as an instance) will be available within the designer. Ultimately it comes down to when the object is created as an instance, even for design-time purposes.

RE: Question about inheritance and designer behaviour

Greg McGuffey — Tue, 03 Mar 2009 11:36:05 GMT

OK, that makes some sense.

How does .NET determine this? Is it by inheritance? Things inheriting from component and control have this behavior?

RE: Question about inheritance and designer behaviour

Trent L. Taylor — Tue, 03 Mar 2009 08:03:00 GMT

A property defined on a control itself will never show up within a property designer. The purpose of a control and a control property is for use on a parent container or form or object other than itself. So these properties will only show up as an instance. This actually makes a lot of sense as the logic behind these properties is going to happen within the instance.

So like you mentioned, any defined properties on a control will not show up until created as an instance. You can make properties show up on a control through a lot of work and editor logic....but I am not even going down this road on this thread as that is a HUGE conversation in and of itself.