Call an method that is an eventhandler

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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
 
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_SelectedIndexChanged);

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
 
Hi,

Yes you can, just call combo_selectedindexchanged ( null, null );


cheers,
 
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.
 
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.
 
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.
 
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
 
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.
Click to expand...

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.
Click to expand...

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?
Click to expand...

Yes. Two methods.
 
Scott Roberts wrote:

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.
Click to expand...

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
 
Jon Skeet said:
Scott Roberts wrote:



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)
Click to expand...

The original post was related to combox events. In general, you are correct.
 
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,
Click to expand...

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.
Click to expand...

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


Scott Roberts said:
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us>
wrote
in message

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.
Click to expand...

Yes, that was what I meant, terrible combination of words, gave a
completely different meaning to the sentence.
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.
Click to expand...

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

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


cheers,
 
So for you the handler is just a wrapper to another method?
Click to expand...

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?
Click to expand...

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


Scott Roberts said:
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us>
wrote
in message

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).
Click to expand...

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.
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.
Click to expand...

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,
 

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

Similar Threads

Adding and removing eventhandlers 1
strange way to subscibe to an event without explicitly using the EventHandler 2
anonymous method 2
execute in ui thread 1
Events Despatching Multiple Methods 1
To New(EventHandler) or !To New(EventHandler) 8
Calling an event from an inner class 4
Problem with EventHandlers 3

Back
Top