Question about inheritance and designer behaviour


Author
Message
Greg McGuffey
Greg McGuffey
Strategic Support Team Member (3.4K reputation)
Group: Forum Members
Posts: 2K, Visits: 6.6K
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?
Trent Taylor
Trent Taylor
StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
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.

Greg McGuffey
Greg McGuffey
Strategic Support Team Member (3.4K reputation)
Group: Forum Members
Posts: 2K, Visits: 6.6K
OK, that makes some sense.



How does .NET determine this? Is it by inheritance? Things inheriting from component and control have this behavior?
Trent Taylor
Trent Taylor
StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
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.
Greg McGuffey
Greg McGuffey
Strategic Support Team Member (3.4K reputation)
Group: Forum Members
Posts: 2K, Visits: 6.6K
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.
Trent Taylor
Trent Taylor
StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
Yup...you got it Wink
Keith Chisarik
Keith Chisarik
StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)
Group: StrataFrame Users
Posts: 939, Visits: 40K
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?

Keith Chisarik

Keith Chisarik
Keith Chisarik
StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)
Group: StrataFrame Users
Posts: 939, Visits: 40K
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.

Keith Chisarik

Trent Taylor
Trent Taylor
StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)StrataFrame Developer (10K reputation)
Group: StrataFrame Developers
Posts: 6.6K, Visits: 6.9K
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.
Keith Chisarik
Keith Chisarik
StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)StrataFrame VIP (1.5K reputation)
Group: StrataFrame Users
Posts: 939, Visits: 40K
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

Keith Chisarik

GO

Merge Selected

Merge into selected topic...



Merge into merge target...



Merge into a specific topic ID...




Similar Topics

Reading This Topic

Login

Explore
Messages
Mentions
Search