Calling a handler


D

Dom

I have a handler for the KeyDown event on a textbox --
txtRecNo_KeyDown (object sender, KeyEventArgs e). The code for this
handler will capture the "Enter" key and then execute code. This is
the usual behavior of the Enter Key to most users.

Now, there are times when the user wants to doubleclick in a listview
box, and place that Record in txtRecNo, and then proceed like an Enter
Key has been pressed. I do the following:

ListViewItem m = lvwHistory.SelectedItems[0];
txtRecNo.Text = m.SubItems[lvwHistory_RecNo.Index].Text;
KeyEventArgs a = new KeyEventArgs(Keys.Enter);
txtRecNo_KeyDown(txtRecNo, a);

In my "C" days (not even C++, just C), this was bad form. You never
called a handler in code. The way around it was to use a subroutine
in txtRecNo_KeyDown, and then call this when needed. The problem was
that you were handling a message that was never sent by the system.

Yet I see this sort of thing in examples published on the web at sites
that seem to be knowledgable. Is it acceptable in C-Sharp?

Dom
 
Ad

Advertisements

J

Jeff Johnson

I have a handler for the KeyDown event on a textbox --
txtRecNo_KeyDown (object sender, KeyEventArgs e). The code for this
handler will capture the "Enter" key and then execute code. This is
the usual behavior of the Enter Key to most users.

Now, there are times when the user wants to doubleclick in a listview
box, and place that Record in txtRecNo, and then proceed like an Enter
Key has been pressed. I do the following:

ListViewItem m = lvwHistory.SelectedItems[0];
txtRecNo.Text = m.SubItems[lvwHistory_RecNo.Index].Text;
KeyEventArgs a = new KeyEventArgs(Keys.Enter);
txtRecNo_KeyDown(txtRecNo, a);

In my "C" days (not even C++, just C), this was bad form. You never
called a handler in code. The way around it was to use a subroutine
in txtRecNo_KeyDown, and then call this when needed. The problem was
that you were handling a message that was never sent by the system.

Yet I see this sort of thing in examples published on the web at sites
that seem to be knowledgable. Is it acceptable in C-Sharp?

At the end of the day, event handlers are just methods, so there is nothing
TECHNICALLY wrong with calling them directly. That said, from what I've
seen, most people (or at least most of the people who are vocal about it)
are of the opinion that calling a handler directly is bad form, and that you
should be doing exactly what you described: make a separate, "normal" method
and call that method from both the handler and anywhere else in the code
where you need it.

Bottom line: either way will work. What you're worried about now is how
other people will "grade" you.
 
A

Arne Vajhøj

I have a handler for the KeyDown event on a textbox --
txtRecNo_KeyDown (object sender, KeyEventArgs e). The code for this
handler will capture the "Enter" key and then execute code. This is
the usual behavior of the Enter Key to most users.

Now, there are times when the user wants to doubleclick in a listview
box, and place that Record in txtRecNo, and then proceed like an Enter
Key has been pressed. I do the following:

ListViewItem m = lvwHistory.SelectedItems[0];
txtRecNo.Text = m.SubItems[lvwHistory_RecNo.Index].Text;
KeyEventArgs a = new KeyEventArgs(Keys.Enter);
txtRecNo_KeyDown(txtRecNo, a);

In my "C" days (not even C++, just C), this was bad form. You never
called a handler in code. The way around it was to use a subroutine
in txtRecNo_KeyDown, and then call this when needed. The problem was
that you were handling a message that was never sent by the system.

Yet I see this sort of thing in examples published on the web at sites
that seem to be knowledgable. Is it acceptable in C-Sharp?

If it is guaranteed to work then it can be acceptable.

Whether it actually is acceptable depends on the specific
coding conventions used where you work.

If you ask me whether the coding convention should
allow it then I would say no. Setting up a fake
event arg and call the handler explicit is a code smell
in my opinion.

Arne
 
D

Dom

I have a handler for the KeyDown event on a textbox --
txtRecNo_KeyDown (object sender, KeyEventArgs e).  The code for this
handler will capture the "Enter" key and then execute code.  This is
the usual behavior of the Enter Key to most users.
Now, there are times when the user wants to doubleclick in a listview
box, and place that Record in txtRecNo, and then proceed like an Enter
Key has been pressed.  I do the following:
             ListViewItem m = lvwHistory.SelectedItems[0];
             txtRecNo.Text = m.SubItems[lvwHistory_RecNo.Index].Text;
             KeyEventArgs a = new KeyEventArgs(Keys.Enter);
             txtRecNo_KeyDown(txtRecNo, a);
In my "C" days (not even C++, just C), this was bad form.  You never
called a handler in code.  The way around it was to use a subroutine
in txtRecNo_KeyDown, and then call this when needed.  The problem was
that you were handling a message that was never sent by the system.
Yet I see this sort of thing in examples published on the web at sites
that seem to be knowledgable.  Is it acceptable in C-Sharp?

If it is guaranteed to work then it can be acceptable.

Whether it actually is acceptable depends on the specific
coding conventions used where you work.

If you ask me whether the coding convention should
allow it then I would say no. Setting up a fake
event arg and call the handler explicit is a code smell
in my opinion.

Arne

So I take it the answer is, don't do it. Sounds about right.
 
Ad

Advertisements

A

Arne Vajhøj

I have a handler for the KeyDown event on a textbox --
txtRecNo_KeyDown (object sender, KeyEventArgs e). The code for this
handler will capture the "Enter" key and then execute code. This is
the usual behavior of the Enter Key to most users.
Now, there are times when the user wants to doubleclick in a listview
box, and place that Record in txtRecNo, and then proceed like an Enter
Key has been pressed. I do the following:
ListViewItem m = lvwHistory.SelectedItems[0];
txtRecNo.Text = m.SubItems[lvwHistory_RecNo.Index].Text;
KeyEventArgs a = new KeyEventArgs(Keys.Enter);
txtRecNo_KeyDown(txtRecNo, a);
In my "C" days (not even C++, just C), this was bad form. You never
called a handler in code. The way around it was to use a subroutine
in txtRecNo_KeyDown, and then call this when needed. The problem was
that you were handling a message that was never sent by the system.
Yet I see this sort of thing in examples published on the web at sites
that seem to be knowledgable. Is it acceptable in C-Sharp?

If it is guaranteed to work then it can be acceptable.

Whether it actually is acceptable depends on the specific
coding conventions used where you work.

If you ask me whether the coding convention should
allow it then I would say no. Setting up a fake
event arg and call the handler explicit is a code smell
in my opinion.

So I take it the answer is, don't do it. Sounds about right.

I am saying:

existing code using it => continue using it
existing code not using it => don't start using it
no existing code => don't start using it

Arne
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top