G
Gery D. Dorazio
I am having a very difficult time reconciling the page life cycle, and/or
design time behavior with the proper design of CompositeControl based
controls. There does not appear to be any recommended practice for when
objects within the composite control should be created in relation to the
page or designer life cycles. Is there any information on what the designer
does in Visual Studio when a property is changed?...eg what is the designer
life cycle equivalent of a page life cycle? Here is my situation:
I have created a CompositeControl named ControlMessages that simply displays
a message along with an image and a link. The css class names, forwarding
text, and image urls are all exposed String properties. The control itself
has the TypeConverter(typeof(ExpandableObjectConverter)) attribute.
This message control is meant to be aggregated into any number of other
CompositeControl class based controls.
Now I have created another control that contains text boxes, buttons and a
ControlMessages control. This new control exposes css class names,
validation expressions, and the ControlMessages control as a property. The
ControlMessages properties appear in the property window of Visual Studio
(2005 SP1). This ControlMessages property uses the following attributes:
Bindable(true),
Category("Behavior"),
DesignerSerializationVisibility(DesignerSerializationVisibility.Content),
PersistenceMode(PersistenceMode.InnerProperty),
NotifyParentProperty(true)
The problem I am having is that the subproperties which are the
ControlMessages properties do not persist in the properties window of Visual
Studio but do show up in the controls page html as enclosed tags only to be
reset back to blank when changing to design view....OR not showing up at all
in html but showing up in the properties windows as long as one doesn't
change views...eg a real mess for what amounts to a convenience at design
time. Other people have had this same problem with recommended solutions
being various application of some of the attributes as shown above. In
addition, in some properties some folks have made a call to
EnsureChildControls() while others instantiate controls at the field scope
and not in the CreateChildControls() method. And finally, VS SP1
installation was recommended but I already have that.
I looked at how Microsoft designed their Login, LoginStatus, Wizard
controls. The architecture of these controls varies from templated to
non-templated, with and without some of the attributes mentioned and also
varied as to when child controls actually were instantiated. I was under the
impression that EnsureChildControls() is something that should be called
during a life cycle event and not left to when someone might get/set a
property. What was also surprising was that properties at the top level
custom control were duplicated when compared to the contained control. This
effectively bypassed the need for DesignerSerializationVisibility attribute
which makes me think this particular attribute doesn't really work and I
have been wasting a lot of time. But I do not want to introduce 'bloat' into
my controls either as other developers have pointed out given the design of
these framework controls. Somehow I want to believe that the attributes
really work.
So coming full circle then...is there any documentation somewhere that can
guide one in developing CompositeControl based custom controls which
encompasses page life cycle, and/or design time behavior so that proper (and
reliable) controls can be developed.
Thanks,
Gery
design time behavior with the proper design of CompositeControl based
controls. There does not appear to be any recommended practice for when
objects within the composite control should be created in relation to the
page or designer life cycles. Is there any information on what the designer
does in Visual Studio when a property is changed?...eg what is the designer
life cycle equivalent of a page life cycle? Here is my situation:
I have created a CompositeControl named ControlMessages that simply displays
a message along with an image and a link. The css class names, forwarding
text, and image urls are all exposed String properties. The control itself
has the TypeConverter(typeof(ExpandableObjectConverter)) attribute.
This message control is meant to be aggregated into any number of other
CompositeControl class based controls.
Now I have created another control that contains text boxes, buttons and a
ControlMessages control. This new control exposes css class names,
validation expressions, and the ControlMessages control as a property. The
ControlMessages properties appear in the property window of Visual Studio
(2005 SP1). This ControlMessages property uses the following attributes:
Bindable(true),
Category("Behavior"),
DesignerSerializationVisibility(DesignerSerializationVisibility.Content),
PersistenceMode(PersistenceMode.InnerProperty),
NotifyParentProperty(true)
The problem I am having is that the subproperties which are the
ControlMessages properties do not persist in the properties window of Visual
Studio but do show up in the controls page html as enclosed tags only to be
reset back to blank when changing to design view....OR not showing up at all
in html but showing up in the properties windows as long as one doesn't
change views...eg a real mess for what amounts to a convenience at design
time. Other people have had this same problem with recommended solutions
being various application of some of the attributes as shown above. In
addition, in some properties some folks have made a call to
EnsureChildControls() while others instantiate controls at the field scope
and not in the CreateChildControls() method. And finally, VS SP1
installation was recommended but I already have that.
I looked at how Microsoft designed their Login, LoginStatus, Wizard
controls. The architecture of these controls varies from templated to
non-templated, with and without some of the attributes mentioned and also
varied as to when child controls actually were instantiated. I was under the
impression that EnsureChildControls() is something that should be called
during a life cycle event and not left to when someone might get/set a
property. What was also surprising was that properties at the top level
custom control were duplicated when compared to the contained control. This
effectively bypassed the need for DesignerSerializationVisibility attribute
which makes me think this particular attribute doesn't really work and I
have been wasting a lot of time. But I do not want to introduce 'bloat' into
my controls either as other developers have pointed out given the design of
these framework controls. Somehow I want to believe that the attributes
really work.
So coming full circle then...is there any documentation somewhere that can
guide one in developing CompositeControl based custom controls which
encompasses page life cycle, and/or design time behavior so that proper (and
reliable) controls can be developed.
Thanks,
Gery