[RESOLVED] 9 Timers

[dbasnett]

What is the most timers you have used in an application? I think the most I have ever used is 2.


In another forum this question was asked. "I have a Timer ... I have a situation where I want to run the code in the Tick event ONLY ONCE not on the interval i have the timer set too."

I responded with
Timer1_Tick(New Object, New System.EventArgs)

Which led to this

"The 'sender' object is VERY important when you have more than one Timer being handled by the Tick event procedure. This is because in a multi-timer tick event procedure, the only way your program knows which timer just fired is by querying the 'sender' object.

When you use code like this you are putting nothing into the 'sender' object, so that if you were ever going to query it a 'kaboom' is going to happen."

"...this 9 timer Tick event handler job done. Remember, all that is required is the correct timer name gets put into the ListBox." "The need for multi-timers to be handled by a single Tick event handler happens all the time. How would a real life programmer handle this? "


Oh, to test the "kaboom" theory I wrote this and ran it overnight successfully:

Public Class Form1

    Dim run As Boolean = False
    Dim pickIT As Integer = 0
    Dim lock As New Object

    Private Sub Form1_FormClosing(ByVal sender As Object, _
                                  ByVal e As System.Windows.Forms.FormClosingEventArgs) _
                                  Handles Me.FormClosing

        run = False
        Threading.Thread.Sleep(1000)

    End Sub

    Private Sub Form1_Load(ByVal sender As System.Object, _
                           ByVal e As System.EventArgs) Handles MyBase.Load

        Timer1.Start()
        Timer2.Start()
        Timer3.Start()
        Timer4.Start()
        Timer5.Start()
        Timer6.Start()
        Timer7.Start()
        Timer8.Start()
        Timer9.Start()

        'lets make it interesting by breaking all of ash2's rules
        'shouldn't be hard to "Kaboom" according to him

        For x As Integer = 0 To 499
            Dim t As New Threading.Thread(AddressOf PointlessForest)
            t.IsBackground = True
            t.Start()
        Next

    End Sub

    Private Sub PointlessForest()
        Do While Not run
            Threading.Thread.Sleep(100)
        Loop
        Do
            'a little variety
            Threading.Monitor.Enter(lock)
            If pickIT > Integer.MaxValue \ 2 Then pickIT = 0
            pickIT += 1
            If (pickIT And 1) = 0 Then 'if pickit is even then
                Threading.Monitor.Exit(lock)
                _TickTock(New TextBox, New System.EventArgs)
            Else
                Dim foo As String = "For oblio " & pickIT.ToString
                Threading.Monitor.Exit(lock)
                _TickTock(foo, New System.EventArgs)
            End If
            Threading.Thread.Sleep(10)
        Loop While run
    End Sub

    Private Sub _TickTock(ByVal sender As System.Object, _
                            ByVal e As System.EventArgs) _
                            Handles Timer1.Tick, Timer2.Tick, Timer3.Tick, _
                            Timer4.Tick, Timer5.Tick, Timer6.Tick, _
                            Timer7.Tick, Timer8.Tick, Timer9.Tick

        Dim t As System.Windows.Forms.Timer
        If TypeOf sender Is System.Windows.Forms.Timer Then
            t = DirectCast(sender, System.Windows.Forms.Timer)
            If ReferenceEquals(t, Timer1) Then
                Debug.WriteLine("T1")
            ElseIf ReferenceEquals(t, Timer2) Then
                Debug.WriteLine("T2")
            ElseIf ReferenceEquals(t, Timer3) Then
                Debug.WriteLine("T3")
            ElseIf ReferenceEquals(t, Timer4) Then
                Debug.WriteLine("T4")
            ElseIf ReferenceEquals(t, Timer5) Then
                Debug.WriteLine("T5")
            ElseIf ReferenceEquals(t, Timer6) Then
                Debug.WriteLine("T6")
            ElseIf ReferenceEquals(t, Timer7) Then
                Debug.WriteLine("T7")
            ElseIf ReferenceEquals(t, Timer8) Then
                Debug.WriteLine("T8")
            ElseIf ReferenceEquals(t, Timer9) Then
                Debug.WriteLine("T9")
            Else
                Stop
            End If
        Else
            Debug.WriteLine(sender.ToString) 'uncomment to test
        End If

        'I am waiting on an answer?
        'Debug.WriteLine(sender.name) 'this doesn't work
        'Debug.WriteLine(t.name) 'name' is not a member of 'System.Windows.Forms.Timer'.

    End Sub

    Private Sub Button1_Click(ByVal sender As System.Object, _
                              ByVal e As System.EventArgs) Handles Button1.Click
        run = True

    End Sub
End Class

[dbasnett]

I am trying to understand the rationale for 9 timers in any circumstance. So if you are using several (more than 2) help me understand. I should have asked this in the first post.

[jmcilhinney]

