お世話になります。VB6.0　SP6

MSCommコントロールを用いてRS232Cからデータを受信する
プログラムを開発しています。

「受信開始」ボタンを押下することにより、ポート番号、
通信速度などの設定を行い、ポートを開きます。
開いた後にデータを受信するとOnCommイベントが
開始されるように作成しました。

今ある問題点は
「受信開始」ボタンを押下前にデータを受信します。
受信後に「受信開始」ボタンを押下するとOnCommイベントが
発生してしまいます。
そのため、目的のデータを受信する前に別のデータを
受信してしまいます。

「受信開始」ボタン内でバッファの内容をクリア、
Inputを用いてバッファ内容を取り出してみましたが、
この現象を回避できませんでした。

この問題点を回避する方法がありましたら、
ご教授のほうをお願いします。
また質問内容に不明な点がありましたらご指摘をお願いします。

> 「受信開始」ボタンを押下することにより、ポート番号、
> 通信速度などの設定を行い、ポートを開きます。

とあって、

>「受信開始」ボタンを押下前にデータを受信します。
> 受信後に「受信開始」ボタンを押下するとOnCommイベントが
> 発生してしまいます。

「受信開始」ボタンを押下【前】に、データを受信できるのですか？
またその際、ポート番号、通信速度などの設定は、
上記の話を聞く限りでは未設定で、ポートも開かれていないのですよね？

この辺りを詳細に説明していただけると、回答が付きやすいのではないか？と思います。

いな様、ご返信ありがとうございます。

> 「受信開始」ボタンを押下【前】に、データを受信できるのですか？
「受信開始」ボタンを押下【前】はOnCommイベントは発生しません。

> またその際、ポート番号、通信速度などの設定は、
> 上記の話を聞く限りでは未設定で、ポートも開かれていないのですよね？
フォームロード時に
With comMSComm
.InputMode = comInputModeText
.CommPort = 1
.Settings = "9600,N,8,1"
End With

の3種類を設定を行い、「受信開始」ボタン内で

With comMSComm
.InputLen = 30
.RThreshold = 30
.PortOpen = True
End With

としてあります。この結果、
PortOpen = True
前に受信（送信側装置からデータ送信を行う）と、
「受信開始」ボタンの処理終了後、直ぐに
OnCommイベントが開始されてしまいます。

また、デバックのステップインを用いて「受信開始」ボタン内を
実行すると、問題の現象が起きませんでした。

他にも不明な点、アドバイスなどありましたらお願いします。

要するにPortOpen前に受信したデータがあると、Openと同時にOnCommイベントが発生する
のを防ぎたいということでしょうか？。

まず、OnCommイベントはCommEventプロパティが変化した時に発生するイベントなので、
OnCommイベント時のCommEventプロパティを調べて下さい。
多分、comEvReceiveが発生していると思われます。

RThresholdプロパティを0にしておき、PortOpen = True 後に InBufferCountで受信バイト
数を検定し、1以上なら不要データとして、InBufferCount = 0とすればクリアされませんか？。
その後、RThresholdプロパティを30に再設定することでOnCommイベントも回避できませんか？。
ただ、PortOpen = True 前にInBufferCount = 0でクリアできるのかなぁ・・・これだけで良い
かもしれないけど、試していません。

単純に状態遷移表なんかを作って、通過／拒否を調べるのじゃ駄目なのかな。
イベントの発生するタイミングが重要なのではなくて、
利用したくないとき(そういう状態)でイベントでデータを受け取ってしまうのが問題なのでしょう？

G13様、　様、ご返信ありがとうございます。

