From: nt_consulting64@yahoo.com   
      
   "Max"  wrote in message   
   news:4598fc4c$0$5748$afc38c87@news.optusnet.com.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.    
      
   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   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)