[ツリー表示へ] [ワード検索] [Home]
タイトル ： Re^2: MSCommの動作実態と多重On Error文に関して教えて下さい。 投稿日 ： 2008/03/16(Sun) 05:57 投稿者 ： ＢａｍＣｈａｎ
| > > 因みに、このPrint文では csv形式の１レコード(CR.LF付き)を書き込んでいますが、 > > そのレコードの途中で、前のレコードを潰して、次のレコードの先頭が書き込まれている」 > > というトラブルを招いています。 > それは、単に前のレコードが書き込まれずに次へ行っただけなのでしょう。 （私としては、不意に核心をつかれた感じです。） この「次へ行っただけ」の発生条件はなんなのでしょうか？ （組み込み用語での）リアルタイムOSでいう「ディスパッチ」に当たる様な 事態を招いているのでしょうか？ 換言すれは、 「Print文実行中である占有権を奪うような事象ってＶＢの世界に存在するのですか？ 尚、 一つ一つのイベント処理は（特にUI部は私なりにある程度、下記の内容を見越して） 努めて軽く作っているつもりだったのですが‥。 それとも、MSComm1_OnComm()だけでも（十分に）重くなってしまっているのでしょうか？ 因みに今回の通信プロトコルはＰＣからのポーリング方式ですので、 MSComm1_OnComm()内で次の送信の前にDoEventsすることは可能ではありますが、 （現在は一切使っていません）これで、タイマーイベントを走行させやすくできる ものなのでしょうか？ > それは"Windows"だからです。"Windows"は"Window"の複数形ですし、"Window" > は"Message"を"Queue"に置き、それを置かれた時刻とは「無関係」に処理して > いくものだからです。 > # 中にはQueueに置かずに直接送られるMessageもありますが、スレッドを > # 跨ぐ際にはそれでもQueueチェックが入ります。 > はい。 > 簡単な例として、 > 1,Form1にTimer1を貼り付けて、Timer1.Intervalを250(ms)程度に設定しておく。 > 2,Timer1_Timerイベントプロシージャ中で > Caption = CStr(Now) > と記述し、コンパイルする。(P-CodeでもNative-CodeでもどちらでもOK) > 3,コンパイルしたEXEを実行し、そのタイトルバー(Captionが出るところ)の > 上にカーソルを合わせて、右ボタンを押しっぱなしにする。 > これだけで、Timerイベントが抑制されることが確認できます。 > # Timerイベントの元は、WM_TIMERメッセージ。 > これそのものを実験した訳ではありませんが、これは納得させて頂けます。 > リアルタイムに反応することをアプリに要求するのならば、少なくとも > その反応するスレッドは負担のかかるUserInterface(以降UIと略します) > を保持するスレッドとは別のスレッドにするべきですよね。で、そういう > アプリだと、VB6の機能のみでは作りにくいのが現状です。UIを持たない > ActiveX EXEとして作るという手もありますが、それでもUIを持つEXEとの > 通信がネックになります。 最後の部分、「UIを持つEXEとの通信がネック」とは、理論的には 「スレッド間でなんらかのハンドシェイクが必要になってくる」という意味ですね？ ＶＢの範囲に留まらず、Windowsプログラミングの極意の様な解説を頂きました。 （私にとっては。） 有難う御座いました。 （あとは、上記の現象が治まってくれれば‥。） |
をクリックするとツリー全体を一括表示します） - MSCommの動作実態と多重On Error文に関して教えて下さい。 - ＢａｍＣｈａｎ 08/03/14-13:09No.11770