Events with no arguments?

[2obvious]

I'm trying to wrap my mind around writing reusable event handlers.

Say I have a textbox control. In the OnTextChanged event handler of
this textbox control, I want to call a subroutine that does something
to another control (a label control, in this pseudo example):

<asp:textBox id="txt1" OnTextChanged="txtFunction1" ... />

sub txtFunction(sender as Object, e as EventArgs)
lblAnotherControl.Text = "blah"
end sub

But say I want to use this same subroutine on a different textbox
control to affect a different (label) control. My experience tells me
I want to pass the subroutine some arguments. But that doesn't seem to
be an option with ASP.NET. In ASP.NET, it seems my only recourse is to
write a new subroutine for each event handler, regardless of how
similar each subroutine may be. Since this is contrary to the concepts
of modularity and code reuse, I figure I must be interpreting things
wrong.

Can someone please explain to me how .NET takes on situations like the
one in my example, or how it provides a different approach that
circumvents such questions (if it does)?

 

[John Saunders]

I'm trying to wrap my mind around writing reusable event handlers.

Say I have a textbox control. In the OnTextChanged event handler of
this textbox control, I want to call a subroutine that does something
to another control (a label control, in this pseudo example):

<asp:textBox id="txt1" OnTextChanged="txtFunction1" ... />

sub txtFunction(sender as Object, e as EventArgs)
lblAnotherControl.Text = "blah"
end sub

But say I want to use this same subroutine on a different textbox
control to affect a different (label) control. My experience tells me
I want to pass the subroutine some arguments. But that doesn't seem to
be an option with ASP.NET. In ASP.NET, it seems my only recourse is to
write a new subroutine for each event handler, regardless of how
similar each subroutine may be. Since this is contrary to the concepts
of modularity and code reuse, I figure I must be interpreting things
wrong.

Can someone please explain to me how .NET takes on situations like the
one in my example, or how it provides a different approach that
circumvents such questions (if it does)?

You don't need a new handler for each control. The sender parameter is a
reference to the object which raised the event. So, if you know the event
handler is only used with text boxes, but is used with different ones, you
can use:

Sub txtFunction(sender As Object, e As EventArgs)
Dim txt As TextBox = DirectCast(sender, TextBox)
lblAnotherControl.Text = txt.Text
End Sub


John Saunders

 

[2obvious]

Pardon my example. I should have used the sender parameter to clarify
that that wasn't my point of confusion. Let's take this last example
and roll with it:

Sub txtFunction(sender As Object, e As EventArgs)
Dim txt As TextBox = DirectCast(sender, TextBox)
lblAnotherControl.Text = txt.Text
End Sub

Okay, now I can use this subroutine with any textbox control. But it
always affects the same label control. There's my problem. I can't
pass an argument to specify which label control I want to affect.

 

[John Saunders]

Pardon my example. I should have used the sender parameter to clarify
that that wasn't my point of confusion. Let's take this last example
and roll with it:

Sub txtFunction(sender As Object, e As EventArgs)
Dim txt As TextBox = DirectCast(sender, TextBox)
lblAnotherControl.Text = txt.Text
End Sub

Okay, now I can use this subroutine with any textbox control. But it
always affects the same label control. There's my problem. I can't
pass an argument to specify which label control I want to affect.

That's quite correct. The sending control can't send to your page any extra
information that comes originally from your page.

So, why not keep all that information in your page? Create a Hashtable which
associates the textbox and the label:

Dim txt As TextBox = DirectCast(sender, TextBox)
Dim lbl As Label = DirectCast(textBoxToLabel(txt), Label)
lbl.Text = txt.Text

John Saunders

 

[2obvious]

This hashtable approach only works if you know the IDs of all the
labels and textboxes in advance.

In a situation where controls are generated on the fly--say they occur
inside a datagrid control--IDs will not be known.

That being the case, I think some variation of this hashtable approach
will solve my problem. (I just needed someone to lend me a different
perspective on approaching the problem--thanks, John!). But overall,
I'm still baffled by the decision to exclude parameters in events
handlers. I point out the datagrid exception to show that there still
holes.

 

[John Saunders]

This hashtable approach only works if you know the IDs of all the
labels and textboxes in advance.

Sorry, no. I didn't say to use the IDs. I said to use the references. Use
the exact code I gave you, and you're all set.

In a situation where controls are generated on the fly--say they occur
inside a datagrid control--IDs will not be known.

That being the case, I think some variation of this hashtable approach
will solve my problem. (I just needed someone to lend me a different
perspective on approaching the problem--thanks, John!). But overall,
I'm still baffled by the decision to exclude parameters in events
handlers. I point out the datagrid exception to show that there still
holes.

You're still looking for strings. The sender parameter is all you'll ever
need.

John Saunders

 

[2obvious]

Sorry, no. I didn't say to use the IDs. I said to use the references.

To make a reference to an object, I /will/ need to know its ID.

My example textbox from before?

<asp:textBox id="txt1" ... />

To make a reference to it, one would do something like this:

Dim objTxtReference As TextBox = txt1

--Can't identify something without an ID.

Use the exact code I gave you, and you're all set.

Well, first I would have to create a textBoxToLabel() function that
takes a textbox object as an argument and returns a label object. You
never did provide an implementation for this--and I'm not asking you
to, you've been a tremendous help with just the pseudocode. But since
implementation /was/ left up to me, the fastest way I can think of
building this hashtable is with a two-dimensional array that references
objects using
the method I describe above. Meaning I /will/ need to know the IDs in
advance--stop me if I'm wrong.

 

[John Saunders]

To make a reference to an object, I /will/ need to know its ID.

No, actually you won't need the id.

My example textbox from before?

<asp:textBox id="txt1" ... />

To make a reference to it, one would do something like this:

Dim objTxtReference As TextBox = txt1

--Can't identify something without an ID.

In your codebehind, "txt1" is not the ID. It's the name of a variable of
type TextBox.

Well, first I would have to create a textBoxToLabel() function that
takes a textbox object as an argument and returns a label object.

Well, no, actually all you'll need to do is

DirectCast(textBoxToLabel(txt), Label)

textBoxToLabel is not a function. "textBoxToLabel" was meant to be the
Hashtable I was talking about. Sorry that wasn't clear. The idea is that you
would fill the Hashtable in your Page_Load or somewhere, with the
association between the text boxes and the labels you wanted to associate
with them. For instance:

Private textBoxToLabel As New Hashtable()
....
Sub Page_Load(sender As Object, e As EventArgs)
textBoxToLabel(textBox1) = label1
textBoxToLabel(textBox2) = label2
textBoxToLabel(textBox3) = label1 ' No reason you can't duplicate
these
End Sub

Sub CommonEventHandler(sender As Object, e As EventArgs)
Dim txt As TextBox = DirectCast(sender, TextBox)
Dim lbl As Label = DirectCast(textBoxToLabel(txt), Label)
lbl.Text = txt.Text
End Sub


John Saunders