Prev: vb6 xpsp3 DEP stops P&D generated setup.exe
Next: Unicode API
From: xytsrm on 4 Aug 2010 12:38
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
>
>
> .
>
From: Tom Shelton on 4 Aug 2010 13:07
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


From: Dee Earley on 4 Aug 2010 13:15
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(a)icode.co.uk)
i-Catcher Development Team

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)
From: Dee Earley on 4 Aug 2010 13:16
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..

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

iCode Systems

(Replies direct to my email address will be ignored.
Please reply to the group.)
From: Tom Shelton on 4 Aug 2010 13:24
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/Multithreading
> if it helps..

Yep... that's basically the idea.

--
Tom Shelton


First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: vb6 xpsp3 DEP stops P&D generated setup.exe
Next: Unicode API