I've seen various threads where people they were or suggested that someone use multiple Timers when there was really no need to use more than one. I guess that it might be possible to want several different things done multiple times on several different schedules, but not usually.

The thing is, I ALWAYS recommend against calling an event handler directly and I NEVER do it myself. It's just one of those things that good code doesn't do. Event handlers should handle events and that's it. If you have code that want executed from somewhere else then you should put it in its own method, which you can then call from the original event handler and from anywhere else too.

[dbasnett]

I've seen various threads where people they were or suggested that someone use multiple Timers when there was really no need to use more than one. I guess that it might be possible to want several different things done multiple times on several different schedules, but not usually.

The thing is, I ALWAYS recommend against calling an event handler directly and I NEVER do it myself. It's just one of those things that good code doesn't do. Event handlers should handle events and that's it. If you have code that want executed from somewhere else then you should put it in its own method, which you can then call from the original event handler and from anywhere else too.

I am guilty of doing one-time calls directly to event handlers, typically when I want the event code to execute before the event can fire.

The one I am most guilty of (maybe the only one) is that I put a TOD display in most things I work on because I tend to lose track of time, and end up being late. That means I have a timer firing every few seconds and it annoys me waiting for the first tick to see the time, so in the shown event I call the event handler directly(nothing like patience huh).

I normally do as you suggest, putting the code in its own method.

Usually a combination of a timer and stopwatch / TOD suffices in the place of multiple timers, at least for me it has for me up to now.

I was "amused" at some of the other comments, especially the ones predicting "kaboom".

[VBDT]

"kaboom" didn't happen but you haven't seen the "Debug.WriteLine" did you?. Take a look on what you passing to the event sub procedure as a parameter:

_TickTock(New TextBox, New System.EventArgs)
_TickTock(foo, New System.EventArgs)

In the first case you are passing a textbox control and on the second case you are passing a string. The "kaboom" didn't happen because you have this condition in the _TickTock sub procedure.

If TypeOf sender Is System.Windows.Forms.Timer Then

[dbasnett]

Of course I did. If your point is that wrote the code not to fail, you are correct. I feel like I am missing something. And you can be sure that I know exactly what the debug statements were outputting.

[VBDT]

Of course I did. If your point is that wrote the code not to fail, you are correct. I feel like I am missing something. And you can be sure that I know exactly what the debug statements were outputting.

Are you saying that debug statement was writing something by calling the sub procedure? Or am I missing the point in here.

calling the sub procedure by those parameters will not pass the condition if statement in the Tick procedure so debug will not write anything.
The only time you would see the debug statement write something if event is called by the timer object.

never mind, I didn't see the other debug statements.

[dbasnett]

There was someone contending that the application would blow up if you invoked the event handler with something other than a timer. Fundamentally, though I stray, I agree with JMC.

When I disagreed I got back the "9 timers" business. The conversation got personal then, so I posted the code you see and said prove it. Of course that is a real show stopper when someone asks you to back up your words with actual code.

[minitech]

Well, RTTI should be avoided if at all possible.

I'm still struggling to understand what that code you posted is for...

And I have never used more than 1 timer and I think that if you think it out, any situation in which you need multiple timers can be solved elegantly with only one timer or a different program structure.

[minitech]

But BTW, if you are going to make a "kaboom" situation by passing the New Object() to the timer, be a good coder, pass Nothing, and check against Nothing instead of using TypeOf.

[dbasnett]

Well, RTTI should be avoided if at all possible.

I'm still struggling to understand what that code you posted is for...

And I have never used more than 1 timer and I think that if you think it out, any situation in which you need multiple timers can be solved elegantly with only one timer or a different program structure.

RTTI?

The code was nonsense, to prove that the timer event wouldn't go kaboom under the worst of circumstances, if coded properly?

I have done 2, mostly out of laziness. One for my clock and one for everything else, though in principle I agree that one could suffice.

"But BTW, if you are going to make a "kaboom" situation by passing the New Object() to the timer, be a good coder, pass Nothing, and check against Nothing instead of using TypeOf. "

I am missing your point. If you are going to indulge in the less than optimal practice of invoking the method that is a handler what difference does it make what you pass? I am not arguing for a Textbox, I just used that as an obvious poor choice, to prove it did not matter.

[minitech]

It's not less than optimal, it's just a subroutine like any other that handles an event.

RTTI = RunTime Type Identification = use of TypeOf = reflection = slower than optimal.

[dbasnett]

You learn something new everyday, and in this case the oddest of ways(you can't imagine how odd). I didn't know that TypeOf was that slow.

Is the Reference equals RTTI also?

[minitech]

No, it's not. The only RTTIs are TypeOf and GetType(Object). (Maybe Object.GetType() too, I'm not sure)

[dbasnett]

@mini - are you really 12? I don't think I like being taught by a 12 year old

[VBDT]

