Call an method that is an eventhandler

[jac]

Hae,

I have a windows form with a ComboBox an other things.
On that combobox I have an eventhandler on de selectedindexchanged.

But somewhere in my code want to do excecute the same code that is writen
in the eventhandler.
Is it posible to call that eventhandler from the code (not from a real
selectedindexchanged on the form). So, I don't have to call that code twice.
tkx
jac

[Brendan Grant]

Just to make sure I understand you... somewhere in your code you’ve got
something to the effect of:

this.comboBox1.SelectedIndexChanged += new
System.EventHandler(this.comboBox1_SelectedIndexCh anged);

setting up an EventHandler for when SelectedIndexChanged is fired... and you
are curious if you can call your equivalent of comboBox1_SelectedIndexChanged
on your own? Absolutely!

Two things to take note of... first up, the first argument passed into an
event handler is a reference to the sender... if you are not using this
reference you can simply pass in null, otherwise be sure to pass in a
reference to the ComboBox in question.

Second... EventArgs. Some handlers use them, some don’t, if yours doesn’t
you can pass in null or EventArgs.Empty.

Brendan
"jac" wrote:

Hae,

I have a windows form with a ComboBox an other things.
On that combobox I have an eventhandler on de selectedindexchanged.

But somewhere in my code want to do excecute the same code that is writen
in the eventhandler.
Is it posible to call that eventhandler from the code (not from a real
selectedindexchanged on the form). So, I don't have to call that code twice.
tkx
jac

[Nicholas Paldino [.NET/C# MVP]]

jac,

You could just call the event handler like a normal function.

Or are you saying you want to call all the event handlers attached to
that control? If that is the case, you can't do it, as only objects can
fire their own events.

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"jac" <ja*@discussions.microsoft.com> wrote in message
news:84**********************************@microsof t.com...

Hae,

I have a windows form with a ComboBox an other things.
On that combobox I have an eventhandler on de selectedindexchanged.

But somewhere in my code want to do excecute the same code that is writen
in the eventhandler.
Is it posible to call that eventhandler from the code (not from a real
selectedindexchanged on the form). So, I don't have to call that code
twice.
tkx
jac

[Kai Brinkmann [MSFT]]

Yes, it's possible as long as you provide the expected parameters (usually
sender and EventArgs). However, it would be cleaner to put the relevant code
in a separate method and call that method from within the event handler
rather than putting the code in the event handler itself. That way, you
could simply call that method from anywhere in your code.
--
Kai Brinkmann [MSFT]

Please do not send e-mail directly to this alias. This alias is for
newsgroup purposes only.
This posting is provided "AS IS" with no warranties, and confers no rights.

"jac" <ja*@discussions.microsoft.com> wrote in message
news:84**********************************@microsof t.com...

Hae,

I have a windows form with a ComboBox an other things.
On that combobox I have an eventhandler on de selectedindexchanged.

But somewhere in my code want to do excecute the same code that is writen
in the eventhandler.
Is it posible to call that eventhandler from the code (not from a real
selectedindexchanged on the form). So, I don't have to call that code
twice.
tkx
jac

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

Yes you can, just call combo_selectedindexchanged ( null, null );
cheers,
--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation
"jac" <ja*@discussions.microsoft.com> wrote in message
news:84**********************************@microsof t.com...

Hae,

I have a windows form with a ComboBox an other things.
On that combobox I have an eventhandler on de selectedindexchanged.

But somewhere in my code want to do excecute the same code that is writen
in the eventhandler.
Is it posible to call that eventhandler from the code (not from a real
selectedindexchanged on the form). So, I don't have to call that code
twice.
tkx
jac

[Kevin Spencer]

Generally speaking, and for good design, you should not call an Event
Handler directly. Instead, create a method that the Event Handler can call,
as well as any other method that needs it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.

"jac" <ja*@discussions.microsoft.com> wrote in message
news:84**********************************@microsof t.com...

Hae,

I have a windows form with a ComboBox an other things.
On that combobox I have an eventhandler on de selectedindexchanged.

But somewhere in my code want to do excecute the same code that is writen
in the eventhandler.
Is it posible to call that eventhandler from the code (not from a real
selectedindexchanged on the form). So, I don't have to call that code
twice.
tkx
jac

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,
Why it's not?
An "event handler" is just a method as any other, in the same way that you
can have the same method hooked to more than one controls you can call it
yourself,
IMO that is the reason why the sender parameter is there in the first
place, so the method can have a reference to who called it.

Having another method that both the event handler and your code call to
perform the work do have sense IF the logic is different in any case,
otherwise I can't see how it makes it clearer.You are only removing the
parameters and you end with two methods:

void control_handle( ... )
{
do_the_real_work();
}

void do_the_real_work(){}
IMO that is not clearer at all.
Now, in 2.0 with anonymous methods it's a complete different history, you
can declare the control_handle as a anonymous method and the code will be
clear indeed.
What you folks think about the above?
Do you write two methods like the above?
Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Oc**************@tk2msftngp13.phx.gbl...

Generally speaking, and for good design, you should not call an Event
Handler directly. Instead, create a method that the Event Handler can
call, as well as any other method that needs it.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
Ambiguity has a certain quality to it.

"jac" <ja*@discussions.microsoft.com> wrote in message
news:84**********************************@microsof t.com...

Hae,

I have a windows form with a ComboBox an other things.
On that combobox I have an eventhandler on de selectedindexchanged.

But somewhere in my code want to do excecute the same code that is
writen
in the eventhandler.
Is it posible to call that eventhandler from the code (not from a real
selectedindexchanged on the form). So, I don't have to call that code
twice.
tkx
jac

[Scott Roberts]

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:%2******************@TK2MSFTNGP14.phx.gbl...

IMO that is the reason why the sender parameter is there in the first
place, so the method can have a reference to who called it.
The "sender" parameter is there so you know which *component* fired the
event. This is so that multiple *components* can share a single event
handler.
Having another method that both the event handler and your code call to
perform the work do have sense IF the logic is different in any case,
otherwise I can't see how it makes it clearer.You are only removing the
parameters and you end with two methods:

void control_handle( ... )
{
do_the_real_work();
}

void do_the_real_work(){}
IMO that is not clearer at all.
IMO, you should never code "real work" in an event handler - period. All
"real work" belongs in a method that is not inside the GUI in the first
place.
What you folks think about the above?
Do you write two methods like the above?

Yes. Two methods.

[Jon Skeet [C# MVP]]

Scott Roberts wrote:

<snip>

IMO, you should never code "real work" in an event handler - period. All
"real work" belongs in a method that is not inside the GUI in the first
place.

You're making three assumptions which may be invalid:

1) That the event being handled is a GUI event
2) That the real work is not GUI work (if it's GUI work, it's
reasonable for it to be done in the GUI code)
3) That the event handler is defined in GUI code (it may not be,
even if it happens to be hooked up to a GUI event)

