[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.vb.general.discussion

System Timer Callback?

xytsrm

8/3/2010 7:49:00 PM

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
10 Answers

Henning

8/3/2010 9:56:00 PM

0


"xytsrm" <xytsrm@discussions.microsoft.com> skrev i meddelandet
news:4171BBAE-69A7-49E7-AB34-2266C5CF045D@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

xytsrm

8/3/2010 11:33:00 PM

0

Looks interesting,

Thank you Henning.


"Henning" wrote:

>
> "xytsrm" <xytsrm@discussions.microsoft.com> skrev i meddelandet
> news:4171BBAE-69A7-49E7-AB34-2266C5CF045D@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
>
>
> .
>

xytsrm

8/4/2010 3:12:00 PM

0

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@discussions.microsoft.com> skrev i meddelandet
> news:4171BBAE-69A7-49E7-AB34-2266C5CF045D@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
>
>
> .
>

Tom Shelton

8/4/2010 3:28:00 PM

0

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

xytsrm

8/4/2010 4:38:00 PM

0

Hi Tom,

This is not specifically about the MCI control, it's just that the control
illistrates how VB events get suspended; in this case they are suspended
during the synchronous "Play", forcing the use of asynchronous mode, looping
until "Stop" and including "DoEvents" in the loop. I also use other
functions that suspend the event processing, leading to a very Ad Hoc
collection of loops containing "DoEvents". I was hoping I could find a
system function (e.g. timer) that could call a single function in my app on
at a regular interval and not be suspended by any other process. That
function would contain the "DoEvents", insuring all events were processed
regardless of whether a given control was being used synchronously. It would
seem that this should be possible, given that the OS does continue processing
events, regardless of indivudual apps. I am surprised that VB doesn't
provide some capability to multi-task event processing without the need for
the scattering of "DoEvents" around code. Your comments on the way callbacks
work re-enforces my opinion that "Dan Appleman's" server approach won't work
either. Do you know whether this issue has been overcome in VB Net?

X.

"Tom Shelton" wrote:

> 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
>
>
> .
>

Tom Shelton

8/4/2010 5:08:00 PM

0

xytsrm submitted this idea :
> Hi Tom,
>
> This is not specifically about the MCI control, it's just that the control
> illistrates how VB events get suspended; in this case they are suspended
> during the synchronous "Play", forcing the use of asynchronous mode, looping
> until "Stop" and including "DoEvents" in the loop. I also use other
> functions that suspend the event processing, leading to a very Ad Hoc
> collection of loops containing "DoEvents". I was hoping I could find a
> system function (e.g. timer) that could call a single function in my app on
> at a regular interval and not be suspended by any other process. That
> function would contain the "DoEvents", insuring all events were processed
> regardless of whether a given control was being used synchronously. It would
> seem that this should be possible, given that the OS does continue processing
> events, regardless of indivudual apps. I am surprised that VB doesn't
> provide some capability to multi-task event processing without the need for
> the scattering of "DoEvents" around code. Your comments on the way callbacks
> work re-enforces my opinion that "Dan Appleman's" server approach won't work
> either.

Personally, I think you have it backwords... What you should do in
those types of situations is basically the opposite of what your doing
- but the long running task in the background. And then have it
periodically call back to your ui with status updates.

This you could do with an activex exe with not a lot of work....

Hmmm, maybe I'll try and whip an example if I've got time latter, but
I'm sure one of the current VB6 gurus understands what I'm talking
about and could get to it before I can :)

> Do you know whether this issue has been overcome in VB Net?

VB.NET is completely free threaded, so yes, it is overcome.

--
Tom Shelton

Dee Earley

8/4/2010 5:15:00 PM

0

