Web Controls/User Controls - Access Modifier

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 . . .> 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" <here@.now.com> wrote in message
news:utXMRKg3FHA.472@.TK2MSFTNGP15.phx.gbl...
>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 . . .
>
>
>
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" <kevin@.DIESPAMMERSDIEtakempis.com> wrote in message
news:ur5nnvh3FHA.1596@.tk2msftngp13.phx.gbl...
> Correct.
>
> 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" <here@.now.com> wrote in message
> news:utXMRKg3FHA.472@.TK2MSFTNGP15.phx.gbl...
>
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" <here@.now.com> wrote in message
news:ebT6wAi3FHA.400@.TK2MSFTNGP09.phx.gbl...
> 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" <kevin@.DIESPAMMERSDIEtakempis.com> wrote in message
> news:ur5nnvh3FHA.1596@.tk2msftngp13.phx.gbl...
>