Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Asychronous procedure call in VB

30 views
Skip to first unread message

Rags

unread,
Jan 10, 2002, 3:58:55 PM1/10/02
to
Hi,

I think someone must have already come across such
situation. How do I perform Asychronous operation in VB?
For example, an object A calls object B's method. Now,
instead of performing a time consuming calculation or
process (which object A is really not bothered of) I would
like object B to return control to object A and then
continue with whatever object B is intended to do.

Any help or pointer will be really helpful

Regards,
Swamy

Jon Oliver

unread,
Jan 10, 2002, 4:14:29 PM1/10/02
to

"Rags" <Ragavend...@citicorp.com> wrote in message
news:7f4a01c19a19$9e0dd0d0$3bef2ecf@TKMSFTNGXA10...

> Hi,
>
> I think someone must have already come across such
> situation. How do I perform Asychronous operation in VB?
> For example, an object A calls object B's method. Now,
> instead of performing a time consuming calculation or
> process (which object A is really not bothered of) I would
> like object B to return control to object A and then
> continue with whatever object B is intended to do.

It's not exactly good news, but I see three ways to go:

1) Hack in the use of a second thread. Frankly, I've never
done this, but I know it's theoretically possible. For me the
complications out-weighed the attractiveness of using a
"legitimate" technique.

2) Use a timer. Calling your function in essence just starts a
timer that will call a "work" function that will actually do the
heavy lifting. That routine should be well ventilated with
DoEvents to give the rest of your application time to react.

3) Just DoEvents. This does not strictly qualify for what
you're asking, but you can retain a fair amount of
responsiveness by using DoEvents in the right places. Your
calling routine will still be jammed waiting for a return, but
other events in that same form can fire.

Dick Grier

unread,
Jan 10, 2002, 4:15:27 PM1/10/02
to
Hi,

The only (satisfactory) way to do this is to have a Timer in object B that
is enabled in the call from A. The actual Timer event code executes B's
time-critical code, while the calling code continues. This, effectively,
creates a separate, synthetic, thread. B's "time-consuming" process needs
to release time via DoEvents or the equivalent -- since it really IS NOT a
separate thread.

Another way to do this is to place B in an ActiveX EXE. This does create a
separate thread of execution.

Or... Use VB.NET, which allows multi-threading.

--
Richard Grier (Microsoft Visual Basic MVP)
Hard & Software
12962 West Louisiana Avenue
Lakewood, CO 80228
303-986-2179 (voice)
303-986-3143 (fax)
Leave voice mail or fax that I can receive as email at 303-593-9315
Author of Visual Basic Programmer's Guide to Serial Communications, 2nd
Edition ISBN 1-890422-25-8 (355 pages).
For information look on my homepage at http://www.hardandsoftware.net.
Use the Books link to order. For faster service contact the publisher at
http://www.mabry.com.


Rags

unread,
Jan 10, 2002, 5:02:59 PM1/10/02
to
Hi,

Thanks for the respone.

Option 1. I don't know whether this is possible using WIN
API. any pointers.

Option 2. Me and my colleagues really did not like the
idea of using timer to create asynchronous for two
reasons - a) object B does not have any UI and we do not
want to create a form with a bunch of timer and
syncrhonize the timer events and b) timer events are given
less importance by OS when compared other events. As per
Windows documentation, there are slight chances that the
application may not receive the timer- which we cannot
afford in our application scenario.

Option 3. We tried this and it does not seem to help
because it anyway does not give up the control to the
caller.

>.
>

Rags

unread,
Jan 10, 2002, 5:05:32 PM1/10/02
to
Hi Richard,

Thanks for your response.

As I indicated in my other message, myself and my
colleagues do not like using timer to achieve this unless
there is no other option.

Using ActiveX.exe seems to be possible if it works. Do
you have any pointers/documentation.

Using VB.NET is not option in our company.

Thanks
Swamy

Jon Oliver

unread,
Jan 10, 2002, 5:41:50 PM1/10/02
to
"Rags" <Ragavend...@citicorp.com> wrote in message
news:7fa901c19a22$91145940$3bef2ecf@TKMSFTNGXA10...

> Hi,
>
> Thanks for the respone.
>
> Option 1. I don't know whether this is possible using WIN
> API. any pointers.

I'm not a fan of the approach, it seems like too much of a hack.
I would suggests books by Dan Appleman and/or Matthew Curland
for details.

> Option 2. Me and my colleagues really did not like the
> idea of using timer to create asynchronous for two
> reasons - a) object B does not have any UI and we do not
> want to create a form with a bunch of timer and
> syncrhonize the timer events and b) timer events are given
> less importance by OS when compared other events. As per
> Windows documentation, there are slight chances that the
> application may not receive the timer- which we cannot
> afford in our application scenario.

You can create a timer w/o a form, but I hear your conditions.

> Option 3. We tried this and it does not seem to help
> because it anyway does not give up the control to the
> caller.

Understood--I didn't know if you were asking for just a little
more than you needed. (Apparently not.)

Option 4. Using ActiveX EXE, as Dick points out, may be your
best bet here. You'll actually get a seperate thread of
execution, with out having punch holes through the VBVM. I hope
your interface requirements are slim enough to accomodate this?

Art Marks

unread,
Jan 10, 2002, 6:23:52 PM1/10/02
to
The ActiveX exe is the way to go. You still need a timer to kick off the
long process without blocking the main app, but you can code it with an API
timer with a few lines of code. The Coffee example that ships with VB5&6
shows how to do this (both the timer part and the async Activex exe).

Art

Rags <Ragavend...@citicorp.com> wrote in message

news:7fd901c19a22$ec00b740$9ee62ecf@tkmsftngxa05...

Peter Young

unread,
Jan 10, 2002, 6:17:07 PM1/10/02
to
> Using ActiveX.exe seems to be possible if it works. Do
> you have any pointers/documentation.

Look at the Coffee Monitor sample in MSDN.

The general idea is this:

1) Call method in ActiveX EXE.
2) This method enables a "one-shot" timer and returns allowing caller to
continue on.
3) The timer event fires, the timer is disabled, and whatever background
processing was needed is executed.

I've used this approach many times without problems.

HTH.


Dick Grier

unread,
Jan 10, 2002, 7:26:50 PM1/10/02
to
Hi,

You still need a timer to decouple the method (call) from the action, even
in an ActiveX EXE.

See the other replies on Coffee. Also, code on www.mvps.org/vb on timers.

BTW, Timers are good, not bad. Just IMO. At least until multi-threading
exists (after Feb 13).

Neila Nessa

unread,
Jan 10, 2002, 11:25:17 PM1/10/02
to

Monte Hansen

unread,
Jan 11, 2002, 12:15:41 AM1/11/02
to
I agree, Dick. Also, as a side note, I think single-threaded/timer-like apps
have helped &/or forced many developers to come up with (better)
event-driven models.

++++++++++++++++++++
Monte Hansen
http://KillerVB.com
++++++++++++++++++++

"Dick Grier" <dick_gri...@msn.com> wrote in message
news:uc4e9bjmBHA.2116@tkmsftngp03...

Rags

unread,
Jan 11, 2002, 1:46:08 PM1/11/02
to
Thanks a lot!

I'll try creating an ACTIVEX.EXE with the timer.

Swamy

>.
>

0 new messages