Timer Events

Collapse
This topic is closed.
X
X
Collapse
 
  • Page of 1
  • Time
  • Show
Clear All
new posts
Previous template Next
  • Max
    #1

    Timer Events

    This may be an elementary question but it's something I have not encountered
    in about 10 years writing code in VB 5 / 6

    I have a timer that using the API checks if there has been a change to one
    of several watched directories in the file system, if there has been a
    change a rather long running process is started.

    The long running process loops through all files comparing the last modified
    attributes on each to those in the database if there is a change the
    database is updated.

    Simple so far right ?

    Just prior to the loop statement in that routine there is a DoEvents to keep
    everything ticking along, however something interesting happens.

    I have another timer on a very short interval watching for something else to
    happen. This something else is unrelated to the file system, it is updating
    the status of an out of process com component.

    This second timer is not firing while the long running process is taking
    place, the do events is working because the status of the long running
    process is updated in the status bar of the application and that works.

    Is there a rule that I have missed that says only one timer event can be
    running at any one time ?

    Come to think of it over the years I have only ever put very short routines
    in timers so have never faced such a problem.

    I can think of a few ways to get around this but am wondering if you agree
    with my reasoning?

    All the best for the new year

    Max


    Tags: None
    • Ralph
      #2
      Re: Timer Events


      "Max" <nospam@spamcat chers.comwrote in message
      news:4598fc4c$0 $5748$afc38c87@ news.optusnet.c om.au...
      This may be an elementary question but it's something I have not
      encountered
      in about 10 years writing code in VB 5 / 6
      >
      I have a timer that using the API checks if there has been a change to one
      of several watched directories in the file system, if there has been a
      change a rather long running process is started.
      >
      The long running process loops through all files comparing the last
      modified
      attributes on each to those in the database if there is a change the
      database is updated.
      >
      Simple so far right ?
      >
      Just prior to the loop statement in that routine there is a DoEvents to
      keep
      everything ticking along, however something interesting happens.
      >
      I have another timer on a very short interval watching for something else
      to
      happen. This something else is unrelated to the file system, it is
      updating
      the status of an out of process com component.
      >
      This second timer is not firing while the long running process is taking
      place, the do events is working because the status of the long running
      process is updated in the status bar of the application and that works.
      >
      Is there a rule that I have missed that says only one timer event can be
      running at any one time ?
      >
      Come to think of it over the years I have only ever put very short
      routines
      in timers so have never faced such a problem.
      >
      I can think of a few ways to get around this but am wondering if you agree
      with my reasoning?
      >
      All the best for the new year
      >
      Max
      >
      The short answer is no - there is no 'rule' that says you can't have more
      than one timer running at a time. However, you can occasionally arrange
      things such that you can experience 'unexpected' behavior. <g>

      As Timers are not hard interupts and a Timer event has to wait for its turn
      to run, just like any other event, a long running process in one timer can
      definitely effect results. The usual fix is to install judicious DoEvents in
      a long running process - it sounds like you have tried that. You may just
      need to do some re-arranging.

      Without knowing more about your particular situation I wouldn't venture a
      specific solution. But you can take heart that one is likely possible.

      As a sidenote: Just in case, be aware that timers act differently when run
      in debug mode (in an IDE) than when released. They also can react strangely
      with MsgBoxes/Modal dialogs. So do your testing with release versions and
      monitor the behavior with logs or DebugOutputStri ng and DebugViewers.

      Placing Timers in a Control Array and thus having only one event (point of
      entry)can often simplify the coding and make it easier to monitor the
      behavior.

      At the other end of the spectrum you might consider reworking your
      application to using FindFirstChange Notification/FindNextChangeN otification
      functions with the WaitForMultiple Objects function, and eliminate one of the
      timers entirely.

      hth
      -ralph







        Comment

        • Steve Gerrard
          #3
          Re: Timer Events


          "Max" <nospam@spamcat chers.comwrote in message
          news:4598fc4c$0 $5748$afc38c87@ news.optusnet.c om.au...
          >
          This second timer is not firing while the long running process is taking
          place, the do events is working because the status of the long running process
          is updated in the status bar of the application and that works.
          >
          I would bet that the second timer is firing with each DoEvents (unless you just
          have the code mangled up).

          It is more likely that it is is firing, but you are not seeing the out of
          process component updated as you expect.

          It should be easy to put in a visual queue that the second short timer is indeed
          firing during the long loop - a debug statement, a character added to a text box
          on a form, whatever works.

          You might well find that the issue is more to do with the out of process
          component not getting any processing time to update itself, since your app is so
          busy when it is in the long loop.


            Comment

            • Max
              #4
              Re: Timer Events

              Thanks Ralph

              I will look at the re working of the code you have given me some good ideas
              there and thanks for the tip on the different behaviour when running in the
              IDE.

              The app is one that has grown over the past 6 years and could do with a good
              rethink.


              Max

              "Ralph" <nt_consulting6 4@yahoo.comwrot e in message
              news:Gd2dnS7bK4 GZtQTYnZ2dnUVZ_ rOqnZ2d@arkansa s.net...
              >
              "Max" <nospam@spamcat chers.comwrote in message
              news:4598fc4c$0 $5748$afc38c87@ news.optusnet.c om.au...
              >This may be an elementary question but it's something I have not
              encountered
              >in about 10 years writing code in VB 5 / 6
              >>
              >I have a timer that using the API checks if there has been a change to
              >one
              >of several watched directories in the file system, if there has been a
              >change a rather long running process is started.
              >>
              >The long running process loops through all files comparing the last
              modified
              >attributes on each to those in the database if there is a change the
              >database is updated.
              >>
              >Simple so far right ?
              >>
              >Just prior to the loop statement in that routine there is a DoEvents to
              keep
              >everything ticking along, however something interesting happens.
              >>
              >I have another timer on a very short interval watching for something else
              to
              >happen. This something else is unrelated to the file system, it is
              updating
              >the status of an out of process com component.
              >>
              >This second timer is not firing while the long running process is taking
              >place, the do events is working because the status of the long running
              >process is updated in the status bar of the application and that works.
              >>
              >Is there a rule that I have missed that says only one timer event can be
              >running at any one time ?
              >>
              >Come to think of it over the years I have only ever put very short
              routines
              >in timers so have never faced such a problem.
              >>
              >I can think of a few ways to get around this but am wondering if you
              >agree
              >with my reasoning?
              >>
              >All the best for the new year
              >>
              >Max
              >>
              >
              The short answer is no - there is no 'rule' that says you can't have more
              than one timer running at a time. However, you can occasionally arrange
              things such that you can experience 'unexpected' behavior. <g>
              >
              As Timers are not hard interupts and a Timer event has to wait for its
              turn
              to run, just like any other event, a long running process in one timer can
              definitely effect results. The usual fix is to install judicious DoEvents
              in
              a long running process - it sounds like you have tried that. You may just
              need to do some re-arranging.
              >
              Without knowing more about your particular situation I wouldn't venture a
              specific solution. But you can take heart that one is likely possible.
              >
              As a sidenote: Just in case, be aware that timers act differently when run
              in debug mode (in an IDE) than when released. They also can react
              strangely
              with MsgBoxes/Modal dialogs. So do your testing with release versions and
              monitor the behavior with logs or DebugOutputStri ng and DebugViewers.
              >
              Placing Timers in a Control Array and thus having only one event (point of
              entry)can often simplify the coding and make it easier to monitor the
              behavior.
              >
              At the other end of the spectrum you might consider reworking your
              application to using
              FindFirstChange Notification/FindNextChangeN otification
              functions with the WaitForMultiple Objects function, and eliminate one of
              the
              timers entirely.
              >
              hth
              -ralph
              >
              >
              >
              >
              >
              >
              >

                Comment

                • Max
                  #5
                  Re: Timer Events

                  Thanks Steve,

                  I had a break in the 2nd timer event that was not being hit but I will do
                  the visual test. and run it as an EXE

                  The out of process component is media player and the audio is playing
                  without a hiccup however your suggestion my be correct it that its not
                  returning it's position because there is no processor time.

                  All the best


                  Max

                  "Steve Gerrard" <mynamehere@com cast.netwrote in message
                  news:0OidnXeP9Y Cb3wTYnZ2dnUVZ_ oytnZ2d@comcast .com...
                  >
                  "Max" <nospam@spamcat chers.comwrote in message
                  news:4598fc4c$0 $5748$afc38c87@ news.optusnet.c om.au...
                  >>
                  >This second timer is not firing while the long running process is taking
                  >place, the do events is working because the status of the long running
                  >process is updated in the status bar of the application and that works.
                  >>
                  >
                  I would bet that the second timer is firing with each DoEvents (unless you
                  just have the code mangled up).
                  >
                  It is more likely that it is is firing, but you are not seeing the out of
                  process component updated as you expect.
                  >
                  It should be easy to put in a visual queue that the second short timer is
                  indeed firing during the long loop - a debug statement, a character added
                  to a text box on a form, whatever works.
                  >
                  You might well find that the issue is more to do with the out of process
                  component not getting any processing time to update itself, since your app
                  is so busy when it is in the long loop.
                  >
                  >

                    Comment

                    Previous template Next
                    Working...