Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
VFP Communications programing
Message
From
23/05/2006 07:00:52
 
 
To
22/05/2006 13:11:34
General information
Forum:
Visual FoxPro
Category:
Windows API functions
Environment versions
Visual FoxPro:
VFP 9 SP1
Miscellaneous
Thread ID:
01123906
Message ID:
01124213
Views:
109
Powering off the device should raise some event, as at least one control line must change state in that process, assuming some form of hardware handshaking is enabled. The CTSHolding property allows you to check what the current RTS/CTS state is. In this case, the CommEvent = 3 should be true, and you can use CTSHolding to see in what direction the change was.

Some boilerplate I commonly use in the OnComm event:
*** ActiveX Control Event ***

  DO CASE
    CASE THIS.commevent = 1
      * characters sent => SThreshold
    CASE THIS.commevent = 2
      * characters received => RThreshold
    CASE THIS.commevent = 3
      * change in CTS
    CASE THIS.commevent = 4
      * change in DSR
    CASE THIS.commevent = 5
      * Change in CD
    CASE THIS.commevent = 6
      * Ring detected
    CASE THIS.commevent = 7
      * EOF detected
    CASE THIS.commevent = 1001
      * Break Received
    CASE THIS.commevent = 1004
      * Framing Error
    CASE THIS.commevent = 1006
      * Overrun
    CASE THIS.commevent = 1008
      * Overflow
    CASE THIS.commevent = 1009
      * Parity Error
    CASE THIS.commevent = 1010
      * TX buffer full
    CASE THIS.commevent = 1011
      * DCB error
  ENDCASE
My current 'best practice' is to set form/class properties to hold the events as they occur, and to always test for input data, regardless of event raised. I then use a timer to test/check these properties and to process input data.

If you're trying to look at this in the Debugger - don't waste your time. It will be unreliable.

You can't assume that you haven't missed events - in fact you will. While the events will be queued, when your app gets around to processing the event, the comm control will only have knowledge of the last one that occurred - there may well have been several previously. This may be a rare occurence, but it does happen.

Finally, you do have another layer involved with the port virtualization. Don't assume for a second that their code is bug free.

>Correct me if I am doing something wrong.
>I am running a form with mscomm control on it. The control opens a port. I can see that my device has a green light for the open port. Then I am powering the device off and the light goes red. But I have no oncomm event raising anything.
>
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform