Recommended practices for CompositeControls?

Discussion in 'ASP .Net Building Controls' started by Gery D. Dorazio, Feb 28, 2007.

  1. 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? 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:


    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 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 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.

    Gery D. Dorazio, Feb 28, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.