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:
DO CASE
CASE THIS.commevent = 1
CASE THIS.commevent = 2
CASE THIS.commevent = 3
CASE THIS.commevent = 4
CASE THIS.commevent = 5
CASE THIS.commevent = 6
CASE THIS.commevent = 7
CASE THIS.commevent = 1001
CASE THIS.commevent = 1004
CASE THIS.commevent = 1006
CASE THIS.commevent = 1008
CASE THIS.commevent = 1009
CASE THIS.commevent = 1010
CASE THIS.commevent = 1011
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.
>