On 04/08/2010 17:38, xytsrm wrote:
> Hi Tom,
>
> This is not specifically about the MCI control, it's just that the control
> illistrates how VB events get suspended; in this case they are suspended
> during the synchronous "Play", forcing the use of asynchronous mode, looping
> until "Stop" and including "DoEvents" in the loop. I also use other
> functions that suspend the event processing, leading to a very Ad Hoc
> collection of loops containing "DoEvents". I was hoping I could find a
> system function (e.g. timer) that could call a single function in my app on
> at a regular interval and not be suspended by any other process. That
> function would contain the "DoEvents", insuring all events were processed
> regardless of whether a given control was being used synchronously. It would
> seem that this should be possible, given that the OS does continue processing
> events, regardless of indivudual apps. I am surprised that VB doesn't
> provide some capability to multi-task event processing without the need for
> the scattering of "DoEvents" around code. Your comments on the way callbacks
> work re-enforces my opinion that "Dan Appleman's" server approach won't work
> either. Do you know whether this issue has been overcome in VB Net?

It essentially comes down to threading.

A thread can only do one single thing at a time.
Sadly VB6 natively only really supports a single thread (*).

If your code calls other code (that is synchronous) then it will be
blocked until it returns.
This "block" also includes processing of windows messages, redrawing, etc.
If the code calls DoEvents then it allows these to be processed before
it has returned control to your code.

Asynchronous normally means it moves everything off to a background
thread and allows your code to carry on as before, but there are some
exceptions that will just call Doevents allowing other code to run, but
STILL blocking your thread of execution (it hasn't returned).

* Multithreading in VB6 is possible but very awkward to handle.
You either use out of process COM objects (ActiveX EXEs) or some very
carefully written API code to handle TLS (or lack of) but you can't
easily call other objects.

..NET (cue flames..) allows you do do background tasks a lot easier so
you can start off one video on a background thread while your UI threads
carries on processing messages and idling.

Reading that back, it makes some sense so I'll send it anyway... :)

--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

Dee Earley

8/4/2010 5:17:00 PM

0

On 04/08/2010 18:07, Tom Shelton wrote:
> xytsrm submitted this idea :
>> Hi Tom,
>>
>> This is not specifically about the MCI control, it's just that the
>> control illistrates how VB events get suspended; in this case they are
>> suspended during the synchronous "Play", forcing the use of
>> asynchronous mode, looping until "Stop" and including "DoEvents" in
>> the loop. I also use other functions that suspend the event
>> processing, leading to a very Ad Hoc collection of loops containing
>> "DoEvents". I was hoping I could find a system function (e.g. timer)
>> that could call a single function in my app on at a regular interval
>> and not be suspended by any other process. That function would contain
>> the "DoEvents", insuring all events were processed regardless of
>> whether a given control was being used synchronously. It would seem
>> that this should be possible, given that the OS does continue
>> processing events, regardless of indivudual apps. I am surprised that
>> VB doesn't provide some capability to multi-task event processing
>> without the need for the scattering of "DoEvents" around code. Your
>> comments on the way callbacks work re-enforces my opinion that "Dan
>> Appleman's" server approach won't work either.
>
> Personally, I think you have it backwords... What you should do in those
> types of situations is basically the opposite of what your doing - but
> the long running task in the background. And then have it periodically
> call back to your ui with status updates.
>
> This you could do with an activex exe with not a lot of work....
>
> Hmmm, maybe I'll try and whip an example if I've got time latter, but
> I'm sure one of the current VB6 gurus understands what I'm talking about
> and could get to it before I can :)

I have a rough article (no code) in my wiki at:
http://hashvb.earlsoft.co.uk/Mult...
if it helps..

--
Dee Earley (dee.earley@icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)

Tom Shelton

8/4/2010 5:25:00 PM

0

