System Timer Callback?
in [Visual Basic]
|
From: xytsrm on 3 Aug 2010 15:49 This question may not be appropriate to this forum, but it does involve VB6. This question concerns the fact that when using the MCI control in synchronous mode, all VB events, including the Timer Control, are suspended during a "Play" command. This can be circumvented by using asynchronous mode instead and loop Until "Stop", and include "DoEvents" in the loop. The problem with this approach is that it is Ad Hoc, and can get very convoluted when there are several controls, like the MCI that suspend event processing. I can envision an alternate approach that would require creating a timer based server application (not unlike that referred to in Dan Appleman's VBPG) that makes a "Callback" to the original App, through "AddressOf". The callback routine would then execute a "DoEvents". Now for the question (finally), instead of creating a separate server App, is there some system timer function that takes a time interval value, and uses a callback to an App? Thanks, X
From: Henning on 3 Aug 2010 17:56 "xytsrm" <xytsrm(a)discussions.microsoft.com> skrev i meddelandet news:4171BBAE-69A7-49E7-AB34-2266C5CF045D(a)microsoft.com... > This question may not be appropriate to this forum, but it does involve > VB6. > > This question concerns the fact that when using the MCI control in > synchronous mode, all VB events, including the Timer Control, are > suspended > during a "Play" command. This can be circumvented by using asynchronous > mode > instead and loop Until "Stop", and include "DoEvents" in the loop. The > problem with this approach is that it is Ad Hoc, and can get very > convoluted > when there are several controls, like the MCI that suspend event > processing. > > I can envision an alternate approach that would require creating a timer > based server application (not unlike that referred to in Dan Appleman's > VBPG) > that makes a "Callback" to the original App, through "AddressOf". The > callback routine would then execute a "DoEvents". Now for the question > (finally), instead of creating a separate server App, is there some system > timer function that takes a time interval value, and uses a callback to an > App? > > Thanks, > > X > SetTimer, KillTimer ? /Henning
From: xytsrm on 3 Aug 2010 19:33 Looks interesting, Thank you Henning. "Henning" wrote: > > "xytsrm" <xytsrm(a)discussions.microsoft.com> skrev i meddelandet > news:4171BBAE-69A7-49E7-AB34-2266C5CF045D(a)microsoft.com... > > This question may not be appropriate to this forum, but it does involve > > VB6. > > > > This question concerns the fact that when using the MCI control in > > synchronous mode, all VB events, including the Timer Control, are > > suspended > > during a "Play" command. This can be circumvented by using asynchronous > > mode > > instead and loop Until "Stop", and include "DoEvents" in the loop. The > > problem with this approach is that it is Ad Hoc, and can get very > > convoluted > > when there are several controls, like the MCI that suspend event > > processing. > > > > I can envision an alternate approach that would require creating a timer > > based server application (not unlike that referred to in Dan Appleman's > > VBPG) > > that makes a "Callback" to the original App, through "AddressOf". The > > callback routine would then execute a "DoEvents". Now for the question > > (finally), instead of creating a separate server App, is there some system > > timer function that takes a time interval value, and uses a callback to an > > App? > > > > Thanks, > > > > X > > > > SetTimer, KillTimer ? > > /Henning > > > . >
From: xytsrm on 4 Aug 2010 11:12 Well Henning, It looked promising, but unfortunately the "SetTimer" event will not execute unless a "DoEvents" is inserted in the MCI control wait for "Stop" loop. Even though it's a "Windows" function it's event is treated like all the other events. Not what I was looking for; I was hoping for an interrupt timer event that would execute independent of any other control. It seems that an external App as mentioned in Appleman maybe the only choice, but I'm beginning to believe that any external event will be simply logged as pending, and not executed unless a "DoEvents" is inserted in some loop. X. "Henning" wrote: > > "xytsrm" <xytsrm(a)discussions.microsoft.com> skrev i meddelandet > news:4171BBAE-69A7-49E7-AB34-2266C5CF045D(a)microsoft.com... > > This question may not be appropriate to this forum, but it does involve > > VB6. > > > > This question concerns the fact that when using the MCI control in > > synchronous mode, all VB events, including the Timer Control, are > > suspended > > during a "Play" command. This can be circumvented by using asynchronous > > mode > > instead and loop Until "Stop", and include "DoEvents" in the loop. The > > problem with this approach is that it is Ad Hoc, and can get very > > convoluted > > when there are several controls, like the MCI that suspend event > > processing. > > > > I can envision an alternate approach that would require creating a timer > > based server application (not unlike that referred to in Dan Appleman's > > VBPG) > > that makes a "Callback" to the original App, through "AddressOf". The > > callback routine would then execute a "DoEvents". Now for the question > > (finally), instead of creating a separate server App, is there some system > > timer function that takes a time interval value, and uses a callback to an > > App? > > > > Thanks, > > > > X > > > > SetTimer, KillTimer ? > > /Henning > > > . >
From: Tom Shelton on 4 Aug 2010 11:27
xytsrm formulated on Wednesday : > Well Henning, It looked promising, but unfortunately the "SetTimer" event > will not execute unless a "DoEvents" is inserted in the MCI control wait for > "Stop" loop. Even though it's a "Windows" function it's event is treated > like all the other events. Not what I was looking for; I was hoping for an > interrupt timer event that would execute independent of any other control. > It seems that an external App as mentioned in Appleman maybe the only choice, > but I'm beginning to believe that any external event will be simply logged as > pending, and not executed unless a "DoEvents" is inserted in some loop. > I kind of figured that would be the case... SetTimer works by sending a WM_TIMER message. If your UI is blocked with a tight loop, and no messages are being processed - then it's not likely that your call back is going to fire in response to a window message :) Is this a general question - or is this specifically about the MCI control? It's been a long time since I've played with it - but, doesn't it have an event that fires when the selected action is completed? -- Tom Shelton |