齋藤電気の電気実験室

イベント駆動型プログラム、の特徴は、イベントハンドラ、という個々の割込み関数にプログラムを分けて記述する方式。
WindowsＯＳが採用しているのもイベント駆動（ドリブン）型で、いろんな要素をＯＳが管理りましょう…というワケで、時間が来たから
「最優先に処理して…」とか、
「この割込みを先に処理してよ～」
というユーザーが割込みのレベル管理をすることができないんです。

「時間軸制御」で動かさなければいけない用途の場合、WindowsCE、RTLinuxやINTimeといったリアルタイムOSを導入するのがどうやら本筋のようです。

PC内部のタイマー（…といってもCPUクロックを読み取る関数がその根本）をソフトウェア的に「せこく」利用してタイマーを作るより、専用ＩＣ位は外付けで用意して、結果のみOSに知らせてね…って感じな仕様なんでしょう…（笑）
確かにそうですね。時間にシビアな測定なら専用ストップウォッチボードをハードで作成して、データをエクセルに転送する設計が「標準」的な発想でしょうから…。

いかに「せこく」（←安価に？）いくか…ソフトウェアエンジニア達のアイディアがこのフィールドに集うのも、そんなワケなんです。

マルチメディアタイマーのヘッダファイルを覗くと…1mS測定はどうやらCPUタイムを数えているようですね。
考え方としてカーネル部分…にパッチを当てればユーザープログラムが動く訳ですが、流石にそれは…マズイなぁ。。OSのアップデートの度ごとに動かなくなったり…。←本末転倒ですね。ユーザープログラムはOSを触ってはアカンのです。。

画面メニューの設定はリソースViewからMainフォルダ内IDR_MAINFRAMEをクリックすると画面デザインがタブ表示されます。
プロパティにある表示の文字を操作する「終了」確認といった感じに設定し、右クリックで「イベントハンドラ」の追加、つまりマウスでクリックしたらどんな動作をするかのプログラム記述エリア（イベントハンドラ）を作成します。

そのイベントハンドラが作成される場所、はウイザードに指定しますが、View.Cppに設けるのがいいでしょう。
その終了内容は以下のような感じ…

void CM182View::OnAppExit()
{
// TODO: ここにコマンド ハンドラ コードを追加します。
//
endflag = false;//今から終わりますよ…

//もう本当に終了していいですか？
CClientDC mydc(this); //P423
CString ss;
int ret;
ret = AfxMessageBox("本当に終了していい？",
MB_OKCANCEL|MB_ICONINFORMATION);
switch (ret){
case IDCANCEL: //終了キャンセル…終了しない
;//AfxMessageBox("計測に戻ります");//
endflag=true;//戻しておく
return;

case IDOK://終了やぁ！
;//AfxMessageBox("今から終了します");
}//
AfxGetMainWnd() -> PostMessage(WM_CLOSE);
　　　　　　　　//デストロィをよぶ*
}

終了するのにも結構細かい記述がありますが、実はエンドレスループ的なプログラムの終了ロジックを実現させるのにもいろんな技術的な要素があるんです。
何故エンドレスプログラムにしなければならないかというと、ＰＣが通電開始起動したら自動的にプログラムが起動し、計測を止めるときのみ、操作をする、そんな設計の終了部分のプログラムお見せしています。

ポストメッセージでデストロィをコールしてもメモリーリーク（プログラムゴミが残ったまま異常終了）とかがあって、意外とこの問題をクリアして正しく終了させる、というのはハードルが高いなぁ…と感じます。
開発プログラムのレジストリ…をコピーせずに違うＰＣで実行すると上手く動作しないことから、どうやらレジストリのスイッチにその秘訣があるようなんですが、詳細はまだわかりません。

endflgというグローバルなスイッチがありますが、実は、このスイッチ状態で他の非同期プログラムの停止処理を促す設計上は重要なパラメータなのです。…でないと正常終了できないまま取りこぼした…とシステムに怒られる（メモリーリーク）、そんな状態なんですね。マルチタスクを使いこなすのは高度な技が…要るワケだ…マニュアルにはこんなこと…全然書いてない…。（←だからメシの種は尽きぬ…というワケ？）

Winmm.libというライブラリファイルの中に1mSのTimeProc()があるんだけど、これを使えるようにするまでの設定が最初は全く分からない…。

その前に拡張デバイスであるデジタル入力インターフェイスライブラリの位置を指定します。
Tool/ オプション/　プロジェクト・ソルーション/　インクルードファイル/　にインターフェイスドライバディレクトリのパス位置をまず追加…。（←ハードウェアをアクセスするライブラリが入っている）

