M
Marchand
I'm working on a reasonably complex Excel application which interfaces
to a live data feed with trading information courtesy of MBTrading.
Basically they supply a UserForm as a separate class ("Implements
IMbtQuotesNotify") w/in Excel through which you login to their live
datafeed. Their UserForm stays open during its operation and contains
some VBA which takes the datafeed supplied by their DLL and asserts it
into a worksheet when new data comes in. Good product, works well. I
also have a VBA routine in the workbook which does other file I/O
unrelated to this datafeed which is called in a loop controlled by
"Application.OnTime" and this also works well. The problem is they
don't always get along together well. What seems to happen, sometimes
but by no means always, is that the VBA doing file IO is doing its
thing when their DLL fires and their VBA servicing that interrupt
within the UserForm gets called. What happens next is up for grabs,
but generally VBA either hangs indefinitely and/or crashes. If the VBA
hangs, it will be at a random place in a limited set of my fileIO-
related macros -- apparently the line which was executing when the
DLL interrupted.
I'm guessing that the problem stems from VBA being single-threaded and
thus getting 'confused' (shall we say) when its normal VBA thread
execution is interrupted by a call from a DLL event to VBA code
servicing that DLL event. This is only a guess, though. I'm wondering
if there's a standard way for dealing with this kind of issue of
coordinating regular VBA code with VBA servicing DLL events. The DLL
events are effectively randomly timed but frequent. I'll be glad to
stall the File IO routine while the DLL call is serviced but I'd have
to pick up the file IO routine where it left off when the VBA behind
the DLL is done. The problem is I don't know how to do this given the
random nature of the DLL event, and thus the macro (and statement)
executing when the DLL event occurs. Currently I'm doing things the
other way, which is to turn off the VBA servicing the DLL while I'm
doing file IO but that's non-optimal.
Any hints out there about handling this kind of situation? Is it a
threading issue at all or am I going down the wrong path entirely?
= M =
to a live data feed with trading information courtesy of MBTrading.
Basically they supply a UserForm as a separate class ("Implements
IMbtQuotesNotify") w/in Excel through which you login to their live
datafeed. Their UserForm stays open during its operation and contains
some VBA which takes the datafeed supplied by their DLL and asserts it
into a worksheet when new data comes in. Good product, works well. I
also have a VBA routine in the workbook which does other file I/O
unrelated to this datafeed which is called in a loop controlled by
"Application.OnTime" and this also works well. The problem is they
don't always get along together well. What seems to happen, sometimes
but by no means always, is that the VBA doing file IO is doing its
thing when their DLL fires and their VBA servicing that interrupt
within the UserForm gets called. What happens next is up for grabs,
but generally VBA either hangs indefinitely and/or crashes. If the VBA
hangs, it will be at a random place in a limited set of my fileIO-
related macros -- apparently the line which was executing when the
DLL interrupted.
I'm guessing that the problem stems from VBA being single-threaded and
thus getting 'confused' (shall we say) when its normal VBA thread
execution is interrupted by a call from a DLL event to VBA code
servicing that DLL event. This is only a guess, though. I'm wondering
if there's a standard way for dealing with this kind of issue of
coordinating regular VBA code with VBA servicing DLL events. The DLL
events are effectively randomly timed but frequent. I'll be glad to
stall the File IO routine while the DLL call is serviced but I'd have
to pick up the file IO routine where it left off when the VBA behind
the DLL is done. The problem is I don't know how to do this given the
random nature of the DLL event, and thus the macro (and statement)
executing when the DLL event occurs. Currently I'm doing things the
other way, which is to turn off the VBA servicing the DLL while I'm
doing file IO but that's non-optimal.
Any hints out there about handling this kind of situation? Is it a
threading issue at all or am I going down the wrong path entirely?
= M =