Web Controls/User Controls - Access Modifier

[Mr Newbie]

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]

> 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" <he**@now.com> wrote in message
news:ut*************@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 . . .

[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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:ur**************@tk2msftngp13.phx.gbl...

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" <he**@now.com> wrote in message
news:ut*************@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 . . .

[Kevin Spencer]

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" <he**@now.com> wrote in message
news:eb*************@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" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:ur**************@tk2msftngp13.phx.gbl...

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" <he**@now.com> wrote in message
news:ut*************@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 . . .