Something else to look out for with this and any activex controls that raise events is that you usually need a wait state for events to fire. Usually what happens when an event fires (and _VFP.AutoYield is .f.) is that the event message is queued and VFP executes the code attached to the event when a wait state occurs (no code is running and VFP is waiting for some new event to fire). If an event fires during a tight loop (ie a do loop or for loop) activex events can get lost (not queued) so the code attached to the event never fires even if _VFP.AutoYield = .t.

What all this boils down to is don't try to send something and loop until a property is changed in the OnComm event code to exit the loop. Even using doevents, event code may not fire because doevents just fires queued events and the event may never be queued. If you have a send/response type scenario the best way to handle it is with polling or send output and loop but inside the loop read the input buffer manually to look for the response you are expecting and exit the loop based on that condition.

Let me know if this helps or if you need clarification.
Todd

>Todd,
>
>RThreshold was the answer. It's pretty embarrassing how many times I poured through the same MSDN pages
>and failed to see what was right in front of me to be seen.
>
>Unfortunately, progress in this business is too often defined as 'getting different error messages than before.' But
>you have enabled me to communicate with my reader/base unit and I'm very grateful.
>
>Thanks.
>
>Mike