Doesn’t <asp:A runat=”server” B=”someValue” … /> syntax violate one of the basic rules in C# language?

Assuming server control of type A has a protected member M, then we are also able to access A.M via d开发者_开发百科eclaring control tag A on some aspx page:

<asp:A runat=”server” M=”someValue” … />

But isn’t one of the rules in C# that protected members of class A can only be accessed from A and from classes derived from A? So doesn’t the ability to access member A.M via <asp:A M=”someValue” … /> syntax violate this rule, since we are basically accessing A.M from a class ( which is automatically generated aspx class ) not derived from A?!

---

I didn't understood how <asp:A B=”someValue” is related to A.M in sentence "o doesn’t the ability to access member A.M via ".

Although i didn't fully understood your post i can tell you: "Don't worry!". Asp.net will never let your violate c# rules because this xml/html like notation is then translated into C# itself.

---

Your markup cannot touch a protected property. I just tested this:

<cc1:ServerControl1 ID="ServerControl11" runat="server" Text="Text Set"
     ProtectedText="foo" />

protected string ProtectedText { get; set; }

protected override void RenderContents(HtmlTextWriter output)
{
    output.Write(Text);
    output.Write(ProtectedText);
}

This does not display "foo". The property is never modified.

If you set the page to Debug="true":

<%@ Page Language="C#" ... Debug="true" %>

then the C# files that ASP.NET turns your markup into will be left on disk under C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files. It will take some hunting to find the right directory, but here's what I saw for that markup:

[System.Diagnostics.DebuggerNonUserCodeAttribute()]
private global::ServerControl1.ServerControl1 @__BuildControlServerControl11() {
    global::ServerControl1.ServerControl1 @__ctrl;

    #line 15 "C:\Documents and Settings\jsaunder\My Documents\Visual Studio 2008\Projects\SOSoln\WebApplication1\Default.aspx"
    @__ctrl = new global::ServerControl1.ServerControl1();

    #line default
    #line hidden
    this.ServerControl11 = @__ctrl;
    @__ctrl.ApplyStyleSheetSkin(this);

    #line 15 "C:\Documents and Settings\jsaunder\My Documents\Visual Studio 2008\Projects\SOSoln\WebApplication1\Default.aspx"
    @__ctrl.ID = "ServerControl11";

    #line default
    #line hidden

    #line 15 "C:\Documents and Settings\jsaunder\My Documents\Visual Studio 2008\Projects\SOSoln\WebApplication1\Default.aspx"
    @__ctrl.Text = "Text Set";

    #line default
    #line hidden

    #line 15 "C:\Documents and Settings\jsaunder\My Documents\Visual Studio 2008\Projects\SOSoln\WebApplication1\Default.aspx"
    ((System.Web.UI.IAttributeAccessor)(@__ctrl)).SetAttribute("ProtectedText", "foo");

    #line default
    #line hidden
    return @__ctrl;
}

Note what happened to my "foo".

---

This only holds if the member you're setting is not public. Otherwise, you'd never be able to set any properties on any object from anywhere.

---

I think what you're asking, is why are protected properties exposed when working with a control in the page markup.

Try this: mark a Property on a custom control or user control as protected. What you'll find is you can set its value in the markup, but not the page code-behind. This is the expected behavior. When you edit property values of a control in markup, this isn't violating any visibility/accessibility rules IMO. You are editing the properties of a control within the control in essence. If you mark the Property as private, you'll find you can't even edit in markup as expected.

If you then move to the code-behind of your page, and try to change or access the same protected property, you'll find it isn't visible. This is because you are trying to access the property from 'outside' the control (from the page class), and the protected rule is enforced.

Hope this helps clarify. I think what you need to consider is in your markup, changes to control properties are considered 'within' the control since they are within the markup of that control. Hard to explain but I think I hopefully made my point...

---

Control Properties accessed from the calling Page object need to have the public access specifier.

See Properties, Methods, and Events for Custom Controls

Adding properties and methods is easy — a method is any public procedure you declare in your control class; a property can be declared using a Property statement in Visual Basic, or implemented as a public member variable in C#.

---

I just ran a quick test and I wasn't able to access a protected member of a server control from a web form. But I made it public and rebuilt the application and it was accessible, as expected.

Is it possible that you didn't recompile the application after setting the field to protected?