不要/必要

機能を実装する際に必要なものと不要なものをそれぞれ考えなくちゃいけない。
考えるのが面倒であればその項目を設定可能にしておけば後はユーザーが勝手に悩めばいいだけ。
でもやっぱ設定を実装するのがややこしかったりどう考えてもいらなさそうな問題もちらほら。

今現在悩んでいるのがタイトルバーの有無です。
ウィンドウ状態のﾈﾑぃにタイトルバーは必要なんだろうか。

どう考えても要らないんですよねぇ。
設定可能にすべきなのだろうか、悩むなぁ。

ウィンドウのサイズ

ウィンドウのサイズをですね、固定したいんですよ。
最低の大きさと最大の大きさを。

うん、WM_GETMINMAXINFO使えばいいのは知ってるよ。
前のバージョンとかRLでも使ってましたから。

分かってるのに実行しないのは理由があってですね、
早い話が最小サイズが分からんのです。
ツールーバーのボタンサイズを基準に考えているんですがツールバーにボタンが無ければ決められない。
文字位置やアイコンサイズによって変わってくるんでどうしても決め打ちできない。

対策を捻くり出さなくてはなぁ。

はい終了

終わった。
平和だったこの素晴らしかった日々が終わった。

労働者の権利

月曜日

色々あって呑みに行くことに。
なんだかんだで浴びるように飲んで体力0.

火曜日

色々あって月曜日の体力が回復せず有給休暇。
午前中爆睡して知人と遊ぶ。
有給は素晴らしい。

水曜日

もはや私に労働意欲はありません。
こんな時間まで起きてたことだし、今日も有給だ。

こうやって人は堕ちて行くんだなぁ。

バグと仕様と進捗状況

ﾈﾑぃの、

• 仕様→skの頭の中と若干の資料
• バグ→skの頭の中と置いてけぼりのコメント
• 進捗→skの暇な時間

ダメだ、そろそろ統一しなければ。

ソースコード自体はCVSを使用するまでも無いんですが上記三項目、特に上位二項目はなんとかしたい。
こういうのはwikiで統合すべきなんだろうか、それともWord(例です。とりあえず一つのソフトって意味で)か何か使って統一しとくべきなんだろうか。

ま、とりあえず完成してから考えよう(最悪だ)。

めもめも

忘れないうちに引っ掛かった部分をメモ。

extern(Windows) int BrowseCallbackProc(
HWND hWnd,
UINT Message,
LPARAM lParam,
LPARAM lpData
)

//------------------------------------------------

typedef extern(Windows) BOOL function(
HWND,
LPWSTR,
DWORD,
DWORD*
) SHChangeIconDialogType;
SHChangeIconDialogType SHChangeIconDialog;

extern(Windows)が無いと怒涛のごとく落ちる。

ランチャーの基盤部分

表題通りですがランチャーの基盤、そして一番重要なこと。
とりあえず何かしらを実行する
コレに尽きると思います。

ﾈﾑぃでは実行するデータをアイテムと呼び、それをファイルに記述しておきます。
内容はアドレスや引数などの実行するのに必要な情報(他にも色々)です。

このアイテム、今のところ四個に区別されます。

• 通常アイテム
• URIアイテム
• マルチアイテム
• リンクアイテム

通常アイテムはアドレスを起動。
URIアイテムはファイルの有無を判定できないけど何かを起動できる。

問題はマルチとリンク。
マルチは複数のアイテムを起動できる(現時点では順々に)アイテム。
リンクは他のアイテムへのショートカットみたいなアイテム。

マルチアイテムは複数のアイテムをバッチ処理よろしく起動することが可能なので特定の環境(A起動させるにはBが必要だからBとAを起動させる)を構築するのに有効かと。
リンクアイテムはリンク先アイテムに情報の上書き(普段はCの作業フォルダはC:\だけどD:\にしたい、その他はそのままで)して使用。
これだけだと意外と使えんじゃね？と思うのですが問題は「循環」。

リンク先アイテムがリンクアイテムだったりマルチアイテムの起動アイテムが同じマルチアイテムだったり、といった状況にどう対処するかが今後の課題です。
制限付きという事でリンク先はリンク以外、マルチアイテム内アイテムは通常・URIアイテムのみといった制限は簡単なんですがいまいち効果を発揮しにくいんじゃないかなぁと思うわけです。
リンク先がマルチアイテムでその中にマルチアイテムやリンクアイテムを呼べる仕様も結構良いんじゃないかと思うわけです。

妙案があれば良いなぁ。

第一回 崖っぷちチキンレース

仕事がね、無いんよ。

うまくいきそうだった案件が他社に取られたんよ。

ほんとにもうやばいんよ。

ていうか、いっそのこと楽にしてほしいんよ。

そんなばかな

ち、ちくしょう・・・！！

ウィンドウとモーダル/モードレスダイアログボックス

敢えて通らずに、ワザと無視して、見たくないものには蓋をして。
でもいつかは作らなくちゃならない、そんなものだと認識しているもの。

ダイアログボックスめんどい。

巷にあふれるダイアログボックス作成方法ではマクロがどうとかリソースがどうとか。
そんなに素敵な環境じゃねーんだよ。
CreateDialogだって中身はCreateWindowEx だしCreateToolbarとなんら変わりない。
ResEdit使って作るのもいいんですが何かと不安多し、Dに。

モーダルダイアログは簡単に実装できるんですがモードレスがめんどい。
モードレス単品で作るにはMSDNを参考にすれば可能なんですがモーダル内でモードレスを実装するのがめんどい。
決め撃ちで書けばいいんだけど今後の拡張性とか考えて汎用性持たせようとするにはめんどい。

めんどい。

クラス

やる気がなくなってきたので気分転換にクラスを作ってみた。

abstract class Gui {
 protected HANDLE hItem;

 this(HWND hWnd) {
  hItem = hWnd;
 }
 final HWND opCall() {
  return hItem;
 }

 /// 以下それっぽいコード
}
class Window: Gui {/* ... */}
class Control: Gui {/* ... */}
abstract class Button: Control {/* ... */}
class PushButton: Button {/* ... */}
class CheckButton: Button {/* ... */}
class RadioButton: Button {/* ... */}
class ToolBar: Control {/* ... */}

ほっとんどがNeGuiからの流用だったり。

クラスが便利な機能だということは、まぁ実際に使ってるんで分かるんですがインターフェイスの何が便利なのかどういった場面で使うのかがいまいち分からんです。
抽象クラス使えば列挙体・フィールド・メソッドが共通項目で実装出来るんだし闇雲にインターフェイスの多重継承しなくても済みますし。

やっぱ、あれなんだろうなぁ。
一人でちまちま書いてるから分からないんだろうなぁ。

なんだかなぁ

-debugコンパイルだと頻繁に
An exception was thrown while finalizing an instance of class クラス名
が出て落ちていたにも関わらず-releaseコンパイルだと落ちない。

やっべ～、隠れた…。

うぃんどうずせぶんべーた

いれてみた