There was someone contending that the application would blow up if you invoked the event handler with something other than a timer. Fundamentally, though I stray, I agree with JMC.

When I disagreed I got back the "9 timers" business. The conversation got personal then, so I posted the code you see and said prove it. Of course that is a real show stopper when someone asks you to back up your words with actual code.

Ok, now I understand the nature of the question. If you take away the condition statement than yes with present code kaboom will happen. The bad thing of passing none timer type object in to sub procedure is that the parameter name "sender" tells the coder that sender should be timer type not something else. For example imagine in .net for button click event handler the sender parameter is of a type textbox. Wouldn't this be odd, certainly it would be considered as a bug.

In conclusion,
Event handlers are same as any sub procedures with two parameters, one representing the object that raises the event and the other contains additional information. So in your case if you don't condition the validity of the parameters and use them, than yes you are going to get an exception. In particular the exception will happen in your code at this line:

t = DirectCast(sender, System.Windows.Forms.Timer)

if the sender is not a type of timer.

[dbasnett]

Ok, now I understand the nature of the question. If you take away the condition statement than yes with present code kaboom will happen. The bad thing of passing none timer type object in to sub procedure is that the parameter name "sender" tells the coder that sender should be timer type not something else. For example imagine in .net for button click event handler the sender parameter is of a type textbox. Wouldn't this be odd, certainly it would be considered as a bug.

In conclusion,
Event handlers are same as any sub procedures with two parameters, one representing the object that raises the event and the other contains additional information. So in your case if you don't condition the validity of the parameters and use them, than yes you are going to get an exception. In particular the exception will happen in your code at this line:

t = DirectCast(sender, System.Windows.Forms.Timer)

if the sender is not a type of timer.

Aren't bugs something not planned for? No matter how bad it is (this is right up there, 9 timers, 500 threads!!!) I don't think the word bug is appropriate unless the code fails, or will fail. All this code was for was to prove that it wouldn't break if coded properly, it doesn't really matter to me how bad it looks, because it is nonsense.

"If you take away the condition statement than yes with present code kaboom will happen." I have already agreed that if you write any method and doesn't account for how it is invoked, then errors occur. There is nothing special about the timer.

If you write bad code, like this:

    Private Sub Button2_Click(ByVal sender As System.Object, _
                              ByVal e As System.EventArgs) Handles Button2.Click

        Dim oblio As New foo
        oblio.Value = TextBox1.Text

    End Sub

    Class foo
        Private _bar As Integer

        Property Value() As Object
            Get
                Return Me._bar
            End Get
            Set(ByVal value As Object)
                Me._bar = CInt(value)
            End Set
        End Property

    End Class

Then you are asking for bugs.

[minitech]

@mini - are you really 12? I don't think I like being taught by a 12 year old

It's a one-time sort of thing

[formlesstree4]

As of right now, I don't use timers. I view them as....unnecessary in most cases. I usually utilize events. The closest I've come to a timer is a StopWatch for my Downloading System.

[minitech]

Yeah, in most cases, threading is better, just because of the speed.

[dbasnett]

@mini - if you are 12 take this as a compliment, I don't believe you.

[minitech]

I don't mind

I'm curious though, where do you use 2 timers?

[dbasnett]

I don't mind

I'm curious though, where do you use 2 timers?

I don't remember. I use one a lot for time-of-day for the reasons stated earlier. As I've got better with VB I find the need for timers less often.

[stanav]

@mini - are you really 12? I don't think I like being taught by a 12 year old

You should also ask what base the number 12 is in. In computer world, numeric values are not always in base 10

[MaximilianMayrhofer]

In computer world, there are no base 10 numbers..... It's kind of binary..

[dbasnett]

In computer world, there are no base 10 numbers..... It's kind of binary..

Bazinga!

[minitech]

Yup, 12 is actually my age in binary. Just compile it.

[minitech]

Oh, and why is everybody saying "Bazinga!" now?

EDIT: Google'd it:
Urban Dictionary: bazinga
23 May 2009 ... bazinga - 4 definitions - A catchy phrase to accompany your clever pranks. As popularized by Sheldon Cooper (The Big Bang Theory).

[dbasnett]

You don't watch the "Bing Bang Theory?"

Or are you Dr. Sheldon Cooper in disguise and you said that so you could say "Once again, you've fallen for one of my classic pranks. Bazinga!"

[minitech]

No. A problem with that?

I don't watch any TV shows except for NOVA. And I hate that everything's in HD now because I can't see the full picture.

[dbasnett]

No. A problem with that?

I don't watch any TV shows except for NOVA. And I hate that everything's in HD now because I can't see the full picture.

No. Not a problem. It is funny.

[minitech]

Um, thanks. :S

[jmcilhinney]

Yup, 12 is actually my age in binary. Just compile it.

That's the strangest binary number I've ever seen.

[minitech]

These posts should be moved to Chit-Chat...