Dee Earley formulated the question :
> On 04/08/2010 18:07, Tom Shelton wrote:
>> xytsrm submitted this idea :
>>> Hi Tom,
>>>
>>> This is not specifically about the MCI control, it's just that the
>>> control illistrates how VB events get suspended; in this case they are
>>> suspended during the synchronous "Play", forcing the use of
>>> asynchronous mode, looping until "Stop" and including "DoEvents" in
>>> the loop. I also use other functions that suspend the event
>>> processing, leading to a very Ad Hoc collection of loops containing
>>> "DoEvents". I was hoping I could find a system function (e.g. timer)
>>> that could call a single function in my app on at a regular interval
>>> and not be suspended by any other process. That function would contain
>>> the "DoEvents", insuring all events were processed regardless of
>>> whether a given control was being used synchronously. It would seem
>>> that this should be possible, given that the OS does continue
>>> processing events, regardless of indivudual apps. I am surprised that
>>> VB doesn't provide some capability to multi-task event processing
>>> without the need for the scattering of "DoEvents" around code. Your
>>> comments on the way callbacks work re-enforces my opinion that "Dan
>>> Appleman's" server approach won't work either.
>>
>> Personally, I think you have it backwords... What you should do in those
>> types of situations is basically the opposite of what your doing - but
>> the long running task in the background. And then have it periodically
>> call back to your ui with status updates.
>>
>> This you could do with an activex exe with not a lot of work....
>>
>> Hmmm, maybe I'll try and whip an example if I've got time latter, but
>> I'm sure one of the current VB6 gurus understands what I'm talking about
>> and could get to it before I can :)
>
> I have a rough article (no code) in my wiki at:
> http://hashvb.earlsoft.co.uk/Mult...
> if it helps..

Yep... that's basically the idea.

--
Tom Shelton

xytsrm

8/4/2010 9:42:00 PM

0

Thanks Guys,

The bottom line seems to be it's not very easy to overcome the Ad Hoc use of
"DoEvents" in VB6. Which I am currently doing, and although it works fine, I
just don't like the structure.

May have to embrace vb.Net....eventually.

X.


"Dee Earley" wrote:

> On 04/08/2010 17:38, xytsrm wrote:
> > Hi Tom,
> >
> > This is not specifically about the MCI control, it's just that the control
> > illistrates how VB events get suspended; in this case they are suspended
> > during the synchronous "Play", forcing the use of asynchronous mode, looping
> > until "Stop" and including "DoEvents" in the loop. I also use other
> > functions that suspend the event processing, leading to a very Ad Hoc
> > collection of loops containing "DoEvents". I was hoping I could find a
> > system function (e.g. timer) that could call a single function in my app on
> > at a regular interval and not be suspended by any other process. That
> > function would contain the "DoEvents", insuring all events were processed
> > regardless of whether a given control was being used synchronously. It would
> > seem that this should be possible, given that the OS does continue processing
> > events, regardless of indivudual apps. I am surprised that VB doesn't
> > provide some capability to multi-task event processing without the need for
> > the scattering of "DoEvents" around code. Your comments on the way callbacks
> > work re-enforces my opinion that "Dan Appleman's" server approach won't work
> > either. Do you know whether this issue has been overcome in VB Net?
>
> It essentially comes down to threading.
>
> A thread can only do one single thing at a time.
> Sadly VB6 natively only really supports a single thread (*).
>
> If your code calls other code (that is synchronous) then it will be
> blocked until it returns.
> This "block" also includes processing of windows messages, redrawing, etc.
> If the code calls DoEvents then it allows these to be processed before
> it has returned control to your code.
>
> Asynchronous normally means it moves everything off to a background
> thread and allows your code to carry on as before, but there are some
> exceptions that will just call Doevents allowing other code to run, but
> STILL blocking your thread of execution (it hasn't returned).
>
> * Multithreading in VB6 is possible but very awkward to handle.
> You either use out of process COM objects (ActiveX EXEs) or some very
> carefully written API code to handle TLS (or lack of) but you can't
> easily call other objects.
>
> ..NET (cue flames..) allows you do do background tasks a lot easier so
> you can start off one video on a background thread while your UI threads
> carries on processing messages and idling.
>
> Reading that back, it makes some sense so I'll send it anyway... :)
>
> --
> Dee Earley (dee.earley@icode.co.uk)
> i-Catcher Development Team
>
> iCode Systems
>
> (Replies direct to my email address will be ignored.
> Please reply to the group.)
> .
>