Protected or Public ?

[Paperback Writer]

I have 30 textBox in my UserControl...they are with PROTECTED modifier.
But i need to access these TextBox throught my WebForm...
What is the best way to access them ? leaving PROTECTED and creating publics
properties or Leaving de objects publics ?

--
Please, check my theSpoke:
http://www.thespoke.net/MyBlog/dgroh/MyBlog.aspx

[Nicholas Paldino [.NET/C# MVP]]

Paperback Writer

If you want them exposed from the control, then you want to expose them
as public, or internal (if they are hosted in the same assembly), that is
the only way you will be able to access them directly from the page the user
control is on.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Paperback Writer" <ne*********@gmail.com> wrote in message
news:O2*************@TK2MSFTNGP15.phx.gbl...

I have 30 textBox in my UserControl...they are with PROTECTED modifier.
But i need to access these TextBox throught my WebForm...
What is the best way to access them ? leaving PROTECTED and creating
publics properties or Leaving de objects publics ?

--
Please, check my theSpoke:
http://www.thespoke.net/MyBlog/dgroh/MyBlog.aspx

[garethdjames]

You can expose them via public properties, this method is much better
because when you change the textBox from protected to public, visual
studio designer wil change them back,

If you are not using VS then its not a problem,

by the way this is fixed in VS 2005

[Bruce Wood]

You should avoid exposing controls within your user control as public
members. I almost wrote "You should never expose..." but I'm not
feeling that cocky.

The way to handle this problem (and it's a common one), is to think
about the user control as a whole. Obviously, it has 30 text boxes for
a reason. What is the sum functionality of the entire user control? Is
it, for example, an application form?

Assuming that it's an application form (for the sake of argument), then
you don't _really_ want to be able to get at the text boxes. What you
_really_ want is to get at the information on the form. So, you could
do that by exposing one public property for each item on the form:

public string LastName
{
get { return this.txtLastName.Text; }
set { this.txtLastName.Text = value; }
}

Or, you could create a class that would hold all of the application
information, and expose a single property:

public ApplicationInformation ApplicationInformation
{
get { return new ApplicationInformation(this.txtLastName.Text, ...
); }
set
{
this.txtLastName.Text = value.LastName;
...
}
}

Either way, what you've done is expose properties that "talk in the
language of" your user control as a whole. This does two very good
things: 1) it makes the calling code more readable, because callers can
now write code in terms of what the user control does, not in terms of
how it's put together, and 2) it makes the calling code ignorant of the
structure of your user control (loose coupling), so that you can
change, for example, a radio button group to a combo box if that makes
more sense from an interface point of view... all without changing any
calling code. The less your calling code knows about the guts of your
user control, the better.

You can do this with events, too (which is also common). WIthin your
user control you subcribe to events from the text boxes, and then in
the event handler you raise an event particular to the user control.
For example:

this.userControl.ApplicationInformationChanged += new
System.EventHandler(...);

and then inside your user control:

this.txtLastName.TextChanged += new
System.EventHandler(this.txtLastName_TextChanged);
.... etc ...
private void txtLastName_TextChanged(System.EventArgs ea)
{
OnApplicationInformationChanged();
}
.... etc ...
protected void OnApplicationInformationChanged()
{
if (ApplicationInformationChanged != null)
{
ApplicationInformationChanged(System.EventArgs.Emp ty);
}
}

Again, this isolates your caller from knowing about the controls within
your user control, and creates events that are meaningful at the level
of the user control rather than events that depend upon how the user
control is constructed.

[garethdjames]

Bruce, that was extreemly good advice, but the question was "how do I
expose", not "should I expose".

I do agree with everything you have said but sometimes it can be an
overkill to do it the way you explain.

It would be great if everything could be programmed the correct way all
of the time, but sometimes its just not feasable.

I believe that the whole point of control (aka component) architecture
of ASP.net is often not understood, but sometimes this is just to much
to take in for new ASP.net developers.

I hope I have not flamed you here, as I said before I agree with
everything you said

[Kim Quigley]

Was your question resolved? It looks like Bruce gave you a C# example of how
to expose properties in a user control. Here is the VB code to expose a
textbox which would allow you, for example, to change its css class,
visibility, text, etc. If you only need to work with the text, then you
could expose it as a string and return me.fname.text instead.

(Sorry if you already have your answer and this isn't relevant anymore.
Hopefully it will at least help someone else.)

Public Property FirstName() As TextBox
Get
Return Me.fname
End Get
Set(ByVal Value As TextBox)
Me.fname= Value
End Set
End Property
<ga**********@gmail.com> wrote in message
news:11**********************@o13g2000cwo.googlegr oups.com...

Bruce, that was extreemly good advice, but the question was "how do I
expose", not "should I expose".

I do agree with everything you have said but sometimes it can be an
overkill to do it the way you explain.

It would be great if everything could be programmed the correct way all
of the time, but sometimes its just not feasable.

I believe that the whole point of control (aka component) architecture
of ASP.net is often not understood, but sometimes this is just to much
to take in for new ASP.net developers.

I hope I have not flamed you here, as I said before I agree with
everything you said

[louise raisbeck]

Hi there, I found your post really helpful..but i wondered if, once I have
exposed a public property containing the value of a textbox in a user
control..how do I grab this from the calling page? I cant think of the
syntax, since my page doesnt know the contents of the class (and therefore,
the public properties) of the user control??

Sorry if its blatently obvious!

I am currently getting a value using
Page.FindControl(usercontrol);usercontrol.FindCont rol...etc etc and am told
this is much slower than the public property route.

Many Thanks, Louise.

"Bruce Wood" wrote:

You should avoid exposing controls within your user control as public
members. I almost wrote "You should never expose..." but I'm not
feeling that cocky.

The way to handle this problem (and it's a common one), is to think
about the user control as a whole. Obviously, it has 30 text boxes for
a reason. What is the sum functionality of the entire user control? Is
it, for example, an application form?

Assuming that it's an application form (for the sake of argument), then
you don't _really_ want to be able to get at the text boxes. What you
_really_ want is to get at the information on the form. So, you could
do that by exposing one public property for each item on the form:

public string LastName
{
get { return this.txtLastName.Text; }
set { this.txtLastName.Text = value; }
}

Or, you could create a class that would hold all of the application
information, and expose a single property:

public ApplicationInformation ApplicationInformation
{
get { return new ApplicationInformation(this.txtLastName.Text, ...
); }
set
{
this.txtLastName.Text = value.LastName;
...
}
}

Either way, what you've done is expose properties that "talk in the
language of" your user control as a whole. This does two very good
things: 1) it makes the calling code more readable, because callers can
now write code in terms of what the user control does, not in terms of
how it's put together, and 2) it makes the calling code ignorant of the
structure of your user control (loose coupling), so that you can
change, for example, a radio button group to a combo box if that makes
more sense from an interface point of view... all without changing any
calling code. The less your calling code knows about the guts of your
user control, the better.

You can do this with events, too (which is also common). WIthin your
user control you subcribe to events from the text boxes, and then in
the event handler you raise an event particular to the user control.
For example:

this.userControl.ApplicationInformationChanged += new
System.EventHandler(...);

and then inside your user control:

this.txtLastName.TextChanged += new
System.EventHandler(this.txtLastName_TextChanged);
.... etc ...
private void txtLastName_TextChanged(System.EventArgs ea)
{
OnApplicationInformationChanged();
}
.... etc ...
protected void OnApplicationInformationChanged()
{
if (ApplicationInformationChanged != null)
{
ApplicationInformationChanged(System.EventArgs.Emp ty);
}
}

Again, this isolates your caller from knowing about the controls within
your user control, and creates events that are meaningful at the level
of the user control rather than events that depend upon how the user
control is constructed.