I am not a true VBA expert (and may explain poorly), but I do some
pretty sophisticated serial I/O and I believe I have seen three
methods for setting up VBA serial I/O. Which method do you use?
1- MScomm - Haven't tried as it may only be part of VB (not A)
2- Structs used by Win32 comm api kernel API file i/o functions -
such as:
CreateFile, CloseHandle, WriteFile, ReadFile Libs all calls to, I
believe, the "kernel32" DLL and calls like: OpenComPort, ReadComPort,
WriteComPort, CloseComPort.
3- Shell (Environ("comspec") + " /c mode " + ComP$ + ":" + baud$
+ ",n,8,2"). This uses standard Basic file handling commands such
as:
Open ComP$ For Output As 1
Print #1, c$ + ";";
Close 1
4- I suspect there are other .DLLs as I know there are some NT
parallel port workaround .DLLs
Some of this depends on which OS you are running under and I can not
answer questions except that I know that NT prevents DoEvents from
doing what it is supposed to "Do" and I was unable to use any of the
methods I could find/understand with complete success (under NT).
There is a Key press event ( I forget the name) which can fire on a
specified or random keyboard event, but I was unable to get it to
work (possibily out of ignorance).
I use method #2. Then I have a timer in the read routine. It times
out should no data arrive in a specified time (this comes with the
Kernal call. I use this in two ways.
1- Set with a long time (3 sec), it will give up if nothing is
received and show a Message Box with the reason and location in the
code (for debugging). This is when a specified amount of data is
expected, in response to a aerial transmission data request that
Excel sends. FYI, I can also detect if the remote device is connected
(a hardware thing) or if is connected, but not responding (a command
equivalent to a 'ping' to the remote device).
When I wish to monitor the port for randomly occuring data (from the
serial device), I set it to a short time and manage this in the code
without any user notification. I basicly receive one byte at a time,
then allow other activity (read on). My bites are all in a
relatively short, defined length packet, however these strings can
occur often or never. In this routine, the time out does not create
any user invention, but only allows other routines as well as the
interruption of the process---which, in NT, is still seriously
crippled by the NT DoEvents restrictions.
On XP all is well using the same code/sheet/macros. I simply have a
buttom on the spreadsheet which is pressed to halt looking for data -
its status is checkes each time the timer times out. On NT it can
tak MANY clicks to affect an interrupt of the Sub.