次にstdafx.hファイルの途中に
#pragma comment(lib,"winmm.lib") //**…まずライブラリの指定です
#include
#include //…これがエントリーヘッダ
を記述。
View.cppファイルに
#include "fbidio.h"//****…ヘッダファイルの指定
を追加…

細かいファイル設定をして、やっとコンパイル時の「インクルードファイルがありません…っていうエラーが消えてくれました。

このファイルパスをちゃんと通すのと、書く位置（最初の位置。）を間違えると、いつまでたっても動いてくれない…（コンパイルできない…）訳なんで、ちょぃハードルが高いです。（←正しい操作方法をつかむまで…）

ちなみにmmsystem.hファイルはProgram Files\Microsoft SDKs\Windows\v6.0A\Includeの中にあって、マルチメディアタイマー割込みの最小単位であるらしいことがヘッダソースから伺えます…。

インストールが無事終了し、アップデートも完了して、早速Interface社のサンプル、標準的なプログラムのHelloWorldを実施してみました。

新規作成のプロジェクトにMFCアプリケーションを指定、単一窓形式のシングルドキュメント、漢字はシフトJIS文字を使うのでユニコードチェックを外す、リンク時に必要となるDLLライブラリのパス設定、と環境設定に細かい指示を指定してやっと使える状態になります。

これら機能の詳細はHELP機能を縦覧すれば一応載っているとはいえ、動作原理理解のためにはやはり専門書（入門書！）が手放せません。

諸目的動作のためのHowTo何故にはマニュアル検索では最初、殆ど理解できず、ステップ、手順を追いながら手探り状態での第一歩です。

大まかにソース、ヘッダ、リソース…そして詳細ファイルにView、Doc、メインファーム…といった10数ファイルに分割されたファイル構成、そして1つ1つの細かい機能は、Helpのヘルプ状態です。

特にマウスで主な操作を司るマウスイベント、メッセージハンドラ、は昔のPC98BASIC時代のキーセレクトに代わるGUI系操作の最たるものです。

文字表示１つとってもテキスト画面（デフォルトプロパティのpDC描画）、グラフィック画面（GDIオブジェクト）、というようにかつてのconsoleやPrint、Color命令が各クラス継承（←ポリモーフィズムというらしい）の記述形式、いわゆる”.”ドットで連結された命令でコーディングされる。
myDC.～とよく定義され、クラスの属性から継承されたコマンドを取り出して使う感触は、コマンド自体が階層化再定義され、オブジェクト指向の最も特徴的な記述スタイルです。
制御文でお行儀が悪いとよばれるgotoやgosub的コマンドを使わず（一筆書きシーケンスではない）パラレル（並列）動作を最重視した設計が基本にあるようです。

CPUの実行優先順位、タイミングの操作は、きっと高度な操作を必要とするのでしょう…。（←それとも、操作して欲しくない…!?）

中間言語であるマネージ形式でなく、コンパイルされた機械語から実行されるネィティブ形式のスタイルでなければ速度依存のある厳しいプログラムには必備であることを前回書きました。

Visualシリーズにはお試し仕様であるExpressというエディションがありますが、残念ながらネィティブ仕様のプログラムは開発ができませんので、VisualStudioの標準的なProfessionalエディションを導入します（有料）。
提供される媒体メディアはDVDです。

さて、PCにVisualStudioのインストールをするのですが、HDDの容量もさることながら、結構、インストールには時間がかかります。（3時間以上）
そして…何より、まともにインストールができない壁、アクシデントがあります。
本来であればDVDの指示どおりに従えば上手くインストールができなければいかん、筈なのですが、ファイルがドライブ読み込みエラーの連発（チェックサムエラー？を生じ）、インストールがままなりません。
（ファイルが壊れている、というエラーでインストール途中で止まってしまう現象…）

この現象を回避するには、どうやらDVDの内容を一旦全部HDDにコピーし、それからHDD上でインストーラを起動したら上手くいく、という「英語」のアドバイスを見つけるのに、かなり苦労いたしました。
やはり、インストールできずに失敗しておられる方が私以外にもいたようです。
また、無事インストール後にはパッチ修正が待っています。
ある意味、WindowsＯＳインストールより遥かに面倒なプロセスを経て、やっと使える環境が手に入る、というわけです。

それにしても、インストールに散々時間をかけておきながら（最初、12時間以上）、インストール途中でプログラム応答しないなんて…これは酷いなぁ…まったく。1時間程度経過すると、HDDランプ点滅がしなくなり、インストールファイルをDVDの中を探しにいったまま、戻ってこなくなる…これはやっぱりあかんでしょう…。ソフトウェアエンジニアならこうした現象も自己解決できる位の機転が必要…そんでもきついなぁ…。安定したDVDドライブ以外はインストールも危ない…というか、それだけ供給メディア内に高密度にツールが圧縮されている、ということなのでしょうね。
これには参りました…。