とりあえず、現行の進行計画から,
α１版：Version 0.3.x クラス化＋α
α２版：Version 0.4.x グラフィックウインドウ＋α
β版：Version 0.5.x とりあえず、計画に有った全機能の取り込み
正式版： Version 1.0.0 β版のバグＦＩＸ版
さて、ここからが正念場なのである。前回のライブラリソース0.2.9を見て、お世辞にもスッキリしてる…等と思う人は居ないだろう。開発している自分でさえ、ちょっと収集付かないのである。これを使うユーザに言わせれば、そんなものは、どうでも良いのかも知れないが、こうごちゃごちゃしていると、自分が納得いかないし、今後の拡張に支障を来すのである。尚、変更の内容については、ＣＷＣＣ特有の要点がない限り、ここでは説明しないので、ソースを見て確認してほしいが、必要な事は、本編の方で説明するので、そちらも併せて確認してほしい。
α−１版ライブラリのダウンロード
ライブラリの版数は、０．３．１２
※サンプル入(ソースは、暗号化されているので、メールにて、デコーダを入手して下さい)
- ＣＬＳボタンは必要か？
実は、既に数人の方に試用をしてもらっているのだが、レスポンスで一番多かったのが、『ＣＬＳボタンは要らない』というものだった。かえって、間違えて押してしまって、データが飛んだ等という事も有って、削除する事にした。折角付けたボタンなので、消すのは勿体ないのだが、常にスクリーンに表示されていなければ、問題は無さそうなので、メニューに残す事にした。(V0.3.0)
- スレッド部分のクラス化
まずは、ここである。ＣＷＣＣでは重要な位置となるスレッドの部分だが、広域変数として、裸で置かれたフラグを元にメインウインドウ側からコントロールする形なので、ユーザに触られると、完全に動作を乱す事になるし、どうも、スッキリしない。そこで、これらの広域変数も含めて、CwccThreadクラスで、コントロールする事により、スレッド部分の制御をスッキリさせた。
尚、本編では、動的宣言を採用した。
※将来的には、ここに、メニューのENABLE/DISABLE機能も持たせる予定。
- メールボックスのクラス化
メールボックスも、勝手にユーザに触られると、動作がおかしくなる部分であるので、クラスの中に閉じこめてしまった。特に、ここは変数のサイズが大きい(と言っても現行は４ＫＢ程度だが…将来的には膨大になる可能性が有るので…)また、サイズについても、チェックを入れる様に変更した。
本編では、静的に宣言する方法を採用している。
- メインウインドウはクラス化すべきか？
スレッドとメールボックスの処理をクラス化する事で、メインのウインドウ側と、スレッド側の通信を、ひとまとめに管理出来る様になったし、拡張時も、ここだけを変えれば問題無いので、意味のあるクラス化で有ったが、問題は、メインウインドウである。ここは、かなり迷った項目なのである。メインウインドウとエディットしかないメインコンソールで、しかも、互いに１個しか存在しないものをクラス化する意味は、殆ど無いのだ…(他に再利用出来るとか、ユーザが拡張する可能性が有るというのであれば別であるが、単純にクラス化しても、処理が遅くなるだけなのだ)。これは、多分に自分自身の頭の中の整理という理由で行ったのだが、少々強引にCoolLibを流用してクラス化してしまった。しかも、ちょっと色気を出して、継承等をやり始めてしまったから、自分でも動作を追うのが大変なのである。多分、基本クラスのウインドウに機能を持たせ過ぎたせいだと思うので、次回までにちょっと修復するつもりだ。
まあ、お陰でメインプログラムは、スッキリスカスカになったので、自分の精神安定上は、良い結果となったが、メインのクラスは、めちゃくちゃである。
- α−１版での対応項目及び既に実施済みのもの
- 未対応項目
- メニューアイテムのコントロール(ENABLE/DISABLE)
- エディットの更新タイミング(ドロップアウト処理)
- タイマの実装
- ファイルダイヤログの実装
|