Jon

[Scott Roberts]

"Jon Skeet [C# MVP]" <sk***@pobox.com> wrote in message
news:11**********************@g14g2000cwa.googlegr oups.com...

Scott Roberts wrote:

<snip>

IMO, you should never code "real work" in an event handler - period. All
"real work" belongs in a method that is not inside the GUI in the first
place.

You're making three assumptions which may be invalid:

1) That the event being handled is a GUI event
2) That the real work is not GUI work (if it's GUI work, it's
reasonable for it to be done in the GUI code)
3) That the event handler is defined in GUI code (it may not be,
even if it happens to be hooked up to a GUI event)

The original post was related to combox events. In general, you are correct.

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,
"Scott Roberts" <sc***********@no-spam.intelebill.com> wrote in message
news:Ou**************@TK2MSFTNGP14.phx.gbl...

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us>
wrote
in message news:%2******************@TK2MSFTNGP14.phx.gbl...

IMO that is the reason why the sender parameter is there in the first
place, so the method can have a reference to who called it.

The "sender" parameter is there so you know which *component* fired the
event. This is so that multiple *components* can share a single event
handler.

Yes, that was what I meant, terrible combination of words, gave a
completely different meaning to the sentence.

Having another method that both the event handler and your code call to
perform the work do have sense IF the logic is different in any case,
otherwise I can't see how it makes it clearer.You are only removing the
parameters and you end with two methods:

void control_handle( ... )
{
do_the_real_work();
}

void do_the_real_work(){}
IMO that is not clearer at all.

IMO, you should never code "real work" in an event handler - period. All
"real work" belongs in a method that is not inside the GUI in the first
place.

So for you the handler is just a wrapper to another method?

What if the event invoke some other changes in the form?
cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Kevin Spencer]

> Why it's not?

An "event handler" is just a method as any other, in the same way that you
can have the same method hooked to more than one controls you can call it
yourself,
At the very least, it makes for code that is difficult to read. The test of
a practice is to imagine what the result would be if it were repeated a
sufficient number of times. In addition, it has parameters which are
irrelvant to anything but the delegate it is assigned to. This also adds
confusion to the code. An event handler's purpose is to handle an event.
IMO that is the reason why the sender parameter is there in the first
place, so the method can have a reference to who called it.
No, the purpose of the sender parameter is to match the signature of the
delegate it is assigned to. It is a Microsoft convention to add a sender
parameter to an EventHandler delegate, and sometimes it is a necessity, bot
often it is not. The convention exists for more than one purpose.

