Web Controls/User Controls - Access Modifier

Discussion in 'ASP .Net' started by Mr Newbie, Oct 31, 2005.

  1. Mr Newbie

    Mr Newbie Guest

    I am messing around with Web User Controls at present and (think) I have
    discovered the following.

    1.) The identifier for the control in the code behind must match the ID for
    the control on the page.

    2.) The identifier must be delcared with a minimum access of 'Protected' in
    order to work.

    If the above is indeed correct, then I have made the following assumptions
    for which I would be grateful if someone who knows far more than I, could
    either validate or correct for me.

    1.) The assembly needs to set these objects when the page is loaded and
    assumes that the ID is allways the same as the ID in the HTML. This is
    different from Windows Forms, where the controls may be made private if
    required as the objects are instantiated within the form and do not need to
    be set from an external object.

    2.) Because of 1.) Non private access modifier are required.

    I hope I have understood this correctly; I look forward to being corrected
    or otherwise.


    Many Thanks - Mr Newbie . . .
     
    Mr Newbie, Oct 31, 2005
    #1
    1. Advertising

  2. > 1.) The identifier for the control in the code behind must match the ID
    > for the control on the page.
    >
    > 2.) The identifier must be delcared with a minimum access of 'Protected'
    > in order to work.


    Correct.

    > 1.) The assembly needs to set these objects when the page is loaded and
    > assumes that the ID is allways the same as the ID in the HTML. This is
    > different from Windows Forms, where the controls may be made private if
    > required as the objects are instantiated within the form and do not need
    > to be set from an external object.
    >
    > 2.) Because of 1.) Non private access modifier are required.


    No. Let me explain. ASP.Net 1.1 is a bit confusing because a Template is
    actually a class definition, even though it doesn't look like one. This is
    why you can include CodeBehind in a .aspx page, rather than necessarily
    using the CodeBehind method. The CodeBehind method is more for the purpose
    of separating the presentation layer into logical "sections," the visible
    presentation layer, and the logic that drives the visible presentation
    layer.

    When using the CodeBehind model, therefore, the Page Template (class) (or
    UserControl Template - both are Templated Controls), inherits the CodeBehind
    class. Therefore, for the CodeBehind class to access or control Controls in
    the Template class, the CodeBehind class must declare these instances, and
    the declarations in the CodeBehind class must, naturally, match the usage of
    these instances in the Template.

    ASP.Net 2.0 introduces a new concept, "partial classes." A partial class is
    a single class definition that spans multiple pages. In the 2.0 model, it is
    not necessary to do this declaration in the CodeBehind because the Template
    does not inherit the CodeBehind, but is, in fact, merged with the CodeBehind
    to create a single class definition.

    So, in summary, the CodeBehind is a class definition, and the Template is a
    class definition. As they are 2 different class definitions, in order for
    the CodeBehind to manipulate instances of Controls in the Template which
    inherits it, the instances must be declared as members of the base
    (CodeBehind) class for the Template.

    --
    HTH,

    Kevin Spencer
    Microsoft MVP
    ..Net Developer
    A watched clock never boils.

    "Mr Newbie" <> wrote in message
    news:...
    >I am messing around with Web User Controls at present and (think) I have
    >discovered the following.
    >
    > 1.) The identifier for the control in the code behind must match the ID
    > for the control on the page.
    >
    > 2.) The identifier must be delcared with a minimum access of 'Protected'
    > in order to work.
    >
    > If the above is indeed correct, then I have made the following assumptions
    > for which I would be grateful if someone who knows far more than I, could
    > either validate or correct for me.
    >
    > 1.) The assembly needs to set these objects when the page is loaded and
    > assumes that the ID is allways the same as the ID in the HTML. This is
    > different from Windows Forms, where the controls may be made private if
    > required as the objects are instantiated within the form and do not need
    > to be set from an external object.
    >
    > 2.) Because of 1.) Non private access modifier are required.
    >
    > I hope I have understood this correctly; I look forward to being corrected
    > or otherwise.
    >
    >
    > Many Thanks - Mr Newbie . . .
    >
    >
    >
    >
    >
     
    Kevin Spencer, Oct 31, 2005
    #2
    1. Advertising

  3. Mr Newbie

    Mr Newbie Guest

    Ahhh Haaaa!!!

    Code Behind Class
    |
    |
    Web Page Class (aspx - inherits Code Behind)

    I now see exactly how this works from reading your reply. This has been most
    informative Kevin, so thanks for the explanation. This had me bugged until I
    read your reply, but it all makes perfect sense now.

    I hate not understanding things as fully as possible, because it only leads
    to confusion when things go wrong and you need to fix them. Knowing the
    whole picture sure makes diagnostics easier. It has also cleared up a
    question I have had for a while regarding binding context statements.

    I have had a little dabble with ASP.NET 2.0, and the partial classes also do
    seem to make things a lot clearer from the developer perspective as one
    doesent have all that designer code hanging around your own functional
    code, which makes it look so busy ( esp with windows forms designer code ).

    Thanks Again - Mr Newbie.










    "Kevin Spencer" <> wrote in message
    news:...
    >> 1.) The identifier for the control in the code behind must match the ID
    >> for the control on the page.
    >>
    >> 2.) The identifier must be delcared with a minimum access of 'Protected'
    >> in order to work.

    >
    > Correct.
    >
    >> 1.) The assembly needs to set these objects when the page is loaded and
    >> assumes that the ID is allways the same as the ID in the HTML. This is
    >> different from Windows Forms, where the controls may be made private if
    >> required as the objects are instantiated within the form and do not need
    >> to be set from an external object.
    >>
    >> 2.) Because of 1.) Non private access modifier are required.

    >
    > No. Let me explain. ASP.Net 1.1 is a bit confusing because a Template is
    > actually a class definition, even though it doesn't look like one. This is
    > why you can include CodeBehind in a .aspx page, rather than necessarily
    > using the CodeBehind method. The CodeBehind method is more for the purpose
    > of separating the presentation layer into logical "sections," the visible
    > presentation layer, and the logic that drives the visible presentation
    > layer.
    >
    > When using the CodeBehind model, therefore, the Page Template (class) (or
    > UserControl Template - both are Templated Controls), inherits the
    > CodeBehind class. Therefore, for the CodeBehind class to access or control
    > Controls in the Template class, the CodeBehind class must declare these
    > instances, and the declarations in the CodeBehind class must, naturally,
    > match the usage of these instances in the Template.
    >
    > ASP.Net 2.0 introduces a new concept, "partial classes." A partial class
    > is a single class definition that spans multiple pages. In the 2.0 model,
    > it is not necessary to do this declaration in the CodeBehind because the
    > Template does not inherit the CodeBehind, but is, in fact, merged with the
    > CodeBehind to create a single class definition.
    >
    > So, in summary, the CodeBehind is a class definition, and the Template is
    > a class definition. As they are 2 different class definitions, in order
    > for the CodeBehind to manipulate instances of Controls in the Template
    > which inherits it, the instances must be declared as members of the base
    > (CodeBehind) class for the Template.
    >
    > --
    > HTH,
    >
    > Kevin Spencer
    > Microsoft MVP
    > .Net Developer
    > A watched clock never boils.
    >
    > "Mr Newbie" <> wrote in message
    > news:...
    >>I am messing around with Web User Controls at present and (think) I have
    >>discovered the following.
    >>
    >> 1.) The identifier for the control in the code behind must match the ID
    >> for the control on the page.
    >>
    >> 2.) The identifier must be delcared with a minimum access of 'Protected'
    >> in order to work.
    >>
    >> If the above is indeed correct, then I have made the following
    >> assumptions for which I would be grateful if someone who knows far more
    >> than I, could either validate or correct for me.
    >>
    >> 1.) The assembly needs to set these objects when the page is loaded and
    >> assumes that the ID is allways the same as the ID in the HTML. This is
    >> different from Windows Forms, where the controls may be made private if
    >> required as the objects are instantiated within the form and do not need
    >> to be set from an external object.
    >>
    >> 2.) Because of 1.) Non private access modifier are required.
    >>
    >> I hope I have understood this correctly; I look forward to being
    >> corrected or otherwise.
    >>
    >>
    >> Many Thanks - Mr Newbie . . .
    >>
    >>
    >>
    >>
    >>

    >
    >
     
    Mr Newbie, Oct 31, 2005
    #3
  4. My pleasure.

    Yes, partial classes do seem to me to be useful. I have seen them employed
    quite effectively with Windows Forms templates. I haven't gotten into
    ASP.Net 2.0 much yet, but I imagine they are just as helpful there.

    Time will tell.

    --
    HTH,

    Kevin Spencer
    Microsoft MVP
    ..Net Developer
    A watched clock never boils.

    "Mr Newbie" <> wrote in message
    news:...
    > Ahhh Haaaa!!!
    >
    > Code Behind Class
    > |
    > |
    > Web Page Class (aspx - inherits Code Behind)
    >
    > I now see exactly how this works from reading your reply. This has been
    > most informative Kevin, so thanks for the explanation. This had me bugged
    > until I read your reply, but it all makes perfect sense now.
    >
    > I hate not understanding things as fully as possible, because it only
    > leads to confusion when things go wrong and you need to fix them. Knowing
    > the whole picture sure makes diagnostics easier. It has also cleared up a
    > question I have had for a while regarding binding context statements.
    >
    > I have had a little dabble with ASP.NET 2.0, and the partial classes also
    > do seem to make things a lot clearer from the developer perspective as one
    > doesent have all that designer code hanging around your own functional
    > code, which makes it look so busy ( esp with windows forms designer
    > code ).
    >
    > Thanks Again - Mr Newbie.
    >
    >
    >
    >
    >
    >
    >
    >
    >
    >
    > "Kevin Spencer" <> wrote in message
    > news:...
    >>> 1.) The identifier for the control in the code behind must match the ID
    >>> for the control on the page.
    >>>
    >>> 2.) The identifier must be delcared with a minimum access of 'Protected'
    >>> in order to work.

    >>
    >> Correct.
    >>
    >>> 1.) The assembly needs to set these objects when the page is loaded and
    >>> assumes that the ID is allways the same as the ID in the HTML. This is
    >>> different from Windows Forms, where the controls may be made private if
    >>> required as the objects are instantiated within the form and do not need
    >>> to be set from an external object.
    >>>
    >>> 2.) Because of 1.) Non private access modifier are required.

    >>
    >> No. Let me explain. ASP.Net 1.1 is a bit confusing because a Template is
    >> actually a class definition, even though it doesn't look like one. This
    >> is why you can include CodeBehind in a .aspx page, rather than
    >> necessarily using the CodeBehind method. The CodeBehind method is more
    >> for the purpose of separating the presentation layer into logical
    >> "sections," the visible presentation layer, and the logic that drives the
    >> visible presentation layer.
    >>
    >> When using the CodeBehind model, therefore, the Page Template (class) (or
    >> UserControl Template - both are Templated Controls), inherits the
    >> CodeBehind class. Therefore, for the CodeBehind class to access or
    >> control Controls in the Template class, the CodeBehind class must declare
    >> these instances, and the declarations in the CodeBehind class must,
    >> naturally, match the usage of these instances in the Template.
    >>
    >> ASP.Net 2.0 introduces a new concept, "partial classes." A partial class
    >> is a single class definition that spans multiple pages. In the 2.0 model,
    >> it is not necessary to do this declaration in the CodeBehind because the
    >> Template does not inherit the CodeBehind, but is, in fact, merged with
    >> the CodeBehind to create a single class definition.
    >>
    >> So, in summary, the CodeBehind is a class definition, and the Template is
    >> a class definition. As they are 2 different class definitions, in order
    >> for the CodeBehind to manipulate instances of Controls in the Template
    >> which inherits it, the instances must be declared as members of the base
    >> (CodeBehind) class for the Template.
    >>
    >> --
    >> HTH,
    >>
    >> Kevin Spencer
    >> Microsoft MVP
    >> .Net Developer
    >> A watched clock never boils.
    >>
    >> "Mr Newbie" <> wrote in message
    >> news:...
    >>>I am messing around with Web User Controls at present and (think) I have
    >>>discovered the following.
    >>>
    >>> 1.) The identifier for the control in the code behind must match the ID
    >>> for the control on the page.
    >>>
    >>> 2.) The identifier must be delcared with a minimum access of 'Protected'
    >>> in order to work.
    >>>
    >>> If the above is indeed correct, then I have made the following
    >>> assumptions for which I would be grateful if someone who knows far more
    >>> than I, could either validate or correct for me.
    >>>
    >>> 1.) The assembly needs to set these objects when the page is loaded and
    >>> assumes that the ID is allways the same as the ID in the HTML. This is
    >>> different from Windows Forms, where the controls may be made private if
    >>> required as the objects are instantiated within the form and do not need
    >>> to be set from an external object.
    >>>
    >>> 2.) Because of 1.) Non private access modifier are required.
    >>>
    >>> I hope I have understood this correctly; I look forward to being
    >>> corrected or otherwise.
    >>>
    >>>
    >>> Many Thanks - Mr Newbie . . .
    >>>
    >>>
    >>>
    >>>
    >>>

    >>
    >>

    >
    >
     
    Kevin Spencer, Oct 31, 2005
    #4
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Mark Kamoski
    Replies:
    1
    Views:
    2,758
    Herfried K. Wagner
    Jul 23, 2003
  2. =?Utf-8?B?YWppdA==?=

    access modifier for webcontrols

    =?Utf-8?B?YWppdA==?=, Nov 17, 2004, in forum: ASP .Net
    Replies:
    1
    Views:
    371
    Eliahu
    Nov 17, 2004
  3. Stephen

    Protected access modifier in Struct

    Stephen, Apr 6, 2006, in forum: ASP .Net
    Replies:
    2
    Views:
    402
    Stephen
    Apr 7, 2006
  4. dost
    Replies:
    5
    Views:
    1,169
    Phlip
    Apr 28, 2006
  5. Ron

    Web Services - Internal Access Modifier

    Ron, Jul 14, 2003, in forum: ASP .Net Web Services
    Replies:
    0
    Views:
    137
Loading...

Share This Page