Getting the ASP.NET Designer to persist changes from Child Collection Items properly

May 16, 2006 @ 7:25 am

One thing that really bugs me with Visual Studio and the way the designers work is that it's often pretty complicated to force the designer to update itself and persist changes in the designer to the underlying code. This is true in both WinForms and ASP.NET.

I'm working on a set of ASP.NET server controls that are extenders and the 'ExtenderItems' are shown in the property sheet and can be edited. When you make a change to a property though, those changes are not automatically persisted back into the source view even though you are talking to a live instance of one of the collection items.

To make the designer refresh is a bit of a pain – you basically have to manually force the designer to refresh itself. To do this I have to create a method like this on the Extender control (the 'host' control for the extended properties):

/// <summary>

/// this method is used to ensure that designer is notified

/// every time there is a change in the sub-ordinate validators

/// </summary>

internal void NotifyDesigner()

{

if (this.DesignMode)

{

IDesignerHost Host = this.Site.Container as IDesignerHost;

ControlDesigner Designer = Host.GetDesigner(this) as ControlDesigner;

PropertyDescriptor Descriptor = null;

try

{

Descriptor = TypeDescriptor.GetProperties(this)["DataBindingItems"];

}

catch (Exception ex)

{

return;

}

// *** This works too

//object Val = pd.GetValue(this);

//pd.SetValue(this,"___");

//pd.SetValue(this, Val);

ComponentChangedEventArgs ccea = new ComponentChangedEventArgs(

this,

Descriptor,

null,

this.DataBindingItems);

Designer.OnComponentChanged(this, ccea);

}

That's not too bad once you figure this out (with a lot of help from this article from Alex Soldatov). I spent a few hours scouring MSDN for any information on this before running into his article that also helped with a number of other issues that I'm working on.

But the real pain is that you now have to call this notification method for every change that's been made to a property of the child items. So the property implementation for any designer properties that can be set for the child properties (DataBindingItems in this case) looks like this:

/// <summary>

/// The name of the Object or DataSet/Table/Row to bind to.

/// Page or Container relative. Example: Customer.Entity = this.Customer.Entity

/// </summary>

[NotifyParentProperty(true)]

[Description("The name of the object or DataSet/Table/Row to bind to. Page relative. Example: Customer.DataRow = this.Customer.DataRow"),DefaultValue("")]

public string BindingSource

{

get { return _BindingSource; }

set

{

_BindingSource = value;

if (this.DesignMode && this.Binder != null)

this.Binder.NotifyDesigner();

}

private string _BindingSource = "";

So this sort of code has to be attached to any of the child controls that display in the designer for DataBindingItems.

While this doesn't look too bad, it's actually a bit of work to get a reference to the Binder object (the Parent Collection) which in this case is the top level Extender control. I talked about this a couple of days ago – getting a reference to the parent is not trivial in a child collection that is persisted through the designer because ASP.NET and the designer are not firing the standard Add methods on the collection child controls. The only way I was able to make this work is by implementing a custom collection rather than using the easier Generic Collection and overriding the Add method to pass an explicit reference down to the child item.

It sure would be nice if there was a way to do this with an attribute. It actually looks like this should be happening anyway with the [NotifyParentProperty(true)] but that doesn't appear to have any effect on forcing the designer to dump the values into the HTML source.

Feedback for this Weblog Entry

Collection Properties, Child Items and Page and Parent References in ASP.NET Custom Controls - Rick Strahl's Web Log
by Rick Strahl's Web Log October 15, 2006 @ 6:35 am

I've been struggling with a way to get a reference to the Page and Parent property in a collection published on an ASP.NET Custom Control. Seems this should be trivial - but collections loaded from the page loading child controls behave a little different than other child controls.

re: Getting the ASP.NET Designer to persist changes from Child Collection Items properly
by Bart Verkoeijen February 25, 2008 @ 2:09 am

I ran into the same problem months ago. I couldn't find a neat solution, until now.

In my case, NotifyParentProperty seems to work correct on properties. However, it doesn't work well with methods. Especially in a custom collection, causing the ASP.NET IDE not to persist the changes from the CollectionEditor into the source code.

However, I found two solutions for this, that both work, although the second one is more elegant.

First solution: design time property with NotifyParentProperty on the custom collection class.

For this, you need to make your collection object a custom collection class derived from the CollectionBase class.

public class NodeCollection : CollectionBase, IList<Node>, ICollection<Node>, IEnumerable<Node>
{
    // CLASS CODE HERE

    protected override void OnInsertComplete( int index, object value )
    {
        DesignState++;
        base.OnInsertComplete( index, value );
    }

    protected override void OnSetComplete( int index, object oldValue, object newValue )
    {
        DesignState++;
        base.OnSetComplete( index, oldValue, newValue );
    }

    protected override void OnRemoveComplete( int index, object value )
    {
        DesignState++;
        base.OnRemoveComplete( index, value );
    }

    protected override void OnClearComplete()
    {
        DesignState++;
        base.OnClearComplete();
    }

    private int designState = 0;
    [NotifyParentProperty( true )]
    [DesignerSerializationVisibility( DesignerSerializationVisibility.Hidden )]
    [Browsable( false )]
    public int DesignState
    {
        get { return designState; }
        set { designState = value; }
    }
}

By incrementing the DesignState property, the parent will be notified and processes the change even though it originated from a method (insert, set, remove, clear on the collection).

Second solution: Raise change events in a CollectionEditor.

This one is more neat, as you won't have code that will execute at runtime, and it saves you to manage the DesignState increment calls.

class TreeNodesEditor : CollectionEditor
{
    public TreeNodesEditor( Type type ) : base( type ) { }

    protected override Type CreateCollectionItemType()
    {
        return typeof( Node );
    }

    protected override object CreateInstance( Type itemType )
    {
        if( itemType == typeof( Node ) ) return new Node( true );
        return base.CreateInstance( itemType );
    }

    public override object EditValue( ITypeDescriptorContext context, IServiceProvider provider, object value )
    {
        context.OnComponentChanging();
        object result = base.EditValue( context, provider, value );
        context.OnComponentChanged();
        return result;
    }

    protected override object SetItems( object editValue, object[] value )
    {
        Context.OnComponentChanging();
        object result = base.SetItems( editValue, value );
        Context.OnComponentChanged();
        return result;
    }

    protected override string GetDisplayText( object value )
    {
        return ( (Node)value ).Caption;
    }
}

As you can see in the EditValue() and SetItems() methods, the ComponentChanged event is raised when the collection is manipulated.

re: Getting the ASP.NET Designer to persist changes from Child Collection Items properly
by Bart Verkoeijen February 25, 2008 @ 2:12 am

Oh, I forgot to mention that I found the first solution with help of your code comment marked with: *** This works too.
The second solution I found by examining the problem in more detail.