>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.
>
>HOWEVER, by clicking both the LEFT and RIGHT buttons on the mouse at-the-same-time, yields 100% success rate every time! Strange!
>
>Upon further testing, the RIGHT mouse button always seems to select the button properly, while the LEFT mouse button clicks it and gets the button to work.
>
>So I figure that the RIGHT button is the key instrument to getting this 100% button-clicking success rate.
>
>Any ideas why? Or how I can get the LEFT button to work 100% like the RIGHT button? I was thinking that maybe I could force a RIGHT-mouse-click everytime the user clicks the LEFT-mouse button. Any ideas if this is possible?
>
>Anyone else have encounters like this?
>Thanks for any help!
Today I did some tests on this, and the results may be of your interest.
Note : My test was done in VFP5 which will differ from VFP6 (SP4 ?) because of multi-threading overthere).
I've created a self-contained object (Class) consisting of a Container, an Image, and a Timer. I drag this class on a form as many times as I like;
The intention is to let them move from left to right on the form, and at the border reverse the other way. At the elapse of the timer the Left is incremented / decremented. All together it consumes about 10 lines of code i.e. by itself this moving object does very few.
At a click I can start and stop moving each of them.
The fact that it's more timers doesn't give any overhead at all.
Once the elapse of any of the Intervals isn't answered immeately goves loads of overhead. So, avoid this !!
N.b.: The elapsing is buffered once it can't be answered.
I did this on a 600 Mhz PIII and with an Interval of 60 ms all keeps on going smoothly with 60 of these objects; F.e. 40 ms gets things stressed, or better, gets the elapsing of the Timers buffered, giving the overhead.
I used the "CPU-meter" (? I have Dutch version) of NT4 (right-click on taskbar -> task list) which shows the cpu-usage. To my findings, you can get many of these objects running at 12 %, then it increases to 52 % where another lot can be added, an then it becomes critical; There is nothing in between 52 % and 98 % though many objects can be added again. I just stopped at 60 objects (at 60 ms Interval), and doing other stuff (I just did this within our app) is not allowed anymore; if you do, the Timers get buffered, and will never come back to "being in time" because of the added overhead from buffering.
Wheter the system is still enough responsive can be seen at the CPU-meter; once is flipping from 100 % to 98 % is just reacts, and no buffering takes place. Of course you see this on the objects smooth moving too;
Since our app uses office-97 buttons (custom-made) the MouseMove on these buttons also show everything still workes fine : the buttons become buttons when the mouse is over them immedeately, and disappear when the mouse is away.
The objects keep on moving smootly until 8 ms as long as there are few objects; under 8 ms they keep on running, but with hikups; this is not because they get buffered, by (IMO) because the timer can elapse before it's own code is finished (this is almost nothing, because the .Interval = 8 is the last line in the Timer-method).
Conclusion
The number of timers doesn't matter;
The elapsing of the timers being buffered should be avoided at all cost.
A timer is allowed to have 8 ms (at the 600 Mhz !)
The CPU-meter will show whether you did allright; a constant 100 % is not.
and
of course all depends on the code performed in the other (timer) tasks on the PC. So, my test performed a minimum.
Last notice :
The more timers you have, the greater the chance is that two elapse at exactly the same time. This again is the moment that one will be buffered, implying the relatively huge overhead. That this is true can be seen on the objects catching up with eachother. So, once one catches up another, they both elapsed at the same time, and the timeslice is given randomly. So it's no FIFO but random.
