Page 1 of 2 12 LastLast
Results 1 to 40 of 44

Thread: Timer not acting as I expect

  1. #1

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Timer not acting as I expect

    I have used timers in just about every app I have ever developed, but not quite like this...

    I am obviously failing to understand something here

    Code:
    01 Public Class TimerExample
    02    WithEvents Timer As New Timer With {.Interval = 1}
    03    Dim CurrTimerInterval As Integer = 0
    04    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
    05        ProgressBar1.Maximum = 5000
    06        Timer.Start()
    07    End Sub
    08    Private Sub TimerTick() Handles Timer.Tick
    09        While CurrTimerInterval < 5000
    10            ProgressBar1.Value += 1
    11            CurrTimerInterval += 1
    12        End While
    13        Timer.Stop()
    14        'MsgBox("Whats happening here?!")
    15        CurrTimerInterval = 0
    16        ProgressBar1.Value = 0
    17    End Sub
    18 End Class
    Firstly, if I comment out Line 16 then the progressbar goes from 0 to 5000 in about 1 second(give or take a few ms)
    If I leave Line 16 as is the progressbar presumably resets as though this line was in the loop, it appears that the run position is not staying in the loop, like the condition is being ignored yet it's still running the lines in the loop
    and to my complete disbelief, if I do not comment out Line 16 and uncomment Line 14, It again will take about 1 second for progressbar to go from 0 to 5000

    What I would expect is that the progressbar takes 5 seconds (5000ms) to go from 0 to 5000
    Last edited by kpmc; Dec 6th, 2017 at 12:05 PM.

  2. #2
    PowerPoster PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Pontypool, Wales
    Posts
    2,458

    Re: Timer not acting as I expect

    Quote Originally Posted by kpmc View Post
    I have used timers in just about every app I have ever developed, but not quite like this...

    I am obviously failing to understand something here

    Code:
    01 Public Class TimerExample
    02    WithEvents Timer As New Timer With {.Interval = 1}
    03    Dim CurrTimerInterval As Integer = 0
    04    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
    05        ProgressBar1.Maximum = 5000
    06        Timer.Start()
    07    End Sub
    08    Private Sub TimerTick() Handles Timer.Tick
    09        While CurrTimerInterval < 5000
    10            ProgressBar1.Value += 1
    11            CurrTimerInterval += 1
    12        End While
    13        Timer.Stop()
    14        'MsgBox("Whats happening here?!")
    15        CurrTimerInterval = 0
    16        ProgressBar1.Value = 0
    17    End Sub
    18 End Class
    Firstly, if I comment out Line 16 then the progressbar goes from 0 to 5000 in about 1 second(give or take a few ms)
    If I leave Line 16 as is the progressbar presumably resets as though this line was in the loop, it appears that the run position is not staying in the loop, like the condition is being ignored yet it's still running the lines in the loop
    and to my complete disbelief, if I do not comment out Line 16 and uncomment Line 14, It again will take about 1 second for progressbar to go from 0 to 5000

    What I would expect is that the progressbar takes 5 seconds (5000ms) to go from 0 to 5000
    Your TimerTick routine has a loop (lines 09 - 12) that increase the progress bar value to 5000, this loop is run when the timer ticks.

    That means as soon as the first tick event fires you run the loop until the progressbar has a value of 5000. I think you meant to keep increasing the value of the progress bar by one on every tick event, not to keep looping to 5000 on each event.

    Could you not make the it something like
    Code:
    Private Sub TimerTick() Handles Timer.Tick
        If ProgressBar1.Value< 5000
            ProgressBar1.Value += 1
         Else
            Timer.Stop()
            ProgressBar1.Value = 0
         End If
    End Sub
    Code hasn't been tested but should give you an idea.

    Also be aware that the precision of the timer might not give 1ms accuracy so the overall time could be more (or less) than 5 seconds.
    Last edited by PlausiblyDamp; Dec 6th, 2017 at 12:15 PM.

  3. #3
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    6,582

    Re: Timer not acting as I expect

    p.s. I figured someone else would get an answer in before I finished my post, and I was right....

    Well, a timer isn't that accurate, so it would be rare that you would get a 1ms tick interval for a selection of an interval of 1.
    Also, you have an continuous loop inside the timer, so at the first time the timer ticks you just go into loop for 5000 iterations, then exit.
    I would expect that loop to last a very small fraction of a second.
    Since you're in a continuous loop, other things can't happen in that time, e.g. updating the display so you see progress of the bar.

    The GUI can't be updated (i.e. the display won't show new information) while your code is running. You have to leave the Tick event, so that the GUI can update.

    What is happening is you are leaving the Tick event very quickly (after completing the loop). If you comment out the resetting of the ProgressBar to 0, then after you leave the Tick event, you see that happening. The progress bar has a built in delay when it updates, so you are essentially setting the value to 5000, and the progress bar shows the value changing (using a ramp over a short period of time) from 0 to Max, so you see that ramped value over the period of about a second.

    You should try changing the code to something like this.
    Code:
    Public Class TimerExample
        WithEvents Timer As New Timer With {.Interval = 1}
        Dim CurrTimerInterval As Integer = 0
        Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
            ProgressBar1.Maximum = 5000
            Timer.Start()
        End Sub
        Private Sub TimerTick() Handles Timer.Tick
            If CurrTimerInterval < 5000
                ProgressBar1.Value += 1
                CurrTimerInterval += 1
            Else 'we counted 5000 ticks
                Timer.Stop()
                CurrTimerInterval = 0
                ProgressBar1.Value = 0
            End If
        End Sub
    End Class
    You should find that it will probably take about 1.25 minutes to get 5000 ticks, in the normal case where ticks come in at the rate of 64 times per second max.
    You should probably just determine how long you want to wait, and use a stopwatch object to track the time, with the tick event just checking the elapsed time from the stopwatch.

  4. #4

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    I sort of follow you. Thinking about it some more, I now want to think that the sub should get stuck in a while loop because the counter variable should never exceed 1
    The tick event fires, variable changes to 1, how exactly does it get out of that loop in the first place? Does the tick event occur even if the sub is already running?

    Also when removing the loop and including an If condition I seem to be getting an opposite effect, the progress runs at a snail pace.
    Code:
        Private Sub TimerTick() Handles Timer.Tick
            If ProgressBar1.Value < 5000 Then
                ProgressBar1.Value += 1
            Else
                Timer.Stop()
                ProgressBar1.Value = 0
            End If
        End Sub
    I maybe ablt to make a stopwatch work, i didnt even think of that

    ...re-thinking, the counter is incremented in the loop. however there is no 1ms interval in counting that up... duh

  5. #5

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    Should this not be showing a new time in textbox for each tick? It is showing the exact time to the ms with each tick
    Code:
    Public Class TimerExample
        WithEvents Timer As New Timer With {.Interval = 1}
    
        Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
            ProgressBar1.Maximum = 5000
            Timer.Start()
        End Sub
        Private Sub TimerTick() Handles Timer.Tick
            If ProgressBar1.Value < 5000 Then
                ProgressBar1.Value += 1
                TextBox1.Text &= Date.Now & Environment.NewLine
    
            Else
                Timer.Stop()
                ProgressBar1.Value = 0
            End If
        End Sub
    End Class

  6. #6
    PowerPoster PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Pontypool, Wales
    Posts
    2,458

    Re: Timer not acting as I expect

    If you are appending a new line and then appending the time the extra lines might not be visible, is the textbox big enough to show all the text?

    The reason it might appear to be taking longer than expected to count up to 5,000 is down to the timer resolution - the timer doesn't have 1ms accuracy I think it is around 15ms so you are only going to get a tick about 60 - 70 times a second.

  7. #7

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    I do understand it is not precise to the ms, but in this case it's not even precise to the minute.
    is the textbox big enough to show all the text?
    It is a multiline textbox.

    it is puzzling bcz each minute is producing like 63 line in the TB

    Datetime ============= ms
    12/6/2017 1:39:32 PM=====8764
    12/6/2017 1:39:32 PM=====8775
    12/6/2017 1:39:32 PM=====8791
    12/6/2017 1:39:32 PM=====8810
    12/6/2017 1:39:32 PM=====8822
    12/6/2017 1:39:32 PM=====8841
    12/6/2017 1:39:32 PM=====8854
    12/6/2017 1:39:32 PM=====8871
    12/6/2017 1:39:32 PM=====8888
    12/6/2017 1:39:32 PM=====8899
    12/6/2017 1:39:32 PM=====8916
    12/6/2017 1:39:32 PM=====8933
    12/6/2017 1:39:32 PM=====8951
    12/6/2017 1:39:32 PM=====8963
    12/6/2017 1:39:32 PM=====8983
    12/6/2017 1:39:32 PM=====8997
    12/6/2017 1:39:32 PM=====9010
    12/6/2017 1:39:32 PM=====9029
    12/6/2017 1:39:32 PM=====9040
    12/6/2017 1:39:32 PM=====9058
    12/6/2017 1:39:32 PM=====9078
    12/6/2017 1:39:32 PM=====9088
    12/6/2017 1:39:32 PM=====9103
    12/6/2017 1:39:32 PM=====9121
    12/6/2017 1:39:32 PM=====9134
    12/6/2017 1:39:32 PM=====9181
    12/6/2017 1:39:32 PM=====9200
    12/6/2017 1:39:32 PM=====9214
    12/6/2017 1:39:32 PM=====9230
    12/6/2017 1:39:32 PM=====9244
    12/6/2017 1:39:32 PM=====9260
    12/6/2017 1:39:32 PM=====9280
    12/6/2017 1:39:32 PM=====9290
    12/6/2017 1:39:32 PM=====9307
    12/6/2017 1:39:32 PM=====9324
    12/6/2017 1:39:32 PM=====9345
    12/6/2017 1:39:32 PM=====9354
    12/6/2017 1:39:32 PM=====9371
    12/6/2017 1:39:32 PM=====9385
    12/6/2017 1:39:32 PM=====9400
    12/6/2017 1:39:32 PM=====9421
    12/6/2017 1:39:32 PM=====9433
    12/6/2017 1:39:32 PM=====9447
    12/6/2017 1:39:32 PM=====9466
    12/6/2017 1:39:32 PM=====9487
    12/6/2017 1:39:32 PM=====9494
    12/6/2017 1:39:32 PM=====9514
    12/6/2017 1:39:32 PM=====9524
    12/6/2017 1:39:32 PM=====9542
    12/6/2017 1:39:32 PM=====9561
    12/6/2017 1:39:32 PM=====9571
    12/6/2017 1:39:32 PM=====9589
    12/6/2017 1:39:32 PM=====9609
    12/6/2017 1:39:32 PM=====9620
    12/6/2017 1:39:32 PM=====9637
    12/6/2017 1:39:32 PM=====9650
    12/6/2017 1:39:32 PM=====9671
    12/6/2017 1:39:32 PM=====9683
    12/6/2017 1:39:32 PM=====9703
    12/6/2017 1:39:32 PM=====9713
    12/6/2017 1:39:32 PM=====9730
    12/6/2017 1:39:32 PM=====9749


    Code
    Code:
    Public Class TimerExample
        WithEvents Timer As New Timer With {.Interval = 1}
        Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
            ProgressBar1.Maximum = 5000
            Timer.Start()
            SW.Start()
        End Sub
        Dim SW As New Stopwatch
        Private Sub TimerTick() Handles Timer.Tick
            If ProgressBar1.Value < 5000 Then
                ProgressBar1.Value += 1
                TextBox1.Text &= Date.Now & "=====" & SW.ElapsedMilliseconds.ToString & Environment.NewLine
            Else
                Timer.Stop()
                ProgressBar1.Value = 0
            End If
        End Sub
    End Class
    This is making me feel kind of dumb

  8. #8

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    it is puzzling bcz each minute is producing like 63 line in the TB
    Actually thats not a minute of results. That is how many lines are written before a new ms starts

  9. #9
    PowerPoster PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Pontypool, Wales
    Posts
    2,458

    Re: Timer not acting as I expect

    I am not entirely sure what the problem is - if you take the last line
    Code:
    12/6/2017 1:39:32 PM=====9749
    it is showing the date as being the 6th December 2017 and the time as being 1:39:32 in the afternoon (almost twenty to two) and then 9749 milliseconds, if the time is firing approximately 60 - 70 times a second (as I mentioned earlier) then you would expect approximately 60 or 70 entries per second. I am not sure how this isn't what you are expecting or how it isn't precise to the minute.

  10. #10

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    My logic is this:
    There is 5000ms in 5 seconds
    1 timer tick = approx 1 ms
    it should (roughly) take 5 seconds to count from 0 to 5000
    it should roughly take 5000ms for progressbar to go from min (0) to max (5000) not like 2 minutes...

  11. #11
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    6,582

    Re: Timer not acting as I expect

    63 is not surprising as I said in my first post.
    The clock that is used to trigger the ticks of the timer by default is based on a 64hz cycle.
    The cycle doesn't start when you enable the timer, it is continually going on in the background.
    When you enable the timer, you are most likely going to be somewhere in the cycle, not synchronized with the start of the cycle so the first period will normally be the minimum interval (i.e. 15.625) + whatever remained of the cycle when you started. After the first tick, you will be in sync with the clock, but depending on what interval you chose, you won't get what you expect. Since the timer has to tick on a 64hz clock phase, if you ask for 15ms or less, you will get a tick at around 64hz. The timer has a low event priority, so other events, like mouseMoves can take precedence so your ticks may be delayed or skipped, given you less than 64 a second.

    If you chose a value like 20ms, which theoretically would be 50hz, since the tick has to occur on a phase of the 64hz clock, you will get a tick every other phase of the 64hz clock, meaning that you will get ticks at 32hz, not 50hz.
    You need to be aware of this 64hz cycle so that you know that you won't get 50hz ticks if you ask for it.
    If I'm going to use a timer for periodic processing, I will assume the clock will run no faster than 64 hz and go ahead and choose a small interval like 1, or 2.
    I will also start a stopwatch running and keep track of the true elapsed time each time the timer ticks. That way I can choose to process 50 times a second and get 50 times per second, but the 50 events won't be evenly spaced. The 50 events will happen at a 64hz rate, but I will end up skipping the processing 14 times (skipping processing every 6 or 7th tick) over that second to achieve 50 "ticks" per second. Just updating the trigger time by 50 ms each time I reach my trigger, takes care of giving my by average rate over time.
    Last edited by passel; Dec 6th, 2017 at 02:24 PM.

  12. #12
    PowerPoster PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Pontypool, Wales
    Posts
    2,458

    Re: Timer not acting as I expect

    Quote Originally Posted by kpmc View Post
    My logic is this:
    There is 5000ms in 5 seconds
    1 timer tick = approx 1 ms
    it should (roughly) take 5 seconds to count from 0 to 5000
    it should roughly take 5000ms for progressbar to go from min (0) to max (5000) not like 2 minutes...
    It has already been said in this thread that the timer doesn't have a 1ms accuracy, you can request an interval of 1ms but you aren't going to get that - it is closer to 15ms. If it is firing once every 15 or so milliseconds then 5,000 ticks is 5,000 * 15 to give roughly 75,000 ms which is about 1 minute 15, that is assuming it fires that often. If the time is slightly longer (even 17 or 18 ms) would put it closer to a minute and a half.

  13. #13
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    6,582

    Re: Timer not acting as I expect

    Quote Originally Posted by kpmc View Post
    My logic is this:
    ...
    1 timer tick = approx 1 ms
    ...
    That is the problem with your logic, as already explained.
    1 timer tick = 15.625 ms, not 1 ms.

    If someone has chosen to use an API call to change the base interval that Windows uses for scheduling, you can get 1ms for your timer interval, but that effects all of Windows scheduling, not just that timer, so the end result is that things get less efficient for all programs running under windows, since the Windows scheduler will be doing contexts switches between processes 15 times faster than normal, so the process switching overhead will take a greater percentage of the available CPU time than with Window's default interval.

  14. #14

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    It has already been said in this thread that the timer doesn't have a 1ms accuracy
    I left a lot up to assumption, like +/- a few ms. I didnt think this inaccuracy could account for 2,300% increase.

    passel seems to have it figured out.

    I will do more testing based on what I have learned here today. Thank you

  15. #15
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: Timer not acting as I expect

    Uh, let's be clear that you understand how a timer works, OK? Part of the problem here is you aren't fully explaining what you expect when you post code, so it's hard for us to elucidate why your expectations are violated.

    The Timer component raises an event after its Interval passes. When the UI thread is not busy, it processes that event. "When the UI thread is not busy" is an important concept to keep in mind. It has to do a lot of things, like redraw controls, handle mouse input, handle keyboard input, etc.

    The Timer component has to use SOMETHING that works as a clock. It's not inherently clear, but there aren't really any reliable clocks in most systems. A good rule of thumb is you can assume there's a 16ms clock available, so that happens to be the smallest usable interval the Timer tends to have. But sometimes you encounter a system that's got worse. Generally you don't get better unless you're paying for very expensive, specific hardware for data acquisition.

    But even if you did get 1ms out of it, that would be very bad for your Windows Forms application. It takes some number of milliseconds to draw the Form, some number to process a keypress, etc. That number is sometimes "more than 1". So if it takes 20ms to update the screen, 20 timer Tick events will get raised while that happens. Then your UI is "stuck" and can't do anything while it handles EACH of those 20 updates. You might change the ProgressBar value 20 times, which will generate 20 Paint events. Thankfully, Windows is smart enough to see that and only really deal with 1 Paint event. But that means 19 of your timer ticks were wasted effort!

    Worse, while you're dealing with 20 timer ticks, your Form can't do something else. That means mouse events, keyboard events, and other kinds of events will have to wait in line. The surest symptom of a "too-fast" timer is "my form updates really slowly".

    It is confusing to me that you are confused by the results of your code, so I'd like to hear what you think it should do.

    What it does every timer tick is add 1 to the ProgressBar's value, then add a line to the TextBox. This has some weird implications that aren't apparent if you don't realize everything's happening on one thread.

    First: as I said before, the fastest you'll really get the Ticks is 16ms apart. So you expect it to take 5s, but in reality it shouldn't be much faster than 80s.

    Second: Date.Now and the SW.ElapsedMilliseconds aren't "when the event is raised" but "when the event handler is called". So if the UI is busy, or the computer is under load, you'll see a different period between many of the events.

    Third: your event handler takes time to run. In particular, appending text to a TextBox takes longer as the string gets longer.

    Fourth: For the ProgressBar to animate, it has to be drawn in between ticks. I guarantee it takes longer than 1ms to draw a ProgressBar.

    If your goal is "I would like to smoothly animate a ProgressBar to fill up over 5 seconds", that is actually very hard to accomplish in Windows Forms. 16ms is just barely fast enough to get 60 FPS, but in general if you set a timer to an Interval that fast it's hard to do much else on the thread. 33ms is more reasonable, that's about 30FPS and when I've tried WinForms animation in the past I found that was much easier to maintain.

    If you try it, it's foolish to assume you'll always get timer Ticks at exactly the interval. To animate controls, you need a concept called "interpolation". That involves calculating the ratio of time that has passed and using that go generate the right value for the current time. For example, at t=1s, you are 20% of the way through. So you want to set the Value to 0.2 * 5000 = 1000 in that case. Using interpolation means you can deal with a variable framerate and maintain a consistent duration.

    But your code is doing exactly what it says it will do:

    • The Tick event is raised as fast as the Timer can possibly raise it, approximately every 16ms.
    • While the progress bar's value is < 5000, each Tick event adds 1 to the Value, and adds a line to a TextBox. This will happen no faster than 60 times per second, probably fewer.
    • When the progress bar's value is > 5000, each Tick event will stop the timer.
    • It is likely sometimes the Tick events "stack", that is, another Tick happens while one is operating.
    • If the UI gets busy doing something else, Tick events will also "stack".

    So my assessment of the observed behavior is if you wait approximately a minute and a half, the loop will finish. By then, 5000 lines will be in the TextBox and the ProgressBar will be full. During the 80-second period, the form will be very jittery because you'll be occupying the UI with a lot of tasks, the greatest of them "concatenating strings with thousands of lines".

    What did you expect?

    Or more importantly: what are you trying to do? It's possible what you want just isn't doable with a Timer. We could save you days of effort if we could help you figure that out.

    If you need help making tea, you don't ask about matches and kindling. You ask about making tea.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  16. #16
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    6,582

    Re: Timer not acting as I expect

    You can probably figure it our for yourself now, but I just ran a simple test as an example.
    In this example, it is sort of as I described above. I want to run a process 50 times per second, for a one second period.
    Code:
    Public Class Form1
      Private DesiredTickInterval As Integer 'interval in ms
      Private DesiredTime As Long 'How long we want to process in ms
      Private TriggerTime As Long 'Updated to define when we should process next
      Private sw As New Stopwatch
      Private ProcessRuns As Integer
    
      Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click
        sw.Reset()
        DesiredTickInterval = 20 '20ms means process 50 times per second
        TriggerTime = DesiredTickInterval 'intialize first trigger
        ProcessRuns = 0
        DesiredTime = 1000  'process for 1 second
        Timer1.Interval = 1 'let timer fire as quick as it can (probably 64 times per second)
        Timer1.Start()      'start the timer
        sw.Start()          'start our elapsed time stopwatch
      End Sub
    
      Private Sub Timer1_Tick(sender As System.Object, e As System.EventArgs) Handles Timer1.Tick
        Dim currentElapsedTime As Long = sw.ElapsedMilliseconds
        If currentElapsedTime >= TriggerTime Then   'our desired interval has past
          TriggerTime += DesiredTickInterval  'update our trigger for the next desired time
          'do processing
          ProcessRuns += 1
          Debug.Print("Process {1} Ran at {0}ms elapsed time", currentElapsedTime.ToString, ProcessRuns.ToString)
        End If
        If currentElapsedTime >= DesiredTime Then
          sw.Reset()
          Timer1.Stop()
          Debug.Print("Process ran {0} times, taking {1}ms", ProcessRuns.ToString, currentElapsedTime.ToString)
        End If
      End Sub
    End Class
    Here's the print out.
    Code:
    Process 1 Ran at 26ms elapsed time
    Process 2 Ran at 46ms elapsed time
    Process 3 Ran at 73ms elapsed time
    Process 4 Ran at 95ms elapsed time
    Process 5 Ran at 110ms elapsed time
    Process 6 Ran at 125ms elapsed time
    Process 7 Ran at 142ms elapsed time
    Process 8 Ran at 168ms elapsed time
    Process 9 Ran at 195ms elapsed time
    Process 10 Ran at 211ms elapsed time
    Process 11 Ran at 226ms elapsed time
    Process 12 Ran at 242ms elapsed time
    Process 13 Ran at 273ms elapsed time
    Process 14 Ran at 295ms elapsed time
    Process 15 Ran at 311ms elapsed time
    Process 16 Ran at 327ms elapsed time
    Process 17 Ran at 342ms elapsed time
    Process 18 Ran at 373ms elapsed time
    Process 19 Ran at 395ms elapsed time
    Process 20 Ran at 411ms elapsed time
    Process 21 Ran at 426ms elapsed time
    Process 22 Ran at 442ms elapsed time
    Process 23 Ran at 473ms elapsed time
    Process 24 Ran at 481ms elapsed time
    Process 25 Ran at 511ms elapsed time
    Process 26 Ran at 527ms elapsed time
    Process 27 Ran at 542ms elapsed time
    Process 28 Ran at 574ms elapsed time
    Process 29 Ran at 596ms elapsed time
    Process 30 Ran at 611ms elapsed time
    Process 31 Ran at 627ms elapsed time
    Process 32 Ran at 642ms elapsed time
    Process 33 Ran at 674ms elapsed time
    Process 34 Ran at 682ms elapsed time
    Process 35 Ran at 711ms elapsed time
    Process 36 Ran at 727ms elapsed time
    Process 37 Ran at 743ms elapsed time
    Process 38 Ran at 774ms elapsed time
    Process 39 Ran at 796ms elapsed time
    Process 40 Ran at 812ms elapsed time
    Process 41 Ran at 827ms elapsed time
    Process 42 Ran at 843ms elapsed time
    Process 43 Ran at 874ms elapsed time
    Process 44 Ran at 896ms elapsed time
    Process 45 Ran at 912ms elapsed time
    Process 46 Ran at 927ms elapsed time
    Process 47 Ran at 943ms elapsed time
    Process 48 Ran at 974ms elapsed time
    Process 49 Ran at 984ms elapsed time
    Process 50 Ran at 1012ms elapsed time
    Process ran 50 times, taking 1012ms

  17. #17

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    I guess when you look at this all day long you rather start making general assumptions about things. I do understand what you're all saying. I do and did realize that it takes longer than a ms for a tick. I did not realize that each tick could potentially take 16ms

    Like I said, I guess you kind of get into a zone where you just kind of assume or flat out expect things are going to work out based on what youve learned and read

    What I am doing is deciding whether or not I want a progressbar in an update procedure that runs after the 5k ms. Im thinking not at this point, seems to clunky.

  18. #18
    Super Moderator Shaggy Hiker's Avatar
    Join Date
    Aug 2002
    Location
    Idaho
    Posts
    38,988

    Re: Timer not acting as I expect

    Seemed worthless to begin with. No human can resolve things down to the millisecond. Hundredths of a second are just a blur, and tenths of a second are about all we can handle. Therefore, you can set your interval to 100 and think about things in tenths of a second. If ALL you are doing is updating a progress bar, that's plenty fast enough. Any faster will be lost on the user, so don't bother. Heck, your screen may have a 60Hz refresh rate to begin with, in which case you can't physically draw faster than that. You can draw slower, but you can't meaningfully draw faster.

    So, if you are doing something that does NOT involve the UI, then you can think about faster speeds, but for UI work, anything faster than 100 ms is almost certainly going to be lost on the user. Some animation has to go faster, but not on Windows Forms, generally.
    My usual boring signature: Nothing

  19. #19

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    The IDE states the tick is a ms.
    I believed it.
    Perhaps it should read more like "This will take a ms, but not really" followed by a wink emoji for good measure.

  20. #20
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: Timer not acting as I expect

    My advice is to set the ProgressBar to use its animated "Marquee" mode if you know the process will take "some time" but you don't have a good way to determine just how much.

    Here's how to think about it from a UX perspective.

    What do people hate about progress bars? When they lie. But this is a little wonky. There have been studies about progress bars, and what the study found is people are "happiest" when the progress bar starts out filling really slowly, then fills in faster towards the end. So we like for them to lie "the right way" when they fill up. It turns out people feel "meh" about progress bars that move at consistent speeds.

    Also interesting: no matter how the progress bar fills up, participants strongly dislike it when the bar hits "full" and doesn't immediately go to the next thing. Immediately. Any perceptible delay at all made people very upset.

    That means there's a set of rules we tend to want to follow if we have the luxury of time for our progress bar:
    • It is best if we can make our progress bar fill up slowly at first, then get faster as the task nears completion.
    • People respond very negatively to bars that speed up then slow down, it is better to not speed up.
    • At all costs we should make sure the bar only says 100% if it means it is done.

    To satisfy all of those desires, you have to know a lot about the task you're accomplishing. You have to know for sure when to set that dang thing to 100%.

    But if your behavior is "it takes roughly 5 seconds, sometimes more, sometimes less", you can't do all of those things. You can't "get faster without slowing down" and "hit 100% at the right time" if you aren't 100% sure when the end will occur.

    In those cases, it's best to use animations like the ProgressBar's "Marquee" mode to indicate what we call "indeterminate time". It tells the user, "I am busy, but I don't have a reasonable way to tell you how long this will take." Obviously this isn't as "happy" as having a real progress bar. But it turns out people like these better than progress bars that move slowly and don't mean "done" at 100%.

    In terms of intervals, the rule of thumb I've seen is that 250ms is generally so fast no one in any study perceives it as "a delay". 500ms is around where most participants will report "not instantaneous". When Microsoft was designing the APIs for WinRT, which was the foundations for what became UWP, they used this rule of thumb. Any API that could conceivably take 250ms or more to respond was required to be asynchronous. This helps warn us as developers we need to consider busy indicators for those actions. Not many of them support the IProgress method for reporting progress. So the "spinning circle" is what people tend to use.

    And really, that's what you have here. The app is busy. Ages ago, you'd have changed the mouse cursor to the hourglass. I'm not sure why that fell out of fashion, it was dang easy and it conveyed a very clear message. "I'm busy, I don't know how long it will be. Watch this animation as proof the system hasn't hung."
    Last edited by Sitten Spynne; Dec 6th, 2017 at 04:14 PM.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  21. #21
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: Timer not acting as I expect

    All the IDE "says" in regards to the interval property is "The frequency of Elapsed events in milliseconds." And generally speaking, that's true. Also note that the default is 100.

    And yet the documentation says:
    Quote Originally Posted by MSDN
    Important
    The System.Timers.Timer class has the same resolution as the system clock. This means that the Elapsed event will fire at an interval defined by the resolution of the system clock if the Interval property is less than the resolution of the system clock. For more information, see the Interval property.
    https://msdn.microsoft.com/en-us/lib...v=vs.110).aspx

    ... For more information, see the Interval property....

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  22. #22
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: Timer not acting as I expect

    Also yes, TG, this is one of the places where the API is confusing and you really have to dig into the documentation to have a full handle.

    I think it would be smart if the Timer class clamped the value to about 20ms, and threw an exception if you tried to set it much lower. Most of the use cases where you really NEED a higher interval aren't served well by WinForms anyway.

    Thing is, WinForms is old as dirt and this is "for historical reasons". When the Timer class was created, Windows applications were written in C and if someone said "the system clock frequency" you knew exactly what it meant. This Timer class is a wrapper around that, and intended for people who aren't low-level operators. And it's not really easy to decide what "the system clock" means, because intuitively speaking you'd think an 8-core 4GHz system would have at worst 4GHz clock, not a 60Hz one, right? Somewhere in the years between Windows 3 and .NET we quit explaining exactly what "the system clock" meant.
    Last edited by Sitten Spynne; Dec 6th, 2017 at 04:24 PM.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  23. #23

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    "The frequency of Elapsed events in milliseconds."
    Is there an advantage to dragging a timer on the form vs creating one programmatically ?
    I see where you read this, but you have to plop a control to see the default property.
    If you hover over the Interval property where you initialize it in code it will read something a bit different.

  24. #24
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: Timer not acting as I expect

    MSDN represents the most up-to-date version of the documentation, and is sometimes a little different than what the IDE reports.

    The IDE is pulling information that's compiled into the DLLs that ship with the .NET Framework, which might be out of date even before the Framework releases! In general, they don't conflict with each other, but when they clash I don't trust either and write small programs to see what really happens.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  25. #25

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    aren't served well by WinForms
    I think i am going to stop procrastinating and make the jump to WPF

  26. #26

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    Sitten, i just seen your post#20 and will review it tomorrow. im leaving for the day

    Also, it's not too often I need to consult MSDN for deep dives. This would have been one of them, I simply cant do that while im on the clock. I figured it would be faster to pick your brains.

  27. #27
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: Timer not acting as I expect

    I wouldn't necessarily say WPF handles those cases better. What WPF does provide is a native animation library that can animate at 60FPS and interpolate frames if your system slows down.

    But realistically speaking in terms of the kinds of Applications both WinForms and WPF were designed for, there is never a sane reason to want a timer ticking faster than about 250ms.

    These frameworks are for "line of business" applications. That means sticking a lot of boring text boxes on the screen and displaying mountains of boring data to users. In that kind of application, it's rare that you want to update the screen more than once or twice per second. Any faster, and the user doesn't have a chance to read the last set of data before you display the next. What's the point of a fancy odometer-style counter if the user can't see the numbers? When data changes that quickly, it's best to switch to a graph. Even then, seriously look at Task Manager. It generally updates once per second, and you don't lose much from it.

    The kinds of applications that really want faster-than-100ms timers tend to be games or specific multimedia applications like video editors. The most appropriate frameworks for those tend to require you to write a lot more code, but they also provide more fine-grained tools for controlling your framerate.

    I've seen applications that require nanosecond precision. They don't run on Windows, the overhead of multitasking is just too great. Those run on a special "real-time OS" that only runs one program at a time so they can use the full might of the system, and their clocks come from specific and expensive hardware because PC clocks simply aren't accurate enough for that kind of work.

    Odds are 90% of what you're doing is "line of business" and if the Timer threw an exception for an interval < 100ms you'd still be able to do everything you want. If you want to write games, I strongly recommend either giving up on "fast framerates" or finding a game engine, which will involve pretty much abandoning VB. I suppose you can get by in Unity with VB, but good luck finding examples.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  28. #28

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    there is never a sane reason to want a timer ticking faster than about 250ms
    I think that it depends on what you are sampling, or relativity. realistically if 1 tick = 1ms then i would have had a pretty dang smooth prgressbar.

  29. #29
    PowerPoster jdc2000's Avatar
    Join Date
    Oct 2001
    Location
    Idaho Falls, Idaho USA
    Posts
    2,392

    Re: Timer not acting as I expect

    For operations where I don't know how long they will take to complete, especially those where I don't have any control over the interval, I generally use some sort of text type message indicating how things are going.

    Examples:

    Processing 1 of 5000 items
    Updating file 123456.txt

    Maybe with a Marquee progress bar.

  30. #30
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,297

    Re: Timer not acting as I expect

    Quote Originally Posted by kpmc View Post
    The IDE states the tick is a ms.
    No, it states that the Interval is measured in milliseconds. The documentation, which is what you should have read the moment things didn't work the way you expected, says this about the WinForms Timer class:
    The Windows Forms Timer component is single-threaded, and is limited to an accuracy of 55 milliseconds. If you require a multithreaded timer with greater accuracy, use the Timer class in the System.Timers namespace.
    If you follow the link to that Timers.Timer class doco then you get what tg posted earlier:
    The System.Timers.Timer class has the same resolution as the system clock. This means that the Elapsed event will fire at an interval defined by the resolution of the system clock if the Interval property is less than the resolution of the system clock. For more information, see the Interval property.
    If you follow the link to the Interval property documentation then you get this:
    You use the Interval property to determine the frequency at which the Elapsed event is fired. Because the Timer class depends on the system clock, it has the same resolution as the system clock. This means that the Elapsed event will fire at an interval defined by the resolution of the system clock if the Interval property is less than the resolution of the system clock. The following example sets the Interval property to 5 milliseconds. When run on a Windows 7 system whose system clock has a resolution of approximately 15 milliseconds, the event fires approximately every 15 milliseconds rather than every 5 milliseconds.
    You could have found that for yourself simply by using the Help menu in VS. It's called the "Help" menu for a reason.

  31. #31
    You don't want to know.
    Join Date
    Aug 2010
    Posts
    4,578

    Re: Timer not acting as I expect

    Quote Originally Posted by kpmc View Post
    I think that it depends on what you are sampling, or relativity. realistically if 1 tick = 1ms then i would have had a pretty dang smooth prgressbar.
    My experience with low-interval timers is instead of a dang smooth progress bar you'd have "a frozen UI due to completely saturated UI thread". If it took 3ms to get to the part where you change the ProgressBar value, you'd accumulate 3 events before the first render loop. Processing those 3 events adds 9 to the queue after the WM_PAINT. If painting the ProgressBar takes 2ms, that's another 2 ticks. We've rendered 1 frame and we're 11 ticks behind. Processing 11 ticks makes a new WM_PAINT, but by the time you get to it 33 are in the queue. It gets worse and worse each iteration.

    Events are processed FIFO and in the order of their arrival. If you Tick multiple times while painting, each of the Tick events has to be handled before a Paint event can be handled again. This is just how Windows API works.

    If you need to acquire data at faster than 16ms, you're better off working with different mechanisms. I worked at one of the nation's largest test and measurement companies for more than 5 years, we sold plenty of devices capable of sampling at high Ghz intervals: but you had to pony up for expensive cards to get that kind of resolution.

    There are some higher-resolution multimedia timers I haven't experimented with, but I have a hunch the overhead of P\Invoke will nullify most of the gains you might see. I never quite could find a part of the documentation that narrowed down what their resolution was. "Millisecond loops" aren't what Windows API was designed for.
    Last edited by Sitten Spynne; Dec 6th, 2017 at 07:39 PM.
    This answer is wrong. You should be using TableAdapter and Dictionaries instead.

  32. #32

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    You're right jmc, i refer to the documentation moving forward, thank you.

  33. #33
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    6,582

    Re: Timer not acting as I expect

    Quote Originally Posted by Sitten Spynne View Post
    ...
    Events are processed FIFO and in the order of their arrival. If you Tick multiple times while painting, each of the Tick events has to be handled before a Paint event can be handled again. This is just how Windows API works.
    ...
    While your point about events is generally true, a Timer doesn't quite work the way you state. A timer will trigger an event, but the timer has to be rearmed in order to generate another event. This is done automatically with the winform timer component, but will only do that as part of the event handler. If you don't process the event, the timer won't be rearmed so won't generate another event. I've done a lot of intense graphic things, and had a timer running and have never had timers attempt to catch up, i.e. they don't stack events on the event queue. When you get done holding up the GUI with your drawing, or whatever intense processing you're doing, and then get around to the tick event, the timer will be rearmed and you'll carry on, essentially loosing whatever number of timer ticks that would have occurred while you were busy.

  34. #34
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,297

    Re: Timer not acting as I expect

    Quote Originally Posted by passel View Post
    While your point about events is generally true, a Timer doesn't quite work the way you state. A timer will trigger an event, but the timer has to be rearmed in order to generate another event. This is done automatically with the winform timer component, but will only do that as part of the event handler. If you don't process the event, the timer won't be rearmed so won't generate another event. I've done a lot of intense graphic things, and had a timer running and have never had timers attempt to catch up, i.e. they don't stack events on the event queue. When you get done holding up the GUI with your drawing, or whatever intense processing you're doing, and then get around to the tick event, the timer will be rearmed and you'll carry on, essentially loosing whatever number of timer ticks that would have occurred while you were busy.
    I actually thought the same as Sitten Spynne and thought that I'd actually seen that behaviour in the past but I just did a bit of testing and can confirm what you say. Interesting.

  35. #35
    PowerPoster PlausiblyDamp's Avatar
    Join Date
    Dec 2016
    Location
    Pontypool, Wales
    Posts
    2,458

    Re: Timer not acting as I expect

    Quote Originally Posted by passel View Post
    While your point about events is generally true, a Timer doesn't quite work the way you state. A timer will trigger an event, but the timer has to be rearmed in order to generate another event. This is done automatically with the winform timer component, but will only do that as part of the event handler. If you don't process the event, the timer won't be rearmed so won't generate another event. I've done a lot of intense graphic things, and had a timer running and have never had timers attempt to catch up, i.e. they don't stack events on the event queue. When you get done holding up the GUI with your drawing, or whatever intense processing you're doing, and then get around to the tick event, the timer will be rearmed and you'll carry on, essentially loosing whatever number of timer ticks that would have occurred while you were busy.
    I always assumed this was the case because of how the WM_TIMER messages get generated https://blogs.msdn.microsoft.com/old...28-00/?p=91501

  36. #36
    Sinecure devotee
    Join Date
    Aug 2013
    Location
    Southern Tier NY
    Posts
    6,582

    Re: Timer not acting as I expect

    Quote Originally Posted by PlausiblyDamp View Post
    I always assumed this was the case because of how the WM_TIMER messages get generated https://blogs.msdn.microsoft.com/old...28-00/?p=91501
    I'm sure that your link is a more accurate description of the mechanism. I worked with some embedded realtime systems in the 80's and what is described in your link is the distinction between a message entrance, and an event entrance in those systems (PSOS and PDOS on Motorola 680xx boards). Messages queued up, and events just set a flag. If your processing was slow, the event that caused the flag to be set could have occurred multiple times, but you only get one notification when you finally get around to processing the event.

    I thought about mentioning the use of flagged events instead messaged based events, but wasn't sure if that was the mechanism used (didn't know about WM_TIMER and didn't try to look it up). I was pretty sure that other API timers did work as I described, needing to be rearmed, so misapplied that mechanism to the way the WinForm timer worked. My mistake.

  37. #37

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    You could have found that for yourself simply by using the Help menu in VS. It's called the "Help" menu for a reason.
    Been thinking about this, and the few persons I've run into on various forums that point this out pretty much on every thread. My first reaction is "Thank you captain obvious!"

    Maybe my idea of a forum differs from others, but how I feel is- I've read a ton of MSDN, you've read a ton of MSDN so lets save ea. other some time and discuss. Also "Help" doesn't offer any type of human element, no opinions, no interactions, no past experiences, no emotions, quite simply....it's boring.

    If everyone refereed to MSDN and "Help" then we wouldnt have a use for this forum, or in the least would have very little to talk about. This thread as an example, I have learned a great deal more about the timer than your Help article could ever provide.

    All that being said, I think I will continue to ask questions here and stir up conversation where applicable regardless that the cut and dry content exists in a help file.

  38. #38
    Super Moderator jmcilhinney's Avatar
    Join Date
    May 2005
    Location
    Sydney, Australia
    Posts
    110,297

    Re: Timer not acting as I expect

    Quote Originally Posted by kpmc View Post
    My first reaction is "Thank you captain obvious!"
    It's obvious, yet people don't do it.
    Quote Originally Posted by kpmc View Post
    Maybe my idea of a forum differs from others
    I'm not the king of this forum or any other so I don't get to decide what they are or are not, but my opinion is that they are for things that you can't work out on your own. Something that can be answered in a couple of minutes doesn't qualify as something that you can't work out on your own.
    Quote Originally Posted by kpmc View Post
    how I feel is- I've read a ton of MSDN, you've read a ton of MSDN so lets save ea. other some time and discuss.
    If you have something to discuss then by all means let's discuss it. You can do that without asking questions that you could easily answer for yourself with a couple of minutes of effort.
    Quote Originally Posted by kpmc View Post
    Also "Help" doesn't offer any type of human element, no opinions, no interactions, no past experiences, no emotions, quite simply....it's boring.
    If you don't want to do things that are boring from time to time then give up programming now. If you can get bored after reading documentation for a few minutes and that is too much to take then you probably have something diagnosable.
    Quote Originally Posted by kpmc View Post
    If everyone refereed to MSDN and "Help" then we wouldnt have a use for this forum, or in the least would have very little to talk about.
    That's simply not the case. I have answered many, many questions without making reference to the documentation because they were difficult questions that couldn't easily be answered with a quick read and a few clicks. This one was not one of those.
    Quote Originally Posted by kpmc View Post
    This thread as an example, I have learned a great deal more about the timer than your Help article could ever provide.
    Like I said, you can have discussions on plenty of topics that will be useful and interesting but they don't have to be prompted by questions that you can easily answer for yourself. Also, I've learned loads by reading the documentation too. Many a time I have gone looking for something and found something else interesting and/or useful either then or later.
    Quote Originally Posted by kpmc View Post
    All that being said, I think I will continue to ask questions here and stir up conversation where applicable regardless that the cut and dry content exists in a help file.
    You do what you think is right and I expect that I'll reply to some/many of your questions without mentioning the documentation but if I think that you've posted an easy one because you were too lazy to look it up, don't be surprised if I point that out. Your free to ignore such posts if you want to or not.

  39. #39
    Smooth Moperator techgnome's Avatar
    Join Date
    May 2002
    Posts
    34,531

    Re: Timer not acting as I expect

    Quote Originally Posted by kpmc View Post
    Been thinking about this, and the few persons I've run into on various forums that point this out pretty much on every thread. My first reaction is "Thank you captain obvious!"

    Maybe my idea of a forum differs from others, but how I feel is- I've read a ton of MSDN, you've read a ton of MSDN so lets save ea. other some time and discuss. Also "Help" doesn't offer any type of human element, no opinions, no interactions, no past experiences, no emotions, quite simply....it's boring.

    If everyone refereed to MSDN and "Help" then we wouldnt have a use for this forum, or in the least would have very little to talk about. This thread as an example, I have learned a great deal more about the timer than your Help article could ever provide.

    All that being said, I think I will continue to ask questions here and stir up conversation where applicable regardless that the cut and dry content exists in a help file.
    There's two sides to this. There's the "I tried XYZ and it didn't work, why?" ... which is what your post amounted to. You tried to use a timer in a particular way and it didn't quite work the way you wanted and was questioning why. The answer to that was in the documentation. Whether you looked for it, found it, and still didn't understand it, or simply didn't even bother to look for it, we don't know, but since you didn't mention the former, we assume the latter. I took the time to pull that piece out of MSDN. Didn't take me long either. Part of the other problem with the posts that they are largely based upon your assumptions, which you are now admitting may not be correct.
    You also stated "Also, it's not too often I need to consult MSDN for deep dives. This would have been one of them, I simply cant do that while im on the clock." But dragging us down the rabbit hole is OK? ... yeah, then that's a problem between you and your employer, and one you need to work out. If I couldn't consult MSDN every time I needed to, I wouldn't be able to do my job. Sorry, that's not a justifiable excuse in my book.

    the other side "I tried XYZ, it didn't work. When I looked at the documentation, it said, ABC, which seems to contradict XYZ, so now I'm confused. What gives?" ... That is how a conversation is started. Lay out ALL the facts. Not just the ones that suit you. That would have been a far better approach in this case... at least it would have shown you had taken the time to the research instead of forcing us to do it for you.

    -tg
    * I don't respond to private (PM) requests for help. It's not conducive to the general learning of others.*
    * I also don't respond to friend requests. Save a few bits and don't bother. I'll just end up rejecting anyways.*
    * How to get EFFECTIVE help: The Hitchhiker's Guide to Getting Help at VBF - Removing eels from your hovercraft *
    * How to Use Parameters * Create Disconnected ADO Recordset Clones * Set your VB6 ActiveX Compatibility * Get rid of those pesky VB Line Numbers * I swear I saved my data, where'd it run off to??? *

  40. #40

    Thread Starter
    Fanatic Member kpmc's Avatar
    Join Date
    Sep 2017
    Posts
    1,012

    Re: Timer not acting as I expect

    You also stated "Also, it's not too often I need to consult MSDN for deep dives. This would have been one of them, I simply cant do that while im on the clock."
    Right this is true, and we are far beyond the duration of time it would have taken me to read the entire class documentation researching the resolution of the interval.
    Again, now that I know this I would surly just answer someones question with exactly that. I dont expect anyone to research anything for me, I would think they would simply type what they know or move on.

    Either way, thank you all for this conversation, I rather enjoyed reading everyone's ideas.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  



Click Here to Expand Forum to Full Width