[ツリー表示へ] [ワード検索] [Home]
タイトル ： Re: MSCommの動作実態と多重On Error文に関して教えて下さい。 投稿日 ： 2008/03/16(Sun) 09:04 投稿者 ： K.J.K.
| > > > 因みに、このPrint文では csv形式の１レコード(CR.LF付き)を書き込んでいますが、 > > > そのレコードの途中で、前のレコードを潰して、次のレコードの先頭が書き込まれている」 > > > というトラブルを招いています。 > > それは、単に前のレコードが書き込まれずに次へ行っただけなのでしょう。 > （私としては、不意に核心をつかれた感じです。） > この「次へ行っただけ」の発生条件はなんなのでしょうか？ そこもしくはそこ以前で例外が発生し、そのPrintステートメントが実行されなかった もしくは失敗した、のでしょう。 例外発生以外では、命令文がスキップされることはないはずです。 > それとも、MSComm1_OnComm()だけでも（十分に）重くなってしまっているのでしょうか？ > 因みに今回の通信プロトコルはＰＣからのポーリング方式ですので、 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関数で直接行うのであれば、そうでもないけど、相当面倒。 |
をクリックするとツリー全体を一括表示します） - MSCommの動作実態と多重On Error文に関して教えて下さい。 - ＢａｍＣｈａｎ 08/03/14-13:09No.11770