Suppose I have a custom control that has a nested child property group, like this:

<cc1:mycontrol [properties]>
  <childpropertyname [properties]>
  </childpropertyname>
</cc1:mycontrol>

I attempted to setup a skin that sets a property in <childpropertyname>. I receive the compiler error "Control skins cannot contain child controls". (Please assume that the syntax of the main control definition is fine and there are no errors if I omit <childpropertyname>.) While the child property is indeed a control, its still a property declaration syntax as if I had defined some other non-control object.

1. Can I declare any form of child property in a skin or is it limited to the top level?
2. What are the requirements for a child property to work with a skin?
3. Is this a bug since its a child property that happens to be a control class?

Background:
In my example, the <childpropertyname> is actually another WebControl whose properties are exposed and uses these attributes to define itself:
[PersistenceMode(PersistenceMode.InnerProperty)]
[DesignerSerializationVisibility(DesignerSerializationVisibility.Content)]

Plus it has [ParseChildren(false)] and [PersistChildren(false)], and uses AddParsedSubObject() to assign the child control to that property. A ControlBuilder maps the <childpropertyname> to the object instance used by that property.

I think Skins are in Preinit so what you are trying to do is far down the  Asp.net 2.0 HTTP pipeline to be valid.  Try the link below on how you can implement skins.  I would also run a search on Brock Allen posts about Themes on this site .  I could be wrong.  Hope this helps

http://www.ondotnet.com/pub/a/dotnet/2004/11/15/libertyonwhidbey.html

Thank you for the article. I think the info about the PreInit phase is pertinent. However, I'd still like to know what is permitted with child properties that are created using PersistanceModeAttribute.InnerProperty.

I am also curious if there are attributes, interfaces, and/or overrideable methods that a custom control developer can use to apply a skin to child properties or on demand (such as when a child property's object is created and now needs its skin applied.)

PLBlum wrote:

Thank you for the article. I think the info about the PreInit phase is pertinent. However, I'd still like to know what is permitted with child properties that are created using PersistanceModeAttribute.InnerProperty.

I'm sure you've come to this realization by now, but the problem is the fact that your property is a Control, as opposed to just some other type that holds the property data. I've gotten [PersistanceModeAttribute.InnerProperty] properties to work fine in the .skin.

Now, as to why it specifically doesn't like your nested property as a Contorl is another question. Perhaps it's just a simple check in the .skin code to disallow nested controls. I don't know for sure; Perhaps some time with Reflector would help.

-Brock

Try this link new link he is also at this site,  Microsoft is providing only HTML pages.  Hope this helps.

http://fredrik.nsquared2.com/viewpost.aspx?PostID=146

PLBlum wrote:

I have been trying to track down the actual code in reflector but got lost when I found a Page gets attached to some kind of event handler which does the work. Any idea on the class that does the actual loading of skins and/or deploying its values to the object?

The way it works is that the .skin is a compiled class that keeps an index table of control type/code pairs. For each index (so say typeof(Calendar), typeof(Table), etc) there is code that was emitted by the ASP.NET parser (as it was parsing the .skin) that's much like the code the parser emits when it's parsed ASPX files that sets all of the properties as declared in the .skin. So, when the theme is applied in the page, every control in the page's control hierarchy is walked and is compared to the map kept by the skin. If a control in the page hierarchy is matched, then the code associated with the key (meaning, that type of control) is executed. The mechanics of the execution is via a delegate and that's why you don't see in Reflector where it's "going", so to speak.

The best way to see this is to precompile your site, then use reflector to see the assembly generated for the .skin files.

-Brock