VB6 Timers failing with Windows 7
We're at a loss here. We have a large VB6 app that has worked flawlessly for years in XP. We are now trying to run it on Windows 7. It works fine, but the VB timers randomly pause for a while and then restart by themselves. We have 4-8 timers in an app (multiple apps). The timers have different intervals, anywhere from 100 to 750. We log when we enter each timer and when it exits. They always enter and exit, but randomly, a timer (usually the same one) will not trigger for anywhere from 8 to 30 seconds later, once in a great while even longer. We have tried writing a simpler app with timers to reproduce the problem but have been unsucessful.
Any suggestions for where to look? has anyone heard of anyhting like this? We're suspecting something has changed in Win 7 because it has always worked with XP.
Re: VB6 Timers failing with Windows 7
welcome to the forums, avfadagio. :wave:
try reducing the amount of timers, set the timer to interval 100:
Code:
dim ticks as integer
Private Sub Timer1_Timer()
ticks = ticks + 1
Select Case ticks
Case 2
label1.caption = "200ms have passed since timer was enabled."
Case 4
label1.caption = "400ms have passed since timer was enabled."
Case 6
label1.caption = "600ms have passed since timer was enabled."
End Select
End Sub
sorry if codes are bad.. i currently don't have vb6 installed, moved on to .net.
Re: VB6 Timers failing with Windows 7
We actually did try combining some of the timers into one, but then that timer stopped for a while and restarted. I know it appears like some sort of code issue on our part. And it must be, but it has worked flawlessly in XP for years.
The timers are not executing code too long - maybe more than the 100 msec once in a while, but like I said it will pause for 20, 30 seconds or more.
We even created a watchdog timer and checked for if one of the other timers stops executing for more than 2 seconds and if so, we disable and enable the stuck timer, and then it starts running again! It's like the timer gets lost in the Windows que for a while. CPU usage is nominal, <5% usually.
Being a large and complex program it is hard to post any sample code
Re: VB6 Timers failing with Windows 7
well what i would do to fix such a problem would be looking at what enables the timer, and what the timer does, even if it worked on XP. if you use "on error resume next" i suggest you remove those and actually look for errors.
i can't think of anything else at the moment. if possible, it would help if you posted some piece of code.
Re: VB6 Timers failing with Windows 7
Thank you for your thoughts.
Ya, we're not finding anybody else with this problem, so unfortunately it must be our code somewhere. As I said, it is a large complex system so it's hard just to take out or stop pieces of it and still have it run to prove it is still failing. We've be working with VB 5 -6 since they came out so we're not beginners, but we're stumped on this one.
This program actually loads VB 6 ocx's in a VB 6 container app on the fly (I did not write that code so I am a bit fuzzy on how it is done), which may somehow be causing issues.
We will keep trying (we have to! it's our job) and I will certainly post once we resolve it.
If anyone has any other thoughts, I certainly will welcome them.
Re: VB6 Timers failing with Windows 7
The thing to remember about timers is that they are about the lowest priority message a window will receive (via the WM_TIMER message). Executing code & just about all messages sent from the system to your project will be processed ahead of the timer. This has the effect of a timer appearing paused/slow or skipping events.
Quote:
Originally Posted by msdn
The WM_TIMER message is a low-priority message. The GetMessage and PeekMessage functions post this message only when no other higher-priority messages are in the thread's message queue.
Re: VB6 Timers failing with Windows 7
Yet the other timers keep going. Seems like just one quits for a while.
We are using SS... objects a lot from Threed32.ocx. I notice Win 7 says those are not supported. (not sure what that means) We will try to remove some of those and see what happens.
Is there a utility or code to show the Windows message que to see if there are other messages being stacked up ahead?
Re: VB6 Timers failing with Windows 7
A timer doesn't just quit. It is either so far back in the queue that it appears stalled or some other code is actually terminating the timer or resetting it. Note that changing the .Interval or .Enabled properties while a timer is running will pause/stop the timer momentarily. If .Enabled is False, then stopped.
You could play with the PeekMessage API. Though I think that only applies to posted messages not messages inserted into the queue, at higher priorities, via the SendMessage family.
Though you may have 3 or 4 timers running, maybe one or more of the other OCXs you are using has a fast timer running also? The Spy++ app that came with VB can view/log messages as they come in. It has a filter where you can restrict to viewing just WM_TIMER messages for example. By filtering those, you can determine how many timers are currently running. Each WM_TIMER message has a unique ID that refers back to the actual timer sending the message (the 3rd parameter [wParam] in that message).
Edited: A timer is assigned to a specific window or no window. Knowing that, if you want to catch/log all timer messages, you'll want to set Spy++ viewing processes vs. windows. Find the process for your project/app, then view that process' messages. Otherwise, you'll have to target specific windows to view their specific messages
Re: VB6 Timers failing with Windows 7
We used SPYxx to display our messages. (Not an expert by any means here) Here is a snapshot of what we are seeing. It seems as if the timer message is happening, but the event does not fire. Is this possible?
In the example below, our timer that quits is timerID 787784. Notice that in the first chunk, right after the timer message, there is a paint, erasebkgrnd, etc. which is our text box flashing. But the second example shows the timer, then no paint. This corresponds with us not seeing the timer event happen.
Where do we look next?
<17560> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17561> 0009058C P WM_TIMER wTimerID:591244 tmprc:00000000 [wParam:0009058C lParam:00000000]
<17562> 00090298 P WM_TIMER wTimerID:590488 tmprc:00000000 [wParam:00090298 lParam:00000000]
<17563> 00090384 P WM_TIMER wTimerID:0 tmprc:6DF73DCE [wParam:00000000 lParam:6DF73DCE]
<17564> 000805FC P WM_TIMER wTimerID:525820 tmprc:00000000 [wParam:000805FC lParam:00000000]
<17565> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17566> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17567> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F154
<17568> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17569> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17570> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17571> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F158
<17572> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17573> 000C02F0 P WM_TIMER wTimerID:787184 tmprc:00000000 [wParam:000C02F0 lParam:00000000]
<17574> 000D01F2 P WM_PAINT hdc:00000000 [wParam:00000000 lParam:00000000]
<17575> 000D01F2 S ..WM_ERASEBKGND hdc:B4010C07 [wParam:B4010C07 lParam:00000000]
<17576> 000D01F2 R ..WM_ERASEBKGND fErased:True [lResult:00000001]
<17577> 0009057C S ..WM_CTLCOLOREDIT hdcEdit:B4010C07 hwndEdit:000D01F2 [wParam:B4010C07 lParam:000D01F2]
<17578> 0009057C R ..WM_CTLCOLOREDIT hBrush:0B100C80 [lResult:0B100C80]
<17579> 0009057C S ..WM_CTLCOLOREDIT hdcEdit:B4010C07 hwndEdit:000D01F2 [wParam:B4010C07 lParam:000D01F2]
<17580> 0009057C R ..WM_CTLCOLOREDIT hBrush:0B100C80 [lResult:0B100C80]
<17581> 00090384 P WM_TIMER wTimerID:0 tmprc:6DF73DCE [wParam:00000000 lParam:6DF73DCE]
<17582> 000A057A P WM_TIMER wTimerID:656762 tmprc:00000000 [wParam:000A057A lParam:00000000]
<17583> 000805FC P WM_TIMER wTimerID:525820 tmprc:00000000 [wParam:000805FC lParam:00000000]
<17584> 00090586 P WM_TIMER wTimerID:591238 tmprc:00000000 [wParam:00090586 lParam:00000000]
<17585> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17586> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17587> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F154
<17588> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17589> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17590> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17591> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F158
<17592> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17593> 00090384 P WM_TIMER wTimerID:0 tmprc:6DF73DCE [wParam:00000000 lParam:6DF73DCE]
<17482> 000805FC P WM_TIMER wTimerID:525820 tmprc:00000000 [wParam:000805FC lParam:00000000]
<17483> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17484> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17485> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F154
<17486> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17487> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17488> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17489> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F158
<17490> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17491> 000B05CE P WM_TIMER wTimerID:722382 tmprc:00000000 [wParam:000B05CE lParam:00000000]
<17492> 000C02F0 P WM_TIMER wTimerID:787184 tmprc:00000000 [wParam:000C02F0 lParam:00000000]
<17493> 00090384 P WM_TIMER wTimerID:0 tmprc:6DF73DCE [wParam:00000000 lParam:6DF73DCE]
<17494> 000A057A P WM_TIMER wTimerID:656762 tmprc:00000000 [wParam:000A057A lParam:00000000]
<17495> 000805FC P WM_TIMER wTimerID:525820 tmprc:00000000 [wParam:000805FC lParam:00000000]
<17496> 00090586 P WM_TIMER wTimerID:591238 tmprc:00000000 [wParam:00090586 lParam:00000000]
<17497> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17498> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17499> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F154
<17500> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17501> 00130500 S ..message:0x100C [User-defined:WM_USER+3084] wParam:FFFFFFFF lParam:00000001
<17502> 00130500 R ..message:0x100C [User-defined:WM_USER+3084] lResult:00000000
<17503> 00130500 S ..message:0x1005 [User-defined:WM_USER+3077] wParam:00000000 lParam:0018F158
<17504> 00130500 R ..message:0x1005 [User-defined:WM_USER+3077] lResult:00000001
<17505> 00090384 P WM_TIMER wTimerID:0 tmprc:6DF73DCE [wParam:00000000 lParam:6DF73DCE]
<17506> 0009058C P WM_TIMER wTimerID:591244 tmprc:00000000 [wParam:0009058C lParam:00000000]
<17507> 000805FC P WM_TIMER wTimerID:525820 tmprc:00000000 [wParam:000805FC lParam:00000000]
Re: VB6 Timers failing with Windows 7
Oops. I meant timerid is 787184.
Re: VB6 Timers failing with Windows 7
Are you saying that you are getting more than 1 timer event? I can't tell from the snapshot whether the timer fired twice or you ran the program twice & stopped tracking after 1st event.
In VB, while in design mode (app not compiled), any opened modal window, within the project, will block a timer event in uncompiled code. Is this the case? Do you have a modal window open (msgbox, common dialog, etc)?
Else if the timer fired twice, then your event should've fired twice. Maybe looking inside the timer event to see if it Exits sub under some condition or if error trapping is aborting the routine? Just guesses as of now.
Re: VB6 Timers failing with Windows 7
Appreciate the help.
We were tracking continually to a log file while watching visually for the flashing textbox to stop (the symptom). Once it did I stopped tracking it and then visually searched the saved log for examples of where it worked and where it did not work. I grabbed a working snippit and a non-working snippit that I then sent in the previous message.
No messages are popping up. We are just watchin the app sit there flashing a text box.
We have a log message in our timer event that logs in and out. When the event works we always see an in and an out log. When it doesn't work, we never see an in or out log.
Re: VB6 Timers failing with Windows 7
Still looking.
We are now on the trail of wondering if it has to do with RaiseEvents. The main app (Container) loads an ocx that has a timer that is Raising an Event in the Container app. Not sure yet, but we are commenting out code as I write this to see if that helps our issue.
Re: VB6 Timers failing with Windows 7
Ok. Here's what we found.
First of all, we got the program down to two timers, one at 750 msec that flashes a textbox, the other at 100 msec that calls an ActiveX exe function that basically checks a few variables and returns a true/false. As it stood, the 750 msec timer would periodically stop triggering. The 100 msec timer keeps going. It's as if the 750 msec timer event was being swallowed up.
Here's what appears to 'fix' the issue. In the 100 msec timer, we change the interval from 100 to 116 and then back to 100 again every other tick. The 16 is significant because the resolution of timers is basically 15 msec so we theorize it has to be bigger than that minimum resolution. (ie changing it from 100 to 110 and back did not work). Just setting the timer interval to 116 all the time did not fix it.
So, two timers, one faster than the other, calling an ActiveX exe function MAY cause a timer event to be lost, at least on Windows 7.
We are now changing the original program to use this method on all timers that call the ActiveX exe and will see if our results are positive.
Re: VB6 Timers failing with Windows 7
Here's a fairly simple method of using 1 timer to do 2 different events. It is similar to that in post #2. But you can't really use a simple counter since no guarantee a timer's event will trigger exactly at its interval
1. VB's Timer is reset after midnight, so a bit of extra code added to compensate
2. Optionally can use GetTickCount API. That resets every 57 days, or so, of continuous pc up time
Code:
Option Explicit
Private Type MultiTimerStruct
Interval As Long
ActivateTime As Single
ActivateDate As Date
End Type
Dim mts(0 To 1) As MultiTimerStruct
Private Sub Command1_Click()
mts(0).Interval = 750: mts(1).Interval = 50
mts(0).ActivateDate = Date: mts(1).ActivateDate = Date
SetActivationTime 0: SetActivationTime 1
Timer1.Interval = 25 ' should set it to <= smallest mts interval needed
Timer1.Enabled = True
End Sub
Private Sub Timer1_Timer()
If GetAlarmState(0) Then
SetActivationTime 0
Debug.Print "activated 'timer1'"
End If
If GetAlarmState(1) Then
SetActivationTime 1
Debug.Print "activated 'timer2'"
End If
End Sub
Private Function GetAlarmState(mtsIndex As Long) As Boolean
' helper function to test triggers that occur just b4 or just after midnight
If VBA.Timer >= mts(mtsIndex).ActivateTime Then
GetAlarmState = (mts(mtsIndex).ActivateDate >= Date)
Else
GetAlarmState = (mts(mtsIndex).ActivateDate < Date)
End If
End Function
Private Sub SetActivationTime(mtsIndex As Long)
' helper function to handle activation times that span midnight
Const maxTime As Single = 86400!
With mts(mtsIndex)
.ActivateTime = VBA.Timer + (.Interval / 1000!)
If .ActivateTime >= maxTime Then
.ActivateTime = .ActivateTime - maxTime
.ActivateDate = .ActivateDate + 1#
End If
End With
End Sub
Edited: Where you place the call to SetActivationTime, within Timer1_Timer event, can make a huge difference.
a. Placing it before calling your custom function/method could trigger another immediate event after your custom function returns & next timer message received. This can happen if your custom function takes awhile to complete
b. Placing it after calling your custom function will ensure it is not re-triggered until at least the desired interval has elapsed
Re: VB6 Timers failing with Windows 7
Quote:
Originally Posted by
avfadagio
Ya, we're not finding anybody else with this problem, so unfortunately it must be our code somewhere. As I said, it is a large complex system...
I have exactly the same problem...
A 20,000 line VB6 program with about 20 timers...
That manages Algorithmic Trading via IB TWS.
On Windows 7...
One timer that fires every 2000 ms...
Just goes dead for 5 or 10 or 15 minutes...
Before eventually starting up again.
This varies a LOT from machine to machine...
On an HP Win7 laptop the problem was not noticable...
On a much faster desktop the problem became very serious.
I see you've found 2 solutions...
The first a polling kludge that most would try first...
The 2nd with the interval switching... very nice work.
Sure beats re-writing 20,000 lines of code.
Re: VB6 Timers failing with Windows 7
Some small points:
You can get wrapped around the axle by making synchronous calls to out of process components such as an ActiveX EXE class or control, see:
WM_TIMER Messages not Processed as Expected When Making Out of Process COM Calls in Visual Basic 6.0
"Windows 7" didn't really change much at all. But for those paying attention, Windows Vista changed thread and process scheduling. Not a lot of the info made available during the Vista Developer Preview is still online or downloadable, but there are some things out there yet. The Vista SDK has some, but Microsoft SDK docs are getting clumsier and clumsier to navigate anymore because of format changes forced on us by the VS Team.
Inside the Windows Vista Kernel: Part 1 is still online, and it has a little bit on the scheduling changes made for the post-2001 (XP) world. The new cycle-based scheduling might account for some of the changes you are seeing. It helps prevent processor hogs from freezing out other processes as much as in the past.
Re: VB6 Timers failing with Windows 7
Instead of using timers you could just use a Do While loop with a locked framerate of 60 FPS or whatever you desire. Timers aren't realtime and can get very sluggish the more you use:
vb Code:
Option Explicit
Private Declare Function QueryPerformanceCounter Lib "kernel32" (lpPerformanceCount As Currency) As Long
Private Declare Function QueryPerformanceFrequency Lib "kernel32" (lpFrequency As Currency) As Long
Private Declare Function timeGetTime Lib "winmm.dll" () As Long
Private Ticks_Per_Second As Currency
Private Start_Time As Currency
Private Milliseconds As Long
Private Last_Time As Long
Private Get_Frames_Per_Second As Long
Private Frame_Count As Long
Private Running As Boolean
Public Function Hi_Res_Timer_Initialize() As Boolean
If QueryPerformanceFrequency(Ticks_Per_Second) = 0 Then
Hi_Res_Timer_Initialize = False
Else
QueryPerformanceCounter Start_Time
Hi_Res_Timer_Initialize = True
End If
End Function
Public Function Get_Elapsed_Time() As Single
Dim Last_Time As Currency
Dim Current_Time As Currency
QueryPerformanceCounter Current_Time
Get_Elapsed_Time = (Current_Time - Last_Time) / Ticks_Per_Second
QueryPerformanceCounter Last_Time
End Function
Private Sub Lock_Framerate(Target_FPS As Long)
Static Last_Time As Currency
Dim Current_Time As Currency
Dim FPS As Single
Do
QueryPerformanceCounter Current_Time
FPS = Ticks_Per_Second / (Current_Time - Last_Time)
Loop While (FPS > Target_FPS)
QueryPerformanceCounter Last_Time
End Sub
Private Function Get_FPS() As String
Frame_Count = Frame_Count + 1
If Get_Elapsed_Time - Milliseconds >= 1 Then
Get_Frames_Per_Second = Frame_Count
Frame_Count = 0
Milliseconds = Get_Elapsed_Time
End If
Get_FPS = "FPS: " & Get_Frames_Per_Second
End Function
Private Sub Close_Program()
Running = False
Unload Me
End
End Sub
Private Sub Main()
With Me
.Show
.ScaleMode = 3
.AutoRedraw = True
.BackColor = RGB(0, 0, 0)
End With
Running = True
Hi_Res_Timer_Initialize
Milliseconds = Get_Elapsed_Time
Main_Loop
End Sub
Private Sub Main_Loop()
Do While Running = True
DoEvents
Lock_Framerate 60
'//Timer Code Goes Here
Me.Caption = Get_FPS
QueryPerformanceCounter Start_Time
Loop
End Sub
Private Sub Form_Load()
Main
End Sub
Private Sub Form_KeyDown(KeyCode As Integer, Shift As Integer)
If KeyCode = vbKeyEscape Then
Close_Program
End If
End Sub
Private Sub Form_Unload(Cancel As Integer)
Close_Program
End Sub
Re: VB6 Timers failing with Windows 7
@Jacob. A couple things. First, a niffty idea. Now to some observations & comments
1) I'd say your solution is more of a delay routine vs. a timer routine. Timer's don't halt applications
2) Your Do Loops have negative effects depending on situations
-- drop frame rate to a low number (say 1 or 2 for example) and your app is locked until Lock_Framerate exits
-- Re-entrance
3) Using END to terminate an application is never a good idea. And to get around the use of END, some tweaking would be needed
Re: VB6 Timers failing with Windows 7
It was some old code I copied and pasted from years ago o.O
Re: VB6 Timers failing with Windows 7
After 2 weeks...
It's clear that none of the solutions put forth by avagagio...
Resolved the problem satisfactorily...
Which = intermittent hanging up of VB6 timers.
I now have now implemented a solution...
Which results in VB6 timers working under Win7...
About as well as they worked under XP (rough precision).
SOLUTION
(1) Download the Scarms Callback Timer:
http://www.thescarms.com/vbasic/timer.aspx
(2) Replace all your VB6 timers with a CallBack Timer
(3) Include any kind of stopwatch timer with each.
(4) In the CallBack Timer event subroutine (that's triggered)...
Always check the stopwatch to see reasonable time has elapsed...
For example, at least 50% of set interval...
And once it gets in, reset all CB Timer parameters each time:
vb Code:
'------------------------------------------------------------
Private Sub Process_Event_Timer(ByVal ms As Long)
If (ProcessTimer.Elapsed < INTERVAL_ProcessData / 2) Then
Exit Sub
End If
Process_Event.interval = CLng(INTERVAL_ProcessData)
Process_Event.Resolution = 16
Process_Event.EventType = 1
...
Code To Be Triggered
...
end sub
'------------------------------------------------------------
For some reason this CB Timer...
Occasionally triggers at very small intervals...
And can freeze up your program somewhat...
Simply exiting when interval is tiny FIXES this very reliably.
So now I have a 20,000 VB6 program with about 10 new CB Timers...
Working "perfectly" = as well as it was running on XP...
But the timers just display data...
For anything mission critical you gotta go with right NET timer, etc
And this was the ONLY VB6 incompatibility I've seen so far...
Which I suppose is a minor miracle.
Re: VB6 Timers failing with Windows 7
Hello everyone. I just wanted to say that I too have experienced some bugs in some of my existing VB6 applications after upgrading to Windows 7. Nothing very serious so far, luckily.
But, yes, I too noticed that my timer control no longer works. Here is what I tried that worked for me.
I just used a new timer control and this worked for me. For example, say, my existing timer control was Timer1. I just added a new timer control to my form and called it Timer2. Then, I copied and pasted any existing Timer1_Timer() event code and change any Timer1 references to use Timer2 and everything works now. You can then delete Timer1 if you want.
You can also just add a new timer control to your form, call it Timer2, and then copy the existing Timer1_Timer() event code to the Timer2_Timer() event, then delete the Timer1 control and Timer1_Timer() event and rename the new timer control to Timer1 an the new even to Timer1_Timer().
I think you understand what I am saying. I think maybe I have made this sound more confusing than it is.
I don't know why this works for me, but it does. Hope this helps.
