"xytsrm" <xyt***@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
>

"Henning" wrote:

>
> "xytsrm" <xyt***@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
>
>
> .
>

"Henning" wrote:

>
> "xytsrm" <xyt***@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" 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
>
>
> .
>

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

> 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 :)

> 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/Multithreading
> if it helps..

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

"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.ear***@icode.co.uk)
> i-Catcher Development Team
>
> iCode Systems
>
> (Replies direct to my email address will be ignored.
> Please reply to the group.)
> .
>