[ツリー表示へ] [ワード検索] [Home]
タイトル ： Re^2: MSCommの動作実態と多重On Error文に関して教えて下さい。 投稿日 ： 2008/03/16(Sun) 09:54 投稿者 ： ＢａｍＣｈａｎ
| > > > > 因みに、このPrint文では csv形式の１レコード(CR.LF付き)を書き込んでいますが、 > > > > そのレコードの途中で、前のレコードを潰して、次のレコードの先頭が書き込まれている」 > > > > というトラブルを招いています。 > > > それは、単に前のレコードが書き込まれずに次へ行っただけなのでしょう。 > > （私としては、不意に核心をつかれた感じです。） > > この「次へ行っただけ」の発生条件はなんなのでしょうか？ > > そこもしくはそこ以前で例外が発生し、そのPrintステートメントが実行されなかった > もしくは失敗した、のでしょう。 > 例外発生以外では、命令文がスキップされることはないはずです。 なるほど、明日、もう少し踏み込んで調べてみたいと思います。 確かに、現在は理由があって意図的に「On Error Resume Next」にしております。 （なにせ、この現象は、通信処理に約15mSec/１Byte、1Sec/csvファイル１レコード出力 のレートに対して、2〜3時間に１回発生、という頻度ですので、 事前の作戦立てに、結構検討を要しています。 先ずは、もう少しデータ収集をお待ち願えますでしょうか。 > > それとも、MSComm1_OnComm()だけでも（十分に）重くなってしまっているのでしょうか？ > > 因みに今回の通信プロトコルはＰＣからのポーリング方式ですので、 > > OnCommイベントを使っているのならば、ポーリングは避けられませんか? > ： > ： > 送信ではほとんど関係がないでしょう。 > イベントドリブンに徹するならば、DoEventsはほとんど必要になりません。 > # そのコンポーネントが、そう作られているという条件下で、ですが。 > スミマセン、言葉が不十分でした。ここで言う「通信プロトコルのポーリング方式」とは、 MSCommのポーリング方式のことではなく、「ＰＣ側が送信しない限り、相手側が自発的に 送信してくることは無い」という「通信用語でのポーリング方式」のことです。 MSCommは仰せの通り、100%イベントドリブンの形で使っております。 ですので、もし「MSComm1_OnComm()が重くなっている様であれば、 その間にタイマーイベントを拾い易くできないか？」と、 DoEventsの有効性をお聞きしたいのです。 （Byte型→String型に加え中間的にSingle演算などの編集とかやってますので。） > > > リアルタイムに反応することをアプリに要求するのならば、少なくとも > > > その反応するスレッドは負担のかかるUserInterface(以降UIと略します) > > > を保持するスレッドとは別のスレッドにするべきですよね。で、そういう > > > アプリだと、VB6の機能のみでは作りにくいのが現状です。UIを持たない > > > ActiveX EXEとして作るという手もありますが、それでもUIを持つEXEとの > > > 通信がネックになります。 > > 最後の部分、「UIを持つEXEとの通信がネック」とは、理論的には > > 「スレッド間でなんらかのハンドシェイクが必要になってくる」という意味ですね？ > > です。一方的にMessageを送り付けあうだけならばいいのですが、ActiveXの > 場合は同期処理を行いますので、そこで片方の時計が止まるのに引きずられ > やすくなります。 > > こういうときはむしろ、昔ながらのDDE通信のがうまく行ったりしますが、 > なにせデータ量や形、速度に制限がありすぎますし。 > # API関数で直接行うのであれば、そうでもないけど、相当面倒。 なるほど、一々合点がいきます。本当に有難う御座います。 では、明日、実機にてデータ収集に努めます。 |
をクリックするとツリー全体を一括表示します） - MSCommの動作実態と多重On Error文に関して教えて下さい。 - ＢａｍＣｈａｎ 08/03/14-13:09No.11770