A property name may be any token that satisfies the grammatical rules for a
property name. None of those rules specify anything about casing. Camel
Case, Hungarian Notation, lower case, it is not specified in the grammar.
But Microsoft has a set of conventions for naming fields and properties that
they apply strictly throughout the organization. Again, there is a purpose
for this. It makes code easier to read and debug.

The C family of languages specifies nothing about the number and type of
white space characters between statements. You can type a whole slew of them
on the same line if you wish, to say nothing of indentation. But Microsoft
and other companies have strict sets of rules regarding this. Again, why?

If you program long enough, and eat enough of your own (and other people's)
dog food, you will find out. Of course, you could always skip the
indigestion, and take my word for it.

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
Ambiguity has a certain quality to it.
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:%2******************@TK2MSFTNGP14.phx.gbl... Hi,
Why it's not?
An "event handler" is just a method as any other, in the same way that you
can have the same method hooked to more than one controls you can call it
yourself,
IMO that is the reason why the sender parameter is there in the first
place, so the method can have a reference to who called it.

Having another method that both the event handler and your code call to
perform the work do have sense IF the logic is different in any case,
otherwise I can't see how it makes it clearer.You are only removing the
parameters and you end with two methods:

void control_handle( ... )
{
do_the_real_work();
}

void do_the_real_work(){}
IMO that is not clearer at all.
Now, in 2.0 with anonymous methods it's a complete different history, you
can declare the control_handle as a anonymous method and the code will be
clear indeed.
What you folks think about the above?
Do you write two methods like the above?
Cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

"Kevin Spencer" <ke***@DIESPAMMERSDIEtakempis.com> wrote in message
news:Oc**************@tk2msftngp13.phx.gbl...

Generally speaking, and for good design, you should not call an Event
Handler directly. Instead, create a method that the Event Handler can
call, as well as any other method that needs it.

--
HTH,

Kevin Spencer
Microsoft MVP
.Net Developer
Ambiguity has a certain quality to it.

"jac" <ja*@discussions.microsoft.com> wrote in message
news:84**********************************@microsof t.com...

Hae,

I have a windows form with a ComboBox an other things.
On that combobox I have an eventhandler on de selectedindexchanged.

But somewhere in my code want to do excecute the same code that is
writen
in the eventhandler.
Is it posible to call that eventhandler from the code (not from a real
selectedindexchanged on the form). So, I don't have to call that code
twice.
tkx
jac

[Scott Roberts]

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:uN**************@TK2MSFTNGP14.phx.gbl...

So for you the handler is just a wrapper to another method?
In general, yes. Every time I write an event handler longer than 5 lines of
code I end up wanting to re-use it in other parts of the application (other
forms, etc.). Since an event has a specific signature it's often difficult
to reuse it (e.g. with a different type of component).
What if the event invoke some other changes in the form?

As Jon pointed out, my assumption that "real work" excludes "GUI work" was
wrong. If the "real work" is related to modifying other GUI controls then it
makes sense to have the "RealWorkMethod" in the GUI.

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,
"Scott Roberts" <sc***********@no-spam.intelebill.com> wrote in message
news:Oo**************@TK2MSFTNGP12.phx.gbl...

"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us>
wrote
in message news:uN**************@TK2MSFTNGP14.phx.gbl...

So for you the handler is just a wrapper to another method?

In general, yes. Every time I write an event handler longer than 5 lines
of
code I end up wanting to re-use it in other parts of the application
(other
forms, etc.). Since an event has a specific signature it's often difficult
to reuse it (e.g. with a different type of component).

I generally use the handler when the name of the method as well as the
action being performed is clear to anybody reading the code; and at the
same time this action can be triggered by other means.

What if the event invoke some other changes in the form?

As Jon pointed out, my assumption that "real work" excludes "GUI work" was
wrong. If the "real work" is related to modifying other GUI controls then
it
makes sense to have the "RealWorkMethod" in the GUI.

We are in the same track, I was thinking exclusively in UI more especific
in win apps.
I was talking with a friend of mine about this subject and what is the best
strategy for UI programming so this thread is interesting for that reason, I
can see what other people think and do about it.

Real work usually include both think, UI updates and backend operations (
refresh a client's orders in a listview based on a client being selected in
the combobox).

BTW, one question, what strategy you follow to name the controls in a form?
cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation