>>Hey Dudes,
>>
>>In one of my applications, I have TIMER objects constantly running code. (They
>>are constantly reading data from various probe hardware).
>>
>>Buttons on forms should always be usable while the TIMERs are running.
>>
>>In certain circumstances, it takes multiple attempts to click buttons on the forms before the button actually registers the click.
>>
>
>I'm not sure if this will fix the problem, but I'd recommend moving your updates into one timer. If you now have one timer for each probe and several probes, then you have alot of unnecessary timer overhead. Add a method and a "last run time" property for each probe. (Either subclass the timer or add them to your form) The Timer Event code checks to see if it's time to run each probe check and if so, calls the method and updates the "Last time run" property for that probe.
>You could put all of the code in the Timer Event, but using methods will make it easier to read and add new probes.
>Hopefully, reducing the number of running timers will free up the event loop and get your mouse clicks working.

Thanks for the info! We have some real short interval timers, 50 and 200 ms timers... So that we can continuously read from our probe-devices. They work good, although sometimes we have 2 timers running at once which I don't care for, but it seems to work ok. But it seems we should be able to streamline the code better to get faster response times, and maybe we wont need to have the timers run that quickly? Then maybe the buttons would work better?

Let me ask you something, in most cases I am assuming that with a 50ms timer, the timer is up before the timer-code is finished. Does that mean that the timer-code will re-run immediately, or not until the timer-code is finished, then it runs it again?

I think there is a lot of potential to clean up our code and make it run better/faster, especially with timers. I just need to understand them better.

Basically, we have one primary timer. the PROBE timer will read one probe, display its results, go to the next probe, read it, display the results, and so on until all probes are read and displayed, then it starts over again at PROBE 1. So there really is only the one timer. We also have a 'pedal timer' that reads from a foot pedal, which can run at the same time, that slows things down I bet.

Increasing the timer to 1000-2000 ms from 200ms seems to work great for our slower probes, and make the buttons work more responsively... but it may slow
down the display-screen of the probes, and people want to see the value that the probes are reading as fast as possible.

Thanks!
Seth