Grab value from public variable in user control

[louise raisbeck]

Resending this as own topic as didnt get answer from original. Would be
grateful for a response from anyone that knows. Thanks.

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.

Was this post helpful to you?

Why should I rate a post?


Manage Your Profile |Legal |Contact Us |MSDN Flash Newsletter
© 2005 Microsoft Corporation. All rights reserved. Terms of Use |Trademarks
|Privacy Statement

[Karl Seguin]

I might have shamelessly plugged this in the original, but take a look at:
http://openmymind.net/index.aspx?documentId=9

basically you would cast the Control returned by FindControl to the specific
control type..

MyUserControl c = (MyUserControl)Page.FindControl("someId")

int x = c.MyProperty;

of course, if the control is placed on the page, why do you need to do a
FindControl? it should be a member like a textbox or any other control...

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is
annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)
"louise raisbeck" <lo************@discussions.microsoft.com> wrote in
message news:73**********************************@microsof t.com...

Resending this as own topic as didnt get answer from original. Would be
grateful for a response from anyone that knows. Thanks.

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.

Was this post helpful to you?

Why should I rate a post?


Manage Your Profile |Legal |Contact Us |MSDN Flash Newsletter
© 2005 Microsoft Corporation. All rights reserved. Terms of Use
|Trademarks
|Privacy Statement

[louise raisbeck]

Thanks Karl. I know what you are saying but am still confused - the
properties of a control such as a TextBox return standard properties for the
object such as ID, public properties that i set up myself. If I do this:

protected UserControl DirectNav1; (DirectNav1 being the name i have given it
in the aspx page)

protected void Page_Load(Object sender, System.EventArgs e)
{
intSID = DirectNav1.intStatusID;
}

it says intStatusID isnt a property of UserControl. I do not understand how
my page will know the contents of the class of my user control.??? what part
of this process am I not understanding?

"Karl Seguin" wrote:

I might have shamelessly plugged this in the original, but take a look at:
http://openmymind.net/index.aspx?documentId=9

basically you would cast the Control returned by FindControl to the specific
control type..

MyUserControl c = (MyUserControl)Page.FindControl("someId")

int x = c.MyProperty;

of course, if the control is placed on the page, why do you need to do a
FindControl? it should be a member like a textbox or any other control...

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is
annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)
"louise raisbeck" <lo************@discussions.microsoft.com> wrote in
message news:73**********************************@microsof t.com...

Resending this as own topic as didnt get answer from original. Would be
grateful for a response from anyone that knows. Thanks.

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.

Was this post helpful to you?

Why should I rate a post?


Manage Your Profile |Legal |Contact Us |MSDN Flash Newsletter
© 2005 Microsoft Corporation. All rights reserved. Terms of Use
|Trademarks
|Privacy Statement

[Karl Seguin]

Louise:
You are saying that DirectNav1 is of type UserControl in your decleration
(protected USERCONTROL DirectNav1)

In reality, DirectNav1 is something more specific, not sure what you called
it, but maybe DirectNav...if you open the user control's codebehind, you'll
see something like

public class DirectNav : UserControl{
public int intStatusId{get { ... } set { ... } }
...
}

UserControl doesn't have a property named intStatusId, but DirectNav does,
so if you change your declaration to be:

protected DirectNav DirectNav1;

then all should be good.

Karl
--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is
annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)
"louise raisbeck" <lo************@discussions.microsoft.com> wrote in
message news:70**********************************@microsof t.com...

Thanks Karl. I know what you are saying but am still confused - the
properties of a control such as a TextBox return standard properties for
the
object such as ID, public properties that i set up myself. If I do this:

protected UserControl DirectNav1; (DirectNav1 being the name i have given
it
in the aspx page)

protected void Page_Load(Object sender, System.EventArgs e)
{
intSID = DirectNav1.intStatusID;
}

it says intStatusID isnt a property of UserControl. I do not understand
how
my page will know the contents of the class of my user control.??? what
part
of this process am I not understanding?

"Karl Seguin" wrote:

I might have shamelessly plugged this in the original, but take a look
at:
http://openmymind.net/index.aspx?documentId=9

basically you would cast the Control returned by FindControl to the
specific
control type..

MyUserControl c = (MyUserControl)Page.FindControl("someId")

int x = c.MyProperty;

of course, if the control is placed on the page, why do you need to do a
FindControl? it should be a member like a textbox or any other
control...

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is
annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)
"louise raisbeck" <lo************@discussions.microsoft.com> wrote in
message news:73**********************************@microsof t.com...

> Resending this as own topic as didnt get answer from original. Would be
> grateful for a response from anyone that knows. Thanks.
>
> 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.
>>
>>
> Was this post helpful to you?
>
> Why should I rate a post?
>
>
>
>
>
>
> Manage Your Profile |Legal |Contact Us |MSDN Flash Newsletter
> © 2005 Microsoft Corporation. All rights reserved. Terms of Use
> |Trademarks
> |Privacy Statement
>

[louise raisbeck]

It was staring me in the face! Its not until someone points it out and it all
becomes clear! Thanks much appreciated :o)

"Karl Seguin" wrote:

Louise:
You are saying that DirectNav1 is of type UserControl in your decleration
(protected USERCONTROL DirectNav1)

In reality, DirectNav1 is something more specific, not sure what you called
it, but maybe DirectNav...if you open the user control's codebehind, you'll
see something like

public class DirectNav : UserControl{
public int intStatusId{get { ... } set { ... } }
...
}

UserControl doesn't have a property named intStatusId, but DirectNav does,
so if you change your declaration to be:

protected DirectNav DirectNav1;

then all should be good.

Karl
--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is
annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)
"louise raisbeck" <lo************@discussions.microsoft.com> wrote in
message news:70**********************************@microsof t.com...

Thanks Karl. I know what you are saying but am still confused - the
properties of a control such as a TextBox return standard properties for
the
object such as ID, public properties that i set up myself. If I do this:

protected UserControl DirectNav1; (DirectNav1 being the name i have given
it
in the aspx page)

protected void Page_Load(Object sender, System.EventArgs e)
{
intSID = DirectNav1.intStatusID;
}

it says intStatusID isnt a property of UserControl. I do not understand
how
my page will know the contents of the class of my user control.??? what
part
of this process am I not understanding?

"Karl Seguin" wrote:

I might have shamelessly plugged this in the original, but take a look
at:
http://openmymind.net/index.aspx?documentId=9

basically you would cast the Control returned by FindControl to the
specific
control type..

MyUserControl c = (MyUserControl)Page.FindControl("someId")

int x = c.MyProperty;

of course, if the control is placed on the page, why do you need to do a
FindControl? it should be a member like a textbox or any other
control...

Karl

--
MY ASP.Net tutorials
http://www.openmymind.net/ - New and Improved (yes, the popup is
annoying)
http://www.openmymind.net/faq.aspx - unofficial newsgroup FAQ (more to
come!)
"louise raisbeck" <lo************@discussions.microsoft.com> wrote in
message news:73**********************************@microsof t.com...
> Resending this as own topic as didnt get answer from original. Would be
> grateful for a response from anyone that knows. Thanks.
>
> 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.
>>
>>
> Was this post helpful to you?
>
> Why should I rate a post?
>
>
>
>
>
>
> Manage Your Profile |Legal |Contact Us |MSDN Flash Newsletter
> © 2005 Microsoft Corporation. All rights reserved. Terms of Use
> |Trademarks
> |Privacy Statement
>