0
votes

I have an old VB6 application that has a timer issue. There is a modal form that contains some elements and two timers (VB6 standard timers). Each timer works like this (pseudo code):

-- TimerEvent Start 
DoSomething
DoEvents
-- TimerEvent End

Then, at some point in time, an event from an OCX control is raised that some connection is lost. Is has nothing to do with the timer itself. But at this point, the timer event is not raised anymore for both timers although - now the weird stuff - the timers are enabled and have an interval of 2000 set. Even re-enabling and re-setting the interval does not have any effect. When another event from the same OCX control is raised that the connection was restored, the timer event is suddenly raised again. Even if removing all the code in the OCX control event handlers, the timers are not working.

I am not very familiar with the DoEvents "pattern" but I assume the issue must be related with the DoEvents. Removing this did not change anything.

Has anyone an idea what could happen here? I already looked for any global setting that would prevent the timer from raising the elapsed event but for god's sake I couldn't find any.

I am going crazy on this...

Thank you for any help.

1
I very much doubt the problem is in the code you quoted. Rather, I suspect the OCX control is written in C/C++ and messes with the application's message pump directly in such a way that it breaks your timers. - pmdj
it's been a while, but DoEvents is basically for emptying the event queue when you're blocking the main thread for a long time. I'm not sure on its exact effect - I do know that in some cases calling DoEvents multiple times in a row was necessary. Its main use is to keep drawing the UI and responding to user input while performing longer-running processing. I'm not sure why you'd call it at the END of an event handler though, I don't think it will realistically have any effect there. - pmdj
Your problem is likely down to the OCX calling GetMessage() somewhere and consuming your timer event. I suspect, but don't know for sure, that the VB6 timer just uses WM_TIMER underneath. Maybe the OCX, which by the sound of it is a networking library or so, uses a WM_TIMER for its timeout internally, and incorrectly interprets the VB6 timer's message as its own timeout message. - pmdj
It's been a while since I touched VB6, but usually you didn't get yourself into such a mess with VB alone - it's almost always an external C library. Good luck! - pmdj
The Timer does indeed use WM_TIMER under the covers and those messages could be consumed I suppose. Calling DoEvents gets and dispatches any messages in the current thread's windows message queue until it is empty. It should be avoided because it can cause re-entrancy problems. - tcarvin

1 Answers

0
votes

sorry for the late response.

It was a timing problem inside another timer. This other timer pings another IP with a ping timeout of 200ms. This timers interval is 200ms. So if the ping times out (because the other machine is disconnected), the timer is firing more often than it can be processed. So it's messing up the event queue and blocking all other timers from firing. By increasing the timer interval to 1000ms it worked although a better solution would be to stop the timer, process the event and then restart the timer.

Thanks for the helpful hints!