Raise Timer_Elapsed event

[Vittorio Pavesi]

Hello,
is it possible to manually raise the event Elapsed of the timer object ?

Vittorio

[Herfried K. Wagner [MVP]]

* "Vittorio Pavesi" <[e-mail]> scripsit:

is it possible to manually raise the event Elapsed of the timer object ?

Place the code of the event handler in a separate method, then call this
method from within the event handler and any other place ;-).

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Vittorio Pavesi]

Thank you for the workaround, this means that is not possible to raise that
kind of event ?

Vittorio

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> ha scritto nel
messaggio news:2k************@uni-berlin.de...

* "Vittorio Pavesi" <[e-mail]> scripsit:

is it possible to manually raise the event Elapsed of the timer object ?

Place the code of the event handler in a separate method, then call this
method from within the event handler and any other place ;-).

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Cor Ligthert]

Hi Vittorio,

You can not raise the event however call the method, as with every event.

As parameters you can normaly always pass (Nothing, Nothing)

I hope this helps,

Cor

[Herfried K. Wagner [MVP]]

* "Vittorio Pavesi" <[e-mail]> scripsit:

Thank you for the workaround, this means that is not possible to raise that
kind of event ?

It simply doesn't make much sense IMO.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Herfried K. Wagner [MVP]]

* "Cor Ligthert" <no**********@planet.nl> scripsit:

You can not raise the event however call the method, as with every event.

As parameters you can normaly always pass (Nothing, Nothing)

This would call /one/ event handler, sure. Nevertheless, I don't think
that's a good idea, and placing the code of the handler in a separate
method would be the better approach.

If it's necessary to raise the event in certain situations, you can try
to inherit from the timer class and call the base class's
'On<EventName>' method to raise the event.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Vittorio Pavesi]

Really thanks for the explanation !

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> ha scritto nel
messaggio news:2k************@uni-berlin.de...

* "Vittorio Pavesi" <[e-mail]> scripsit:

Thank you for the workaround, this means that is not possible to raise that kind of event ?

It simply doesn't make much sense IMO.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Cor Ligthert]

Hi Herfried,

This time I do *not* disagree with you, however it is possible.
This would mean that the first action would be to disable the timer.
However it was to show that you could do this with almost every event.

(Although for that handler method it would be probably the same, I think it
is not right doing this for a timer and certainly not for another timer than
the forms.timer, however just my thought).

:-)

Cor

[Herfried K. Wagner [MVP]]

* "Vittorio Pavesi" <[e-mail]> scripsit:

Really thanks for the explanation !

In other words: No, you cannot /raise/ an event from outside a class
except the class provides a method that raises the event internally. I
doubt that this is the case in the case of the timer.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Herfried K. Wagner [MVP]]

* "Cor Ligthert" <no**********@planet.nl> scripsit:

This time I do *not* disagree with you, however it is possible.
This would mean that the first action would be to disable the timer.
However it was to show that you could do this with almost every event.

(Although for that handler method it would be probably the same, I think it
is not right doing this for a timer and certainly not for another timer than
the forms.timer, however just my thought).

You /can/ call an event handler the way you showed, but I would not pass
'Nothing' to the parameters. Instead I would pass a reference to the
control the event is belonging to in the 'sender' parameter and
'EventArgs.Empty' in the 2nd parameter.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Cor Ligthert]

Hi Herfried,

I find the fact not to do that for a timer more important than passing a
reference.

For the passing of parameters completely confirm the signature I see no
sense when it is not conform the sense of that signature although it are
objects.

So passing the same parameters when I have them is something I would always
do, however giving false parameters is in my eyes even more confusing, than
is nothing even better because that is testable to nothing.

To give you an example, you know that I like it to make a collection of
controls and than to add handlers to it, when I not send always the standard
object I would have to do in those events.

If typeoff sender Is Button then
if directcast(sender, button).name = etc.

This can as well as
If Not sender is Nothing then etc.

So there is not much benefit in my opinion when the sender is not the
expected object.

This is a long philosophic message this time.

Cor
"Herfried K. Wagner [MVP]" <hi***************@gmx.at> schreef in bericht
news:2k************@uni-berlin.de...

* "Cor Ligthert" <no**********@planet.nl> scripsit:

This time I do *not* disagree with you, however it is possible.
This would mean that the first action would be to disable the timer.
However it was to show that you could do this with almost every event.

(Although for that handler method it would be probably the same, I think it is not right doing this for a timer and certainly not for another timer than the forms.timer, however just my thought).

You /can/ call an event handler the way you showed, but I would not pass
'Nothing' to the parameters. Instead I would pass a reference to the
control the event is belonging to in the 'sender' parameter and
'EventArgs.Empty' in the 2nd parameter.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Jay B. Harlow [MVP - Outlook]]

Vittorio,
In addition to the other comments:

Which Timer object (.NET has 3 timer objects)?

It appears that only the System.Timers.Timer object has an Elapsed event, as
Herfried stated, this Timer does not allow others to raise its events. The
normal patterns is to have an overridable protected OnElapsed method that
derived objects can call to raise the event.

In addition to considering the other suggestions, I would consider creating
a new class that encapsulates the Timer, this new class would have its own
Elapsed event, this new class would handle the Timer.Elapsed event, raising
its own Elapsed event, plus it would have a public method allowing other
objects to raise its Elapsed event. I would only really consider creating
this new class, if I wanted or needed to have multiple handlers of a single
Timer's Elapsed event, making calling the handler or a common procedure
"messy".

Hope this helps
Jay

"Vittorio Pavesi" <[e-mail]> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...

Hello,
is it possible to manually raise the event Elapsed of the timer object ?

Vittorio

[Herfried K. Wagner [MVP]]

* "Cor Ligthert" <no**********@planet.nl> scripsit:

I find the fact not to do that for a timer more important than passing a
reference.
The event has basically nothing to do with the timer. It's sort of
"callback" that is called when the event is raised. Passing empty data
can cause a 'NullReferenceException' if you access 'sender' and 'e'
inside the event handler. If you are the author of the code, that's not
a problem, but let's think about a team of programmers and one
programmer adds code to the event handler that accesses 'sender' and 'e'
inside the event handler and *BANG*, an exception is thrown.

There is a "pattern" in .NET's event handling, so that the developer can
expect 'sender' and 'e' to be supplied.
So passing the same parameters when I have them is something I would always
do, however giving false parameters is in my eyes even more confusing, than
is nothing even better because that is testable to nothing.
Why giving false parameters? By passing the reference to the timer in
the 1st parameter you are passing the correct value. By passing an
appropriate 'EventArgs' object (or an instance of one of its subclasses,
depending on the case) is not passing a wrong value too.
To give you an example, you know that I like it to make a collection of
controls and than to add handlers to it, when I not send always the standard
object I would have to do in those events.

If typeoff sender Is Button then
if directcast(sender, button).name = etc.

This can as well as
If Not sender is Nothing then etc.

So there is not much benefit in my opinion when the sender is not the
expected object.

Sure, that's why I would pass the expected object.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>