> 要するにPortOpen前に受信したデータがあると、Openと同時にOnCommイベントが発生する
> のを防ぎたいということでしょうか？。
はい、その通りです。ですが、Openと同時にOnCommイベントが発生しないときもあります。
また、「受信開始」ボタン押下前に送られてこない場合もあります。
(説明不足でした。すみません。）

> OnCommイベント時のCommEventプロパティを調べて下さい。
> 多分、comEvReceiveが発生していると思われます。
はい、comEvReceiveが発生しています。

> RThresholdプロパティを0にしておき、PortOpen = True 後に InBufferCountで受信バイト
> 数を検定し、1以上なら不要データとして、InBufferCount = 0とすればクリアされませんか？。
> その後、RThresholdプロパティを30に再設定することでOnCommイベントも回避できませんか？。
必ず発生する問題ではないため、
comMSComm.RThreshold = 0
comMSComm.PortOpen = True
If comMSComm.InBufferCount > 0 then
comMSComm.InBufferCount = 0
comMSComm.RThreshold = 30
End If
としますと、発生しなかったときは「受信開始」ボタン押下後も受信できなくなってしまいました。

ElseIF comMSComm.InBufferCount = 0 then
comMSComm.RThreshold = 30
End If
を追加しますと、元の問題が発生する状態になりました。

解決しようといろいろ調べてみました。
PortOpen = True 前に送信されると、InBufferCountプロパティに格納されるようです。
comMSComm.InBufferCount = 0
としましても、「受信開始」ボタン処理が終了後、OnCommイベントが発生し、
comEvReceiveが発生しています。
（確かに縁を切ったと思った値がいつの間にか存在している・・・orz）

"　"様
> 単純に状態遷移表なんかを作って、通過／拒否を調べるのじゃ駄目なのかな。
> イベントの発生するタイミングが重要なのではなくて、
> 利用したくないとき(そういう状態)でイベントでデータを受け取ってしまうのが問題なのでしょう
？
通過/拒否を調べるとはどうすれば調べることができるのでしょうか？
利用したくないデータかどうかを調べる方法がまだ思い浮かばないため
（1回目は必ず利用したくないとは限らないため）
困ってしまっています。

> 利用したくないデータかどうかを調べる方法がまだ思い浮かばないため
あれ…「利用したくないデータかどうか」というのは、最初の投稿の
> 目的のデータを受信する前に別のデータを受信してしまいます。
ではないのでしょうか？

…うーん、誤爆していそうだなぁ…

　様返信ありがとうございます。

表現の仕方が悪かったようです。すみません。
受信するデータは同じ文字列のため、「受信開始」ボタン処理終了直後と
待機中による受信データの区別をつける方法が思い浮かばなかったためです。

>> 目的のデータを受信する前に別のデータを受信してしまいます。
これが誤りでした。別のデータではなく、無視したいデータです。
誤解した表現を使用してしまいすみません。

受信開始ボタン押下後#秒以内のOnCommイベントは無視することにして
回避してみようと思います。

ご返信して頂いた いな様、G13様、　様、貴重な時間を私のレベル不足による
質問に返信していただきありがとうございました。
今後もわからないことが起きました時は宜しくお願いします。

> 表現の仕方が悪かったようです。すみません。
> 受信するデータは同じ文字列のため、「受信開始」ボタン処理終了直後と
> 待機中による受信データの区別をつける方法が思い浮かばなかったためです。
うーん…本来は「受信開始」ボタンを処理中には押せないようにするのがいいと思うのですが…

> 受信開始ボタン押下後#秒以内のOnCommイベントは無視することにして
> 回避してみようと思います。
タイムアウト処理ですか…いいのかなぁ…

さて、こういう場合は自分のアプリケーション上にバッファを設けると嬉しく馴れるかもしれません。
たとえば、
・現状
　[「受信開始」ボタンを押す]
　↓
　[受信をしながら処理]
　※この処理は予想です。私はこのように予想しました。

・改造
　[「受信開始」ボタンを押す]
　↓
　[privateDataを処理]

　[OnCommイベントが発生]
　↓
　[データを受信し、privateDataとして保存]
　※このままでは、ボタンを押していないときにきたデータも全て受信してしまいます。
　　適宜修正することで、ボタンを押していないときの受信を避けることができましょう。

このようにすることで、データの受信部分と、処理部分を分割できます。

「OnCommイベント発生＝データ受信」ではないですがその辺は理解されているんでしょうか？

　様、のびた様ご返信ありがとうございます。

　様のシステムですが、私の考えているシステムとずれがあります。
「受信開始」ボタンで PortOpen=True 、Caption = "受信中止"と
する予定です。そのため、
> ・改造
> 　[「受信開始」ボタンを押す]
> 　↓
> 　[privateDataを処理]
>
> 　[OnCommイベントが発生]
> 　↓
> 　[データを受信し、privateDataとして保存]
> 　※このままでは、ボタンを押していないときにきたデータも全て受信してしまいます。
この方法では思い描いた処理になりませんでした。考えていただいたのに申し訳ない。

> 「OnCommイベント発生＝データ受信」ではないですがその辺は理解されているんでしょうか？
G13様から説明頂きました。
> まず、OnCommイベントはCommEventプロパティが変化した時に発生するイベントなので、
> OnCommイベント時のCommEventプロパティを調べて下さい。
> 多分、comEvReceiveが発生していると思われます。
これに、エラー時のデータもCommEventプロパティに格納されていると解釈しています。
Select文でcomEvReceive時に処理が入ったので、受信したものはエラーではなく、
目的のデータです。

すみません、こちらは2重投稿となってしまいました。
汚してすみません。

> G13様、　様、ご返信ありがとうございます。
>
> > 要するにPortOpen前に受信したデータがあると、Openと同時にOnCommイベントが発生する
> > のを防ぎたいということでしょうか？。
> はい、その通りです。ですが、Openと同時にOnCommイベントが発生しないときもあります。
> また、「受信開始」ボタン押下前に送られてこない場合もあります。
> (説明不足でした。すみません。）
>
> > OnCommイベント時のCommEventプロパティを調べて下さい。
> > 多分、comEvReceiveが発生していると思われます。
> はい、comEvReceiveが発生しています。
>
> > RThresholdプロパティを0にしておき、PortOpen = True 後に InBufferCountで受信バイト
> > 数を検定し、1以上なら不要データとして、InBufferCount = 0とすればクリアされませんか
？。
> > その後、RThresholdプロパティを30に再設定することでOnCommイベントも回避できませんか
？。
> 必ず発生する問題ではないため、

> comMSComm.RThreshold = 0
> comMSComm.PortOpen = True
> If comMSComm.InBufferCount > 0 then
> comMSComm.InBufferCount = 0
> comMSComm.RThreshold = 30
> End If
> としますと、発生しなかったときは「受信開始」ボタン押下後も受信できなくなってしまいました
。
当たり前です。
If comMSComm.InBufferCount > 0 then　0以上でない場合は
comMSComm.RThreshold = 30を設定できないからです。

> ElseIF comMSComm.InBufferCount = 0 then
> comMSComm.RThreshold = 30
> End If
> を追加しますと、元の問題が発生する状態になりました。
ここはいらないです。

comMSComm.RThreshold = 30
で良いように思えますが？。

> 解決しようといろいろ調べてみました。
> PortOpen = True 前に送信されると、InBufferCountプロパティに格納されるようです。
> comMSComm.InBufferCount = 0
> としましても、「受信開始」ボタン処理が終了後、OnCommイベントが発生し、
> comEvReceiveが発生しています。
> （確かに縁を切ったと思った値がいつの間にか存在している・・・orz）

当たり前のように思えますが、
comMSComm.RThreshold = 30としているからではないですか？。

ちょっと試せる環境がないので申し訳ないですけど。

G13様ご返信ありがとうございます。

> 当たり前のように思えますが、
> comMSComm.RThreshold = 30としているからではないですか？。
PortOpen = True
にする直前までRThreshold = 0　にし、InBufferCount = 0　にしてみましたが
この問題を回避できませんでした。

現在はタイムアウト処理の#秒以内を無視する方法で回避しております。
条件式が増えてしまいますが、体育会系の私はこれで妥協します。

私のプログラムの問題に気兼ねしていただきありがとうございました。
今後もわからないことが起きました時は宜しくお願いします。
（私も困った人を助けてみたいけど、いつになるのやら。）