タイトル : Re: MSCommの動作実態と多重On Error文に関して教えて下さい。 投稿日 : 2008/03/16(Sun) 09:04 投稿者 : K.J.K.
> > > 因みに、このPrint文では csv形式の1レコード(CR.LF付き)を書き込んでいますが、 > > > そのレコードの途中で、前のレコードを潰して、次のレコードの先頭が書き込まれている」 > > > というトラブルを招いています。 > > それは、単に前のレコードが書き込まれずに次へ行っただけなのでしょう。 > (私としては、不意に核心をつかれた感じです。) > この「次へ行っただけ」の発生条件はなんなのでしょうか? そこもしくはそこ以前で例外が発生し、そのPrintステートメントが実行されなかった もしくは失敗した、のでしょう。 例外発生以外では、命令文がスキップされることはないはずです。 > それとも、MSComm1_OnComm()だけでも(十分に)重くなってしまっているのでしょうか? > 因みに今回の通信プロトコルはPCからのポーリング方式ですので、 OnCommイベントを使っているのならば、ポーリングは避けられませんか? 状態遷移を意識したイベントドリブンなコードにできないか模索してみては。 http://www.int21.co.jp/pcdn/vb/noriolib/vbmag/9802/winsock/ などが参考になるかもしれません。(WinSockのAPI関数版でのサンプル) ポーリングはMSCommやInet、WinSockコントロールでよく問題になりますので、 Googleなどで検索してみるといいかも知れません。 # 問題の根本は、前回記述したMessage処理との兼ね合いが主です。 > MSComm1_OnComm()内で次の送信の前にDoEventsすることは可能ではありますが、 > (現在は一切使っていません)これで、タイマーイベントを走行させやすくできる > ものなのでしょうか? 送信ではほとんど関係がないでしょう。 イベントドリブンに徹するならば、DoEventsはほとんど必要になりません。 # そのコンポーネントが、そう作られているという条件下で、ですが。 > > リアルタイムに反応することをアプリに要求するのならば、少なくとも > > その反応するスレッドは負担のかかるUserInterface(以降UIと略します) > > を保持するスレッドとは別のスレッドにするべきですよね。で、そういう > > アプリだと、VB6の機能のみでは作りにくいのが現状です。UIを持たない > > ActiveX EXEとして作るという手もありますが、それでもUIを持つEXEとの > > 通信がネックになります。 > 最後の部分、「UIを持つEXEとの通信がネック」とは、理論的には > 「スレッド間でなんらかのハンドシェイクが必要になってくる」という意味ですね? です。一方的にMessageを送り付けあうだけならばいいのですが、ActiveXの 場合は同期処理を行いますので、そこで片方の時計が止まるのに引きずられ やすくなります。 こういうときはむしろ、昔ながらのDDE通信のがうまく行ったりしますが、 なにせデータ量や形、速度に制限がありすぎますし。 # API関数で直接行うのであれば、そうでもないけど、相当面倒。 |