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

"Dom" <(E-Mail Removed)> wrote in message
news:de78d88a-1789-42aa-be82-(E-Mail Removed)...

>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.

On 12/6/2011 12:57 PM, Dom wrote:
> 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

On Dec 6, 6:36*pm, Arne Vajhøj <a...@vajhoej.dk> wrote:
> On 12/6/2011 12:57 PM, Dom wrote:
>
>
>
>
>
>
>
>
>
> > 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.

On 12/6/2011 7:28 PM, Dom wrote:
> On Dec 6, 6:36 pm, Arne Vajhøj<a...@vajhoej.dk> wrote:
>> On 12/6/2011 12:57 PM, Dom wrote:
>>> 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