Login or Sign up Help | Site Map
Connecting Tech Pros Worldwide

Timer Events

Question posted by: Max (Guest) on January 1st, 2007 11:25 AM
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


Would you like to answer this question?
Sign up for a free account, or Login (if you're already a member).
Ralph's Avatar
Ralph
Guest
n/a Posts
January 1st, 2007
02:35 PM
#2

Re: Timer Events

"Max" <nospam@spamcatchers.comwrote in message
news:4598fc4c$0$5748$afc38c87@news.optusnet.com.au ...
Quote:
Originally Posted by
This may be an elementary question but it's something I have not

encountered
Quote:
Originally Posted by
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
Quote:
Originally Posted by
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
Quote:
Originally Posted by
everything ticking along, however something interesting happens.
>
I have another timer on a very short interval watching for something else

to
Quote:
Originally Posted by
happen. This something else is unrelated to the file system, it is

updating
Quote:
Originally Posted by
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
Quote:
Originally Posted by
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 DebugOutputString 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 FindFirstChangeNotification/FindNextChangeNotification
functions with the WaitForMultipleObjects function, and eliminate one of the
timers entirely.

hth
-ralph








Steve Gerrard's Avatar
Steve Gerrard
Guest
n/a Posts
January 1st, 2007
04:25 PM
#3

Re: Timer Events

"Max" <nospam@spamcatchers.comwrote in message
news:4598fc4c$0$5748$afc38c87@news.optusnet.com.au ...
Quote:
Originally Posted by
>
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.



Max's Avatar
Max
Guest
n/a Posts
January 1st, 2007
06:35 PM
#4

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@comcast.netwrote in message
news:0OidnXeP9YCb3wTYnZ2dnUVZ_oytnZ2d@comcast.com. ..
Quote:
Originally Posted by
>
"Max" <nospam@spamcatchers.comwrote in message
news:4598fc4c$0$5748$afc38c87@news.optusnet.com.au ...
Quote:
Originally Posted by
>>
>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.
>
>




Max's Avatar
Max
Guest
n/a Posts
January 1st, 2007
06:35 PM
#5

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_consulting64@yahoo.comwrote in message
news:Gd2dnS7bK4GZtQTYnZ2dnUVZ_rOqnZ2d@arkansas.net ...
Quote:
Originally Posted by
>
"Max" <nospam@spamcatchers.comwrote in message
news:4598fc4c$0$5748$afc38c87@news.optusnet.com.au ...
Quote:
Originally Posted by
>This may be an elementary question but it's something I have not

encountered
Quote:
Originally Posted by
>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
Quote:
Originally Posted by
>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
Quote:
Originally Posted by
>everything ticking along, however something interesting happens.
>>
>I have another timer on a very short interval watching for something else

to
Quote:
Originally Posted by
>happen. This something else is unrelated to the file system, it is

updating
Quote:
Originally Posted by
>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
Quote:
Originally Posted by
>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 DebugOutputString 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
FindFirstChangeNotification/FindNextChangeNotification
functions with the WaitForMultipleObjects function, and eliminate one of
the
timers entirely.
>
hth
-ralph
>
>
>
>
>
>
>




 
Not the answer you were looking for? Post your question . . .
182,493 Experts ready to help you find a solution.
Sign up for a free account, or Login (if you're already a member).

  • Didn't find the answer you were looking for?
    Post Your Question
  • Top Community Contributors