The workaround
The property value storage problem is the only bug in Visual Studio that
affects working with extender providers in ASP.NET pages - all other
design-time support works fine. But it is a critical bug: you can't work
with extender providers unless you find a way to store and initialize the
property values correctly.
The core of our workaround is to use (de)serialization to store all
property values. The InitializeComponent method will look like:
private void InitializeComponent()
{
this.MyProvider1 = new MyProvider();
this.MyProvider1.PropertyData = @"AAEAA -- many more characters -- Cw==";
this.MyProvider1.VSDesigned = this;
}
The PropertyData string contains serialized values of the provided
properties (i.e., of the _Values hash table in the example). As PropertyData
is a public property of the provider component, Visual Studio knows how to
handle it at design-time.
The second property, VSDesigned, is needed to deserialize the PropertyData
string. The string cannot contain object references (like this.Label1),
so we serialize the name of the controls. In the deserialization process we
need to know the top-level (Page or UserControl) object to turn the names
into control references again. As a component has no direct access to its
owner at run-time, we need an extra property to achieve that.
The SetDoMagic calls would follow the assignment of the
properties. As the assignments are incorrect, we don't want them to appear
in the InitializeComponent method. This is easy: tell Visual Studio
that the Page or UserControl object cannot be extended and the SetDoMagic
calls disappear. As a consequence, it is not possible to set a provided
property for the page object at design-time using the IDE. If you need to do
that, add a SetDoMagic call by hand.
|