Can a UserControl perform some action on the hosting page codebehind?

[Benton]

Hi there,

I have a UserControl with a couple of textboxes and a couple of buttons
("Save" and "Cancel"). The Click event for this buttons is in the
UserControl's codebehind of course, so here's my question.

Once the UserControl is dropped onto the container page, how can I perform
some action on the codebehind of the container page from the codebehind of
the UserControl? For instance, suppose that the UserControl is dropped
inside one of the Views of a Multiview control on the container page. By
clicking the "Cancel" button of the UserControl, I would like to change the
active view of the container page's Multiview control.

How can this be done in ASP.NET 2.0?

Thanks in advance,

-Benton

 

[wfairl]

I would suggest using a custom event from the UserControl (eg
Cancelled) and subscribing to it in the Page. It will then be up to the
page to handle the event (switch active views).

 

[Brennan Stehling]

Benton,

It sounds like you want the Page to tell the User Control to do
something, or to at least set a value it can use.

What I do is create a public property on User Controls. That exposes a
value I can set for behavior. Then in the Load or even PreRender event
handler for the User Control you can use that property to control
behavior.

What I would not do is set up a method on the User Control because this
is an event driven model. You will want to stay in that event driven
model and let the User Control respond to properties as you do with
controls like TextBox and ListBox. You just adjust properties on those
controls as well.

Brennan Stehling
http://brennan.offwhite.net/blog/

 

[Benton]

It sounds like you want the Page to tell the User Control to do

something, or to at least set a value it can use.

Actually it's the opposite: I want the UserControl to tell its container
page to do something when "something happens" in the UserControl itself,
i.e., the container page should switch the active view when a button is
clicked on the UserControl.

Thanks for any hint,

-Benton

 

[Benton]

I would suggest using a custom event from the UserControl (eg

Cancelled) and subscribing to it in the Page. It will then be up to the
page to handle the event (switch active views).

Sounds very promising, thank you. Can you please provide me with some code
sample to get me started?

Thanks in advance,

-Benton

 

[Benton]

I would suggest using a custom event from the UserControl (eg

Cancelled) and subscribing to it in the Page. It will then be up to the
page to handle the event (switch active views).

Thanks for the idea. I investigated events and finally accomplished what I
was looking for. This article was invaluable:
http://www.csharphelp.com/archives/archive253.html

Again, thanks a million for the help.

Regards,

-Benton

 

[kferron]

The best practices way is to override the OnBubbleEvent on the hosting
page.

In your UserControl, you have it contain its events. When an event
occurs, lets say in your ItemCommand eventhandler on the usercontrol,
you call RaiseBubbleEvent(source,e).

This will pass the event properly up the chain without your hosting
page needing to know anything about the specific user control.


Kevin Ferron

 

[Brennan Stehling]

Here is what I would do to add event handling support.

I tried the OnBubbleEvent once but it was just counter-intuitive for
object oriented coding. I prefer defining an event with a good name
which makes sense the the subscriber. I also like how it gives you
Intellisense support. Now I simply add events to my child controls and
subscribe to them.

public event CancelEventHandler ChangingThing;
public event EventHandler ChangedThing;

There is a lot of ways you can define events now, but I like the above
syntax the best. The first one is called before change and the second
one after. The first one uses the CancelEventHandler. Then the
convention is to create a method like the one below to trigger the
event.

protected virtual void ChangingThing(CancelEventArgs e)
{
if (SendingMail != null)
{
SendingMail(this, e);
}
}

Where it is called, you will do this.

CancelEventArgs args = new CancelEventArgs();
OnChangingThing(args);
if (!args.Cancel)
{
// do stuff
OnChangedThing(EventArgs.Empty);
}

This way you can have the event prevent an action from taking place. I
did this for a contact form control. The full source is here...

http://svn.offwhite.net/svn/SmallSh...k/ClassLibrary/Web/UI/Controls/ContactForm.cs

Brennan Stehling
http://brennan.offwhite.net/blog/

 

[kferron]

hey i like what you're saying, but i disagree with you in a lot of
asp.net scenarios, and the reason is that bubbling events is a really
key lever that asp.net provides for you for navigating the event model
gracefully, and if you're not taking advantage of it, odds are, your
asp.net code ends up doing a lot to compensate for control order
execution, which is critical domain because in the web, you can be
frequently rendering the same page in different orders depending on
many scenarios.

bubbling events offers distinct ways in the context of asp.net that are
advantageous beyond that of custom events, in which you have some
immediate and direct control over the execution flow of your various
webcontrols that are also performing their duties.. the situation that
occurs in a poorly written asp.net application is that by bringing a
control into a page, you break the existing page because of event
wiring issues. the costs of continually rewiring events to subscribers
leads me to believe this isn't getting us anywhere closer to the goal
of reducing headache.

anyway, im rambling, but i do think this is a principle that you should
at least spend some time thinking about, if you were interested in
hearing more about why i think you've overlooked something important
about asp.net, this is from msdn: "Event bubbling ensures that the
event handlers for all elements in which an event occurs have an
opportunity to respond to the event"

 

[Brennan Stehling]

kferron,

I do not see what is wrong with making a parent control subscribe to a
named event on the child control. By just capturing bubbled events you
will not have the same relationship set up between the controls. If
the child control has a button click event rise to the parent control,
do you react based on the CommandName and CommandArgument? How do you
handle the context? (btw, your link did not make it through the news
reader)

I am sure there is sufficient reason to use either approach. But I do
think bubbling between a Page and User Control is where I would not
apply the bubbling approach. In the case of a complex templated server
control, like a GridView, I can see how you would have a button in an
individual templated cell allow the event to bubble up to a parent
where it would capture it and raise the RowCommand event. In this way
you use both named events and bubbling in a very smart way so you do
not have to set up all of those subscribers, but still give the user of
this control a robust interface.

Having a User Control bubble up events which may be used across
multiple pages seems to create relationships which are difficult to
manage which would get out the line quickly.

Perhaps in the future when I create a complex server control I will
internally bubble events and wrap them with my named events. I do not
know if that is how the GridView actually works, but it seems like a
reasonable approach to me.

Brennan Stehling
http://brennan.offwhite.net/blog/
ASP.NET JAD (Just Another Developer)

 

[kferron]

Brennan,

if you use bubbling, you can put a UserControl in another UserControl
and still ensure the firing all the way up (or down) the chain. This
would happen without any of the usercontrols along the chain knowing
anything about each other.

although your first point is valid, the typical approach is to
implement a command factory that actually knows how to interpret the
commands (building the command concrete types based on commandname and
commandargument), and then having your Page class execute the command,
without actually knowing the details.

certainly both approaches can make sense, and even in combination, and
i didnt mean to come across as bubbling was always the correct
mechanism to utilize!

have a good one

kferron