金がねー

あﾞー。
生きてるのか死んでるのかわからーん。

めんどくなった

付箋やめるー

機能追加したい

ちょっくら新しい機能の追加を計画中。
ﾈﾑぃはランチャーなんで他のプログラムが処理できることは極力実装しないというスタンスで開発しています。
ただ、他のプログラムで処理できるけどもわざわざインストールとか面倒なプログラムとかもあるわけじゃないですか。
で、試験的に「付箋」を実装しようかと考えてる次第であります。

どういったファイル構造にするかとかどういったタイミングで保存するとかそこらへん色々考えなくちゃならんのでゆっくり作っていくつもり。

1.080

ﾈﾑぃバージョンアップ。

これといった機能追加じゃなくてバグ修正。
static.akiのバグだったんで結構致命的で笑えた。

ついでにDMD2.037でのコンパイルに対応。

紙なのに金属より高いって不思議だなー

財布にはいてるお札は一万円だと思ってたら野口さんで死ぬかと思いました。

もう師走じゃないか

ﾈﾑぃが1.070になりました。
基本的には修正・更新は 1.06*で行ったので調整的な意味で1.070です。

個人的にはstatic.akiとdynamic.akiの二段構成が気に入ってます。
今バージョンではstatic.akiの記述方法を簡単ながらヘルプファイルに載せたのでそれとパッケージ版同梱のstatic.akiを参照すればある程度ユーザーで値を弄れるんではないかと。

それにしてもvectorの更新遅いなぁ。

今日と明日

仕事休みだ！
やることねー！
ひまだ！
すばらしい！

ひゃー

ﾈﾑぃのバージョンが1.050になったー。

スタートアップからの起動時にﾈﾑぃが実行できないバグを修正、
原因はタスクトレイへアイコン追加時に失敗したら例外を投げていたのが原因。
NeGuiでは停止フラグがONの状態でタスクトレイへのアイコン追加に失敗した場合、一定時間停止、再び追加処理、失敗時に一定時間停止…を一定数繰り返すのですがここで正常に追加できなかった場合例外を投げているわけです。
失敗する場合は「タイムアウト」と「タスクバーがまだ存在しない」場合。

本来この例外を止めなきゃいけなかったけどコーディング環境では「常に」タスクバーが生成済みだったのでこの問題が浮上しなかったわけです。
デバッグ時、意図的にExplorerを落として再びタスクバーが生成された場合にうまくアイコンが追加されていたのでここら辺の受け取り処理はうまくいってるもんだとばかり思ってたよ。

今回のバージョンアップの目玉はほとんどこれだけ。
でも機能的には大きな更新だったので1.050に。

後はまぁ、OS情報でエディションを取得+ソース整理。
エディション取得はMSDNライブラリに例があるので打ち込みが面倒なだけで特に問題なし。
問題はソース整理。

NeGuiの識別子や関数のインターフェイスがぐっちゃぐちゃ。
関数にいたってはポインタなのかrefなのか。
統一せねばなー。

お、お、お！？

日月仕事で火水休みの変則勤務だー。

それはいいとしてこの間ヘッドフォン買ったんですよ。
まぁ一万くらいだろうと思って適当に買ったら奇跡の三万円。
うあー。

ｳﾎﾞｧｰ

Vector登録で以前に登録してるぞボケー、と怒られちゃいました。
あー、そういや登録してたなぁ。

いざ公開しようと思ってもﾈﾑぃの最新バージョンは1.022。
ぜんぜんパッケージ版じゃないし次のパッケージで公開しよっと。

パンがなければコーラでも飲んどけばいいじゃないか

今日更新した1.021はそんなに重要なアップデートでもないのでパッケージ配布なし。
そろそろﾈﾑぃの更新飽きてきたぞー。
とりあえず飽きを忘れるためにVectorライブラリサービスへ登録、掲示板レンタルしたりカウンター設置したり。
そんなこんなしてもやっぱりやる気でない。
NeGuiでもいじろうかなー。

ぬあー。

マシュマロってあんましおいしくないと思った

立て続けにﾈﾑぃのバージョンアップ。
1.010にアイテムのメモが保持されないバグがあったので1.020もパッケージにて公開。

最近はﾈﾑぃの機能からNeGuiに引越しできそうなmoduleを引越し中。
正直GUI以外のmoduleはあんまし移動させたくなかったんですけど今後NeGuiを使用して別ソフトを作る可能性も考えたらpackageまとめておいたほうがいいかと考え決行。
とはいってもNeGuiはﾈﾑぃがつくれりゃそれでいいライブラリという位置づけなんで本当に快適に使用できるかは不明なまま一応検証用としてtest.dを作って実行してみた結果がこの画像。

とまぁこんなかんじ。所要時間は10分くらい。
一応ほかのソフトも作れなくもないかなーと思う今日この頃。
下記がそのソース↓

---

/**

*/
module nemuxi.negui.test;

import nemuxi.negui.allimport;

version(build) {
 pragma(build_def, "EXETYPE NT");
 pragma(build_def, "SUBSYSTEM WINDOWS,5.0");
}

void main() {
 auto aaa=new TestNeGui;
 aaa.execute;
}

class TestNeGui: MainWindow {
 enum CTRL: ITEM_ID {
  HELLO=1,
  EDIT,
  MSGBOX
 }
 private {
  TextLabel label;
  MultiEdit edit;
  Push button;
  
  Font CtrlFont, EditFont;
 }
 this() {
  GUIINFO g;
  super(&g);
 }
 protected override {
  void OnCreate() {
   // メインウィンドウ処理 -------------------------------
   // タイトルバーあり
   caption = true;
   // システムメニューあり
   systemMenu = true;
   // サイズ変更用境界線あり
   frameSize = true;
   // 表示状態
   setShow(SHOW.SHOWNORMAL);
   // 位置とサイズの設定
   move(0, 0, 200, 200);

   // メインウィンドウを親としてラベル作成 ---------------
   label = new TextLabel(this, CTRL.HELLO);
   // 水平位置設定
   label.horizonAlign   = HORIZON_ALIGN.CENTER;
   // 縦位置
   label.verticalCenter = true;
   // 文字設定
   label.text = Text("はろー わーるど");

   // メインウィンドウを親としてエディットボックス作成 ---
   edit = new MultiEdit(this, CTRL.EDIT);
   // 空白にしておく
   edit.text = Text.emptyText;

   // メインウィンドウを親としてボタン作成 ---------------
   button = new Push(this, CTRL.MSGBOX);
   // 文字設定
   button.text = Text("メッセージ表示");

   // フォント生成 ---------------------------------------
   CtrlFont = new Font(Font.STOCK.MESSAGE);
   EditFont = new Font(Font.STOCK.SYSTEM);
   EditFont.pitchAndFamily(Font.PITCH_FAMILY.MODERN);

   // 一括してフォントの設定 -----------------------------
   auto ctrls = new ControlGroup(label, edit, button);
   ctrls.font = CtrlFont;
   // エディットボックスは等幅
   edit.font = EditFont;

   // パネルの設定 ---------------------------------------
   auto panel = new Line(DIRECTION.VERTICAL);
   // ラベルの設定、 あまりの領域
   panel += label;
   panel.sizeInfo(0).absolute = -1;
   // エディットボックスの設定、50%
   panel += edit;
   panel.sizeInfo(1).percent = 50;
   // ボタンの設定、最低限の高さ
   panel += button;
   panel.sizeInfo(2).absolute = button.minContentHeight;
   // それぞれをウィンドウのパネルに設定
   layoutManager.basePanel = panel;
  }

  bool OnCommand(ITEM_ID Id, MESSAGETYPE MessageType, NeGui Sender) {
   if(Sender is button) {
    if(MessageType == Button.EVENT.CLICKED) {
     // メッセージボックス表示
     ShowMessage();
     return true;
    }
   }

   return false;
  }
 }

 private void ShowMessage() {
  // エディットボックスの文字列取得
  auto EditText = edit.text;
  // エディットボックスの改行数取得
  auto LineCount = edit.lineCount-1;
  // 取得文字列から文字列長取得
  auto TextLength = edit.textLength;

  // ダイアログ生成
  auto dialog = new MessageDialog();
  // 表示メッセージを書式付で
  dialog.message = Text(
   "文字列%s%s%s", Text.newline, EditText, Text.newline,
   "%s%s\n", Text.repeat(Text('-'), 40), Text.newline,
   "改行数 = %s\n", LineCount,
   "文字数 = %s\n", TextLength
  );
  // タイトルバーを日時に
  auto time = new DateTime();
  time.format = "[YY]/[M]/[D], [hh]:[mm]:[ss]";
  dialog.text = Text(time);
  // 表示アイコン
  dialog.icon = MessageDialog.ICON.INFORMATION;
  // ボタンの種類
  dialog.button = MessageDialog.BUTTON.OK;
  // 表示
  dialog.show;
 }
}

一応全部で140行くらいでした。

寒いでごわす

DMD2.036入れてみたらコンパイル通った。
あっれー？

1.000公開

ﾈﾑぃを本意じゃないけどまぁいいやと思ってβから1.000に移行しました。
本来ならば1.00β1Aになっていたはずなんだけどね。

今バージョンもDMD最新版ではコンパイルできず2.032を使用。
各モジュールは可能な限り2.035でコンパイル+単体試験はしてるんで早いこと移行したい限りです。

そんだけ。

さぶい

久々に更新で10月もそろそろ終了なわけですが特に書くことがありません。

ﾈﾑぃの開発の方は依然よく分からない方向に進んでいてワケ分からん。
何だろう、importでDMDが落ちる。
循環とか関係なさそうなんだけど再現方法が分からないんで再現するための最小コードが書けない。
とりあえず以前書いたとおりコンパイラ以外は最新でコンパイラのみ3.032で行く方針で進めていく予定。

うん、謎だ。

コンパイルが通らないので一通りモジュールの整理を実施したけど駄目だった。
NeGui自体は(一部思いっきりﾈﾑぃに依存してるけど)単独でコンパイルできる状態になった、が、ﾈﾑぃのソースは絶望的に無理状態。
言語リソース用のモジュールが引数の問題でごちゃごちゃ循環してるんでそれが足枷になってコンパイル不能。

仕方ないから2.032に戻すかなぁ、と考えもしてみたんですが戻せば戻したでstd.convが死んでるんでその対処もしなくちゃならん。
というわけで現状はライブラリ2.033、コンパイラ2.032で行くことにしました。

まったくめでたくないけど、めでたしめでたし。

DMD 2.033

Assertion failure: 'var' on line 3976 in file 'expression.c'

盛大に死んだ。

十月だ、お月見だ、寒くなってきた

β19公開です。

機能的には文字列リソース外部化くらいしか追加なし。のはず。
 あーあと二重起動の禁止フラグの追加とか。

特に書くことなし。

一言

感熱紙プリンターが欲しい。

そろそろ脱βしたい

文字列リソースの表示部分だけは外部へ押しやることが出来ました。
外部にやったはいいんだけれどもそのファイルが存在しない場合は内部の文字列を使用しよう考えたまでは普通なんですが、普通にやるのも面白くないなぁ、とか考えてしまい出来たのがこれ。

無駄に半角カナ。
アホだ。

Dで直に書いててPostfix文字も着けてないんで素直にUTF-8。
一文字3バイトはあるであろうS-JISより無駄豪華な文字列リテラルです。

なんかしらんけどkernel panicから復帰した。正直怖い

書いてると疲れてきたんでドキュメント書くのストップ。
文字列リテラルの外部化でもやります。

かーねる☆ぱにっく

β18公開～。
取り敢えずUIをちまちま変更。
Lineパネルを改良して若干使いやすくしたもののグループボックスとの相性がよろしくなくて即値(50%とか)が増えた感じ。
でもまぁ本体設定の見栄えが幾分かマシになったので良しとします、うん。

次期バージョンではドキュメントの記述に重点を置きます(やったー、バグで悩まなくて済む！)。

うちのCentOSがkernel panicで死んだ

β17だー。

コマンド型の暫定的な実装が主な更新。
DLLも更新したので今回もパッケージ配布で準備が面倒、そろそろ一括バッチでも作ろうか。

今回実装したコマンド型は入力された文字列を正規表現として扱うのでちょっと使いづらいかも知れないので将来的は通常検索・ワイルドカード・正規表現を切り替えられるようにしたい。
Migemoはあまり心惹かれないので実装する気なし。

次バージョンはUIの強化(整理)なんでパネル辺りを重点的にやるかー…。
そのまえにファイルサーバー直さないと…めんど。

マウスフックが直ったー②

やっとこさ直った。
訂正、多分直った。

こっからの話は「恐らく」になると思うんですが原因はDMD2.030から扱いの変ったグローバル変数、TLS変数のおかげ。
フックってDLLを使用する場合は共有メモリを使用、共有部分をグローバルに置いとくのが王道だと思うんです。
だたD(2.030以降)ではこのグローバル部分がスレッド別に置かれるんで変になっていたっぽい。

__gsharedしたらきちんと動きました。
しんどかったー。

マウスフックがバグってたー

謎が多すぎる。
コマンド型を実装してからマウスフックでﾈﾑぃがサヨナラする事象が発生中。

コマンド型で入力補完的なコンボボックスのリスト部分的なものを表示させてからマウスフックを使用すると

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at HOOKER.DLL (0x012b8127) thread(6100)

が発生。
Hooker.dllを使用していなければ大丈夫。
非常に意味が分からない。
DDBGで動きを見る感じでは

1. ﾈﾑぃ起動
2. 起動の最後にHooker.dllがロードされる
   
   

   No symbols available from HOOKER.DLL
   HOOKER.DLL loaded at 0x012b0000

3.  コマンド入力ウィンドウを表示
4. 何か入力するとリストが表示され以下がロードされる
   

   No symbols available from IMJPSQM.dll
   IMJPSQM.dll loaded at 0x3ac70000
   No symbols available from IMJPCD.DIC
   IMJPCD.DIC loaded at 0x3ae00000

5. ここで分岐。
   
6. ①このままリストからアイテムを選択して実行すると以下がロードされて何事も無く動く。
   

   No symbols available from NETAPI32.dll
   NETAPI32.dll loaded at 0x59250000
   No symbols available from urlmon.dll
   urlmon.dll loaded at 0x442a0000
   No symbols available from iertutil.dll
   iertutil.dll loaded at 0x40930000

   
   ②リストを無視してデスクトップでホイールクリックすると
   
   

   EXCEPTION_ACCESS_VIOLATION

ワケが分からん。

いやいやいやいや

Access Violationが発生中。
場所がわかんねー。
DDBG使ってもわけわからん。

Unhandled D Exception (std.contracts.ErrnoException
 "C:\dmd\dmd\src\phobos\std\stdio.d(896):  (Bad file descriptor)") at KERNEL32.dll (0x7c812afb) thread(2632)
->;us
#1 0x004bd728 in __d_throw@4 () from deh
#2 0x004bd538 in extern (C) int rt.dmain2.main(int, char**) . void runMain(void*) () from dmain2
#3 0x004bd575 in extern (C) int rt.dmain2.main(int, char**) . void runAll(void*) () from dmain2
#4 0x004bd2e8 in _main () from dmain2
#5 0x00521695 in _mainCRTStartup () from constart
#6 0x7c817077 in ?? () from KERNEL32.dll
#0 Access Violation

せめて変数名だけでも分からないもんだろうか。

Zippoがつぶれた！

プランプランだ。
修理出さねば。

コマンド型

なんだろう、うまくいかない。
エディットボックスだけ置いて完結したい。


もうこれでいいじゃん。

こないだネットワーク難民になった

はてさてβ17に向けてコマンド型ランチャを考え中。
現状の なんとも言い難い実装を使うべきか新たに書き直すべきか。

コマンド型っていうと一行分の入力欄にコマンドを入力して登録ファイル等々を実行するのが普通なんでそれを踏襲すべきか、それとも違った実装で行くか。
どっちかって言うと後者を採用してCUIちっくな実装にしたいんだけど中々決まらない。
とりあえずコード書くのが鬱陶しいなぁ。

DのDLLでかすぎ

β16ぅぅ。

ソースコードの整理が主で特に機能変更等は無し。
マウスフック用のHooker.dllのフック解除時のコードが若干怪しかったんでその部分の修正もあり今回はDLLも配布ということで久々のパッケージ・単独ファイルの公開です。

今後の予定は、

• β17→コマンド型の実装
• β18→設定画面のUIをいじる
• β19→ドキュメントの整備

この流れで行こうかと。

電波時計の電池が意外と長持ちでびっくり

ﾈﾑぃがバージョンアップした感じです。
ソースがあまりにも汚くなったので次バージョンは機能の追加はせずに整理に重点を置きたいなぁ。

今回の主な変更点はアイテム選択時のコンボボックスやリストボックスに対象アイテムのアイコンを描画するようにしたこと。
今まではアイコン読み込みに掛かる時間等を考えるとあんましやりたくなかったのですが適当にファイルを30個くらい読ませてみたら意外と速く処理できたのでじゃあ実装してみよう、といった感じで進んでいきました。
まぁそのおかげでソースが凄く凄く読み難くなってしまいましたが、、、てか、あれだ、書いてて気付いたけどイメージリストのkill忘れてるわ今回。

他にも色々やったけどアイコン描画がいろんなところに影響しすぎて修正しまくってその過程でなにやったか忘れた。

最近コーラがやたらうまい

DMD2.032のtoで泣いたけどD言語 Part22の839氏も死んでたっぽい。
修正パッチへのリンクもあったのでそれを参考にtoで泣かなくてよくなりました。

ﾈﾑぃの設定画面で多用しているアイテム一覧のコントロールをそろそろ綺麗にしようと思いコンボボックス→拡張コンボボックスに変更しようと思いましてコード実装してみたらすごく変。
STANDARDなら大丈夫なんですけどDROPDOWNとかを指定すると途端に動かない。
いや、動いてんだけどリスト部分が表示されない。
あっれ～ってなりながらGoogle大冒険した結果MSDNのUsing ComboBoxEx Controlsにあんましよろしくない文が。

---

hwnd = CreateWindowEx(0, WC_COMBOBOXEX, NULL,

                    WS_BORDER | WS_VISIBLE |

                    WS_CHILD | CBS_DROPDOWN,

                    // No size yet--resize after setting image list.

                    0, // Vertical position of Combobox

                    0, // Horizontal position of Combobox

                    0, // Sets the width of Combobox

                    100, // Sets the height of Combobox

                    g_hwndMain,

                    NULL,

                    g_hinst,

                    NULL);

---

英語わかんないなりに訳してみるとイメージリスト設定後にリサイズできないの？

とりあえずよく分からんけど適当に実装してみた。
以上、同じ問題で誰かが悩まないようにメモ書きです。

←実装した結果。

BBS

掲示板が欲しい。
自分で作る気もさらさらない。

今日は仕事がお休みだー。

あー、β14公開です。

公開って言っても今回バイナリ配布じゃないしそこまで公開しなきゃいけないってもんでもありませんでしたから。

機能的な変更は環境変数の動作が不完全だったバグを修正したくらい。
内部的にはstringからﾈﾑぃで使用しているTextって型に移行中。
カレキとの兼ね合いでstring使っているところもどうせ外向けにはTextに変換してるんだし最初からTextでいいじゃないかという思惑で作業中。
ある程度変換作業が進み動くようにはなったので公開した感じです。

今回から更新記録をBloggerに移行です。

なんか部屋がやたら寒い

string -> Text へ移行中。

ItemとかはKarehaとの兼ね合いもあってstringを使ってるんですがいちいち変換するくらいなら全部Textで良いじゃないかと思いましてText変換中。
そしたらtoStringが凄く増えた。
処理速度は多分下がる。

だ、だ、だ、だ

β13アップデート。

今回の主なバージョンアップはD&D時のショートカットファイル対応です。
ファイルがD&Dされたときの動作やコードはまだまだ未完成ですがCOMを実装したということでのお披露目みたいなもんです。

というかCOMの実装にえらく手間取りました。
どうもBindings for the Windows APIのIShellLinkが変でIUnknownのメソッドまで定義されてたのが原因だったようですが、これに気付くのに4-5時間ほど掛かりました。
まさかwin32.*に問題があるとは思いもしなかったよ。
んでCOMに関してはwin32.*を使用するの怖いなーと思ってたらwin32.uuidがなんか変。
とりあえず

module win32.uuid;

import win32.basetyps;

extern(C) {
const IID GUID_NULL = {0x00000000, 0x0000, 0x0000, [0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00]};
}

version(none)
export
extern(C) {
const IID _DBBMKGUID = {0xF6304BB0, 0xD188, 0x11CD, [0xAD, 0x48, 0x00, 0xAA, 0x00, 0x3C, 0x9C, 0xB6]};
...
const IID TID_DXFILEHeader = {0x3D82AB43, 0x62DA, 0x11CF, [0xAB, 0x39, 0x00, 0x20, 0xAF, 0x71, 0xE4, 0x33]};
}

これで対応。
あとはnemuxi.com.*に自前で必要な分だけ定義してます。

う、う、う、う、う

β12アップデート。

今バージョンではログ機能が使えません。
↑前バージョンでもソース読まなきゃまず使い方分かりませんが。
ログの実装が弄ってたら死にました。
だめだなぁ、グローバルなところに書くと。

急に涼しくなったけど温暖化はどこに行ったんだろう

昨日くらいにﾈﾑぃのバージョンβ11を出して一安心の今日この頃。
バージョンアップしたその瞬間からβ12への修正へ進むんですが修正なりなんなりすることが分かってるんだから公開しなきゃいいのに、と考えてしまう自分もいるわけです。
β版も早めに卒業したいので最高でβ20(16進だけど)までを限度と考えてます。

β12に向けて実装しようと考えている部分は下記の通り。

• メインウィンドウの細かな制限
• アイテム設定の作業簡略化/未実装部分の実装
• グローバルな設定をローカルへ

コマンド型とか本体設定はまだ今回はさわりません。
ドキュメントやらサイトの整備やら色々修正せねばならんことが多くなってきたのでゆっくり一つずつやっていきたいです。
…たぶん無理だけど。

なんじゃこりゃー

最近PCが変だ。

今年かき氷食ってねー

ﾈﾑぃ、公開しました。
何を切羽詰っていたのかえらく急ぎで公開したんで足りないファイルあるかも。

断っておくと目に見えて未完成なんでバグあったら暖かい目で見てやってください。

ヘルプファイルってやっぱりだるいー

いざ作ろうと思ったヘルプファイル。
やはりというか、だるい。
何がだるいって使い方を知っているモノの使い方を記述するのがすげーだるい。

• プレーンテキスト
  
• Winヘルプ
• CHMヘルプ
• HTMLヘルプ
• Web上のオンラインヘルプ
  

さて、どれを使おうか。
サーバーにヘルプページ作っておくのが一番楽そうではあるのですがいかんせんヲコノのサーバーは借り物なんで無茶は出来ない。
CHMが一番いいかもしれませんが、なんだろう、Help WorkShop落とすのだるい。

こんなことを考えててふと頭に浮かんだのがHTA。
うん、選択としては最悪なんだけど面白そう。
2-3日遊んでみて作れそうならHTAで作ってみます。

先走り

機能不全、ソースも未整理。
仕様も定まっていませんがとりあえずヘルプファイルを作ろう。

なんじゃこりゃー

無題

さっきだ、ついさっき、20分くらい前！

あれ？　そーいや昔修理交換した古いZippoの内ケースにウィック入ってなかったか？

と、思ったわけですよ。

あったよ！
ウィック入ってた！！

というわけでZippo復活しました。
修理出したときは何故に古い方の本体も返ってきたんだろうとは思いましたがまさか今になって必要になるとは。

世の中分からんもんだなぁ。

無題

しばらく掃除してなかったZippoがえらく汚くなっていたので掃除しようと分解してみるとウィックがそれはもう短くなっていてびっくり。
石を支えてるバネと良い勝負の長さになっていたのでコンビニに行くもオイルと石しか売ってない。
スーパーに行っても売ってない。
以前コンビニで買った覚えがあるんだけのなぁ。
どこに売ってるんだろ。

もうすぐ詰みそうな詰め将棋

何だろう、D上での失敗なのかWindows上での失敗なのか分からん。

マルチアイテム用コントロールを作ってその中にアイテム選択用コントロールを配置したんだけれどもアクセスできない。
とりあえず自分で読んでも意味解らない上の一文ですが、ddbgにプログラム渡してやってみた状態はこんな感じ。
invalid class pointerって怒られる。
直訳で無効なクラスのポインタ。
わけわからん。

マウスフックが直ったー

直った、というか出来た？

破れかぶれにMmFile使ったらなんか出来た気がせんでもないような気がする感じ。
ただ初っ端のテストコンパイルでブラウザがいきなり落ちたのが気になる。
俺か、俺のせいなのか。それとも偶々ブラウザが落ちたのか。

謎は深まる夏の夜。

マウスフックでバグったー②

いや、まじでこれどう書くの？

色々調べてみたけど#pragma data_seg(".hookdata")ってDで代用できんの？
Budのpragmaの項目読んでみたけどそれっぽい記述は見当たらず。
やっべー、やっべーーー。

マウスフックでバグったー

---------------------------
توكوغاوا إيئه-ياسو: nemuxi.exe - アプリケーション エラー
---------------------------
"0xe4cbbdff" の命令が "0xe4cbbdff" のメモリを参照しました。メモリが "read" になることはできませんでした。


プログラムを終了するには [OK] をクリックしてください
---------------------------
OK
---------------------------

終わりが見えた！

ﾈﾑぃの完成が見えてきた！
面倒なチェック動作や入力支援機能などなど、絶対必要だろうと思われる機能を省きまくったら意外と速く完成しそうだ！

とにかくまぁ、そういった機能は完成してから実装します。

梅雨あけて、少し晴れたら、たいふーん

最近ﾈﾑぃを作ってなかったのでちまっと作業開始してみた。
分かったことはインターフェイスの継承具合がとてもとても変だってこと。

設定部分の続きをちまちまやってみたんですがどうにもやることが多そう。
一応ある程度の実装はバッサリ切って進めてはいるのですがそれでも作業は少なくなりそうにありません。
※初期値の設定だとかアイテムの循環問題は面倒なんで後回し。

ながいなー。

くしゃみが止まらん

セミが鳴き出した！！
もう夏だ！！

暑い！！！

無題

だれかお金ください。

割り算って難しい

パネルがね、ずれるんよね。

エラーが長い。

パネルが一応完成しました。
実装したのは三個。

• Tansu
  タンス型のパネル。
  各セルの大きさが同一。
  
  
• Line
  直線状に伸びていくパネル。
  セル毎に大きさを保持。最終セルの大きさはLineに処理させることが可能。
  
  
• Dual
  セルが二つのみのパネル。
  Lineを機能限定した感じ。

とりあえずこんだけ。
構想上はGrid(Table?)パネルが欲しかったのですがTansu/Lineの中にパネル放り込めば代替手段になることに気付いたので未実装です。

あと.Netなんかだとパネルが一つのコントロール(ウィンドウ？ .Netの詳しいことは知らん)として扱っているみたいですがNeGuiではレイアウトマネージャに付随するサイズ変更情報として扱っています。
レイアウトマネージャもベースパネルへの連絡役です。

適当にWS_CHILDつけてコントロールでも作ってれば素直に作ることが出来たかもしれないんですがグループボックス作ってそこにコントロール乗せた時にメッセージループの取捨選択とか結構泣けたのでもうあんな思いしたくねーなーと考えた結果、コントロール作らずに回り道しています。

あとﾈﾑぃの実装じゃなしにT* -> ref T, const T* -> ref const(T)とかやってます。
こういうのするから進まないんだなぁ。

---

↓エラー↓

Unhandled Exception: EXCEPTION_ACCESS_VIOLATION(0xc0000005) at nemuxi.gui.nemuxi.window.nemuxiwindow.buttonlauncher.ButtonListMenu.show.nemuxi.gui.nemuxi.window.nemuxiwindow.nemuxiwindow.NemuxiWindow.nemuxi.gui.control.control.Control.nemuxi.file.items.item.Item gui\nemuxi\window\nemuxiwindow\buttonlauncher.d:319 (0x0045b5e0) thread(1208)

サーバーが熱い

人は皆、過ちを犯すものなのです。
それに事前に気付いて対処するか、すぐ気付くか、後になって気付くか、一生気付かないか。

「設定プログラムを作るぞー」までは進んだんですがコントロールを増やしていくとWS_SIZE来たときに悲惨極まりない。
グループボックス作ろうが何しようが最終的にはMoveWindowの嵐で頭狂いそうになります。
NeGuiでは一応簡略化してるんですがそれでも頭が頭痛で痛い。

そんな状態なんで俗に言うパネルっぽいのを実装することにしました。
構成図としては、

• Layout(abstract)
  
  • LayoutManager(final)
  • Panel(abstract)
    • XXXPanel
    • YYYPanel

こんなもんでいくつもり。

なんか最近機能を追加するたびに肥大化していくなぁ。
実際使わねーだろーなぁ。

Invariantってどうなんの？

あれやこれやで六月も残り十日を切りました。
梅雨で嫌な時間に雨が降るようになりﾈﾑぃの作業は進みません(季節関係ない)。

やる気がなくなったときにやる作業、ずばり現状モジュールの手直し(改悪か)。
お勉強も兼ねてinとconstとinvariantをそれぞれ設定してみました。
作業してて思ったんですがinvariantって今後はimmutableに置き換わるのか？
全文置き換えで対応できるよね…？

importでエラー

テストコンパイルせずに複数のモジュールをあれこれ触りまくって引き返せないところまで来たときにコンパイル。

Error: enum 列挙体 is forward referenced の絶望感って異常ですよね。

オセロ

つい最近のことですが仕事中に四時間ほどやることが完全になくなることがありました。
そんだけ暇なら何か作ろうかなぁとオセロ作ってみました。

環境は標準のXPproで開発環境無し。
IE6(ネットワークから完全に独立してるのでアップデートも無し)とメモ帳コンビでJavaScriptをちまちま打って基盤のみ作成。
ホントしょうもないことで二時間くらい無駄にしたけど一応使えるようにはなりました。

また機会があればそのときにでも載せたいと思います。

業務スーパーでカップうどん買った

そろそろ設定プログラム実装する。
いい加減引き伸ばす口実もなくなってきたしほかにやることないし。

実装しなきゃいけないリスト↓

• 設定プログラム
• コマンド型ランチャ
• ログ（機能は出来てるのでどこで取るかが問題なだけ）
• 本体へのD&Dによる処理（登録するかファイルの起動か）
• アイテムの循環参照問題
• マウスフック
• 外部ツールとの連携インターフェイス（char[]での標準出力はもう取れてるから何と連携するか）
• 外部文字列リソース（優先度最低）

こんなもんかな。

とりあえず設定プログラムを実装してからそれ以外の項目を消化してきます。

class Accelerator: HandleRaii

キーボードアクセラレータ実装完了ー！！

マスカー

マスク多すぎ。

通勤電車で大量のマスク。
インフルエンザがマスクで防げるのか知りませんがみんなマスクしすぎ。

仕事場に着いたら着いたでみんなにマスク装備を強要。
ここで俺もマスク装備。

まぁあれだ。
みんなマスクしてるんなら俺別にマスクしなくてもいいんじゃないの？

テスト前に掃除したくなる現象発病中

設定プログラムの実装がだるいので全然関係の無い機能の追加中。
左上から順に

• アップダウンコントロール
• ホットキーコントロール
• DTPコントロール（日付）
• DTPコントロール（時間）

です。

作っていて思うんですがスタイルの付け替えで反映される・されないの資料ってMSDNの原文しか無いんでしょうか。
俺英語読めないし。

メモ帳だと右端で折り返すを選択するとコントロールそのものを作り直すらしいのですが現時点でのNeGuiだとフォントとかその辺のGDIオブジェクトの世話してられないんで未実装です。

---

以下チラシの裏

---

/**
テスト専用ダイアログ。
*/
module nemuxi.test.debugdialog;

debug import std.stdio: wl = writefln, pl = printf;
debug(debugdialog) void main() {}

import win32.windows;

import nemuxi.base;
import nemuxi.draw.image.font;
import nemuxi.gui.gui;
import nemuxi.gui.window.dialog.dialog;
import nemuxi.gui.control.control;
import nemuxi.gui.control.editbox.editbox;
import nemuxi.gui.control.updown.updown;
import nemuxi.gui.control.hotkey.hotkey;
import nemuxi.gui.control.time.datetimepick;


debug{} else {static assert(false, "debug only!");}
class DebugDialog: ModalDialog {
enum CTRL: ITEM_ID {
INPUT=1,
UD,
HOT,
DTP1,
DTP2,
}
Font font;
ControlGroup group;
EditBox Input;
UpDown spin;
HotKey hot;
DateTimePick[2] dtp;

this(NeWindow Owner) {
GUIINFO GuiInfo;
GuiInfo.Owner   = Owner;
GuiInfo.Style   = WS_DLGFRAME | WS_CAPTION | WS_THICKFRAME | WS_SYSMENU;

super(&GuiInfo);

posSize(300,300);
}
protected override {
void OnCreate() {
font=GetSystemFont(SYSFONT.MESSAGE);

Input = new EditBox(this, CTRL.INPUT);
Input.move(0,0,100,30);

spin =new UpDown(this, CTRL.UD, UpDown.POSITION.RIGHT);
//spin.move(101,101,100,100);
spin.buddy = Input;
spin.range(-1000,1000);

spin.value=159;
spin.reLoad;


HOTKEYVALUE hk;
hk.modToHotkey(MOD.SHIFT);
hk.Key = KEY.D;

hot = new HotKey(this, CTRL.HOT);
hot.textAlign=TEXTALIGN.CENTER;
hot.move(100,0,200,30);
hot.rule(HotKey.RULE.NONE, HOTKEY.EXT);
hot.value
=hk;


dtp[0] = new DatePick(this, CTRL.DTP1);
dtp[0].move(0, 40, 200, 30);
dtp[1] = new TimePick(this, CTRL.DTP2);
dtp[1].move(0, 80, 200, 30);
dtp[1].value=new DateTime(
1999, 12, 31, 0,
23, 59, 59, 999
);

group = new ControlGroup(
Input, spin, hot, dtp[0], dtp[1]
);
group.font = font;
}
}
}

どうして寝た子を起こすんだ

中途半端なNeGuiに置き換えてから一向に作業が進まない。
設定部分を実装しようにもちょっと書いては消してちょっと書いてはまた消しての繰り返し。
全然進まねーなぁ…。

設定部分がやる気無いんならコマンド型の実装でもすっかぁと思ったんですがこれもまた進まない。
もうコンボボックス貼り付けてエンター検出してGOでいいんじゃないかと本気で考えてる。

すすまねー。

設定機能

☆　無　気　力　全　開　☆

NeGui復活！

とりあえず復活。
えらいしんどかった。

定額給付金

• Advanced Windows 第5版 上 (マイクロソフト公式解説書) (単行本)
• Advanced Windows 第5版 下 (マイクロソフト公式解説書) (単行本)

買っちまったZE

伏線だったのか！

そう、まさかあの時の僕はこんなことになるなんて微塵も思っていなかった。

大変な事態になってしまった。

僕の心はルネサンス

なぜだろう。
関数定義のウィンドウプロシージャベースで行くって決めたのに今になってNeGuiを復活させようとしている。
今になって、ウィンドウとかコントロールの適当Guiクラスが完成しかかってからの路線変更。

大規模破壊的更新を行います！
完成しません！！

IEはね、戦歴の猛者なんだよ

世間の流行から少し遅れて


←こいつを入れてみました。


軽いっちゃ軽いんですが薄っぺら過ぎやしませんか？
シンプルなのが良い人には良いんでしょうけど俺は常用での使用は無理だなぁ。
ただし速いってのは素晴らしいなぁとMSDNにアクセスしたときに感じ、
俺の中でこの子はMSDN専用ブラウザになりました。

#ステータスバーが無いのは許容し難いなぁ。
#ウィンドウサイズの変更が面倒なんだよなぁ

無題

450m×六周がんばった！！

つかれたぁ

writelnで第一引数は文字列じゃないと駄目なのね…

D 2.029

だめだ、いつもバージョンアップには諦観を込めて作業してるんだけど今回のはきついかもしんない。

C:\dmd\dmd\src\phobos\std\traits.d(1011): Error: static assert "Type const(int) does not have an Unsigned counterpart"
C:\dmd\dmd\src\phobos\std\traits.d(2454): Error: template instance std.traits.Unsigned!(const(int)) error instantiating
C:\dmd\dmd\src\phobos\std\conv.d(2454): Error: Unsigned!(const(int)) is used as a type

どっから呼び出してんのかわっかんねー

きたよ

今日DMDの新しいのを入れてみました。
うごかねー

D 2.029

今日はもう眠いんで明日入れる！
D 2.029

痛い

筋肉痛だ

体力0

つい先日電車に間に合いそうに無かったのでほんの200m程の距離をダッシュしました。
なんとか電車にゃ間に合ったわけですが陸地で溺れた状態。
やばいくらいに体力が無い。

というわけでつい先ほど走ってきました。
一周450mのコースで三周したところで完全にダウン。
陸上部だった中学校の頃は20週くらいやってたのになぁ、おっかしいなぁ。

これからちまちま走ることにして体力を増やさないと。

ヒッ

しゃっくりが、止まらない！！！

TOP VALUEのオレンジジュースがうまい

基本動作を確認しつつ細かい部分の実装中。
以前書いた問題点はズルズル引きずって未だに関係ないとこ実装中。
設定プログラムやる気しねー。

抹茶うめぇ

そろそろﾈﾑぃの基本実装が終わります。
設定ファイルの反映が終わったので個人的に使用するには問題ないかと。
未実装としては

• コマンド型のリスト表示(コンボボックスを使用していましたが操作感が気に食わないので再実装中)
• アイテムの循環参照問題
• マウスフック(DLLめんどい)
• 外部ツールとの連携インターフェイス
• 外部文字列リソース
• エラー用内部画像リソース(もしくは対処方法)
• 設定画面

これっくらいですが最大のネックは設定画面です。

自分で作ってるんだから設定ファイルの記述方法は理解してますし記述してます。
そんな事情もあり最後まで引っ張ろうと考えてここまで来たのですがもはややる気が出ない。
RAD無しで設定部分を作るのは変体の極みなんじゃないだろうか(RLもそうだったけどさ)。

さらに設定ファイルを下手に独自形式にしたのがまずかったかもしれないです。
XMLでやっときゃ適当に誤魔化せたかもしれないなぁ。

春の日に、冬みたいな、重装備

まったく持って活気の無い日々をただ過ごす新年度。
新入社員の方々、入社おめでとう。
がんばれ残り365日×40=12000日以上のお仕事。

もう生きることすら苦痛の親知らず

急患で歯医者行ってきました。
あまりの痛さに仕事行かずに歯医者へ直行。

ドリル：
「あ～これは～、炎症起こしてますね～
取り合えず噛む時に干渉してる上の親知らず、抜きますか？」

sk：
「一思いに」


い～た～い～

親知らず、三度

死ぬ。

歯医者がなかなか抜いてくれなくて、歯医者に行く時間が無くなって、2-3ヶ月放置していた親知らずが暴れだした。
昨日・一昨日に歯茎に異常を察知、今日になって絶好調の痛みをプレゼントしてくれています。
もうご飯食べれない…。
予約を取るために電話したら来週の土曜日くらいまで予約でいっぱいとのこと。

死ぬ。

一応予約はしたけど来週って仕事で無理っぽい気がするんよねぇ。

死ぬ。

モーダルダイアログ

モーダルなダイアログを作りたかった。
戻り値を返してくれるダイアログが欲しかったんですがリソースを使うにはあまりに心もとない。

他力本願一直線ですがIDEできないかなぁ。
リソース・デバッグ・管理に革命が起きるのになぁ。

人生予定

ここ最近、何に対してもやる気が起きない。
無気力というか何に対しても希薄な感じなんです(これを無気力って言うんだけどさ)。

取り合えず来年くらいに旅に出ます。
仕事辞めて貯金0になるまで旅にでます。

若いうちにバカしないと。

無題

IE8日本語版がリリースされたということなんで入れてみました。

文字列選択時にアイコンが出てきたりといろいろ機能追加されてる模様。
ただ、エンコード＞自動選択、日本語(自動選択)だとBOM無しUTF-8のページは未だに真っ白。

これを直して欲しかったなぁ。

日時と書式

え～っとですね、std.timeがちょっとなぁ、といった内容ですので実装することにしてみました。
そんで実装するにあたって書式もサポートしなくちゃならない気配が。
素直にGetTimeFormat使いたかったのですがミリ秒までサポートするとなると使えない気が。

まいったなぁ。

計画することは大事なんだね

内部設計がグチャグチャになってきたぞー！

ウィンドウ関連の関数を作る場合にはHWNDを引数に作っていたのですがこれだとHWNDとHDCの区別がまったく出来ないのでGuiクラスやCanvasクラスなんぞを構築したのです。
この設計から(時の流れとうっかりで)外れた関数、サブクラス化とかそういったのがHWNDを受け取るようになっていて素晴らしい混乱ぶり。
なんだかもう弄れば弄るほど、修正すれば修正するほど阿鼻叫喚な状態になってきた。
てかもうNeGuiの出来損ないみたいなクラス郡が。。。

チャイナ!チャイナ!チャイナ!

仕事取られた。

不要/必要

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

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

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

ウィンドウのサイズ

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

うん、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コンパイルだと落ちない。

やっべ～、隠れた…。

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

いれてみた

いつも知人にもらってたけど今日生まれて初めて傘を買った

営業：
「なぁなぁ、sk君」

sk：
「なんすか」

営業：
「ロト6当たらへんかなぁ？」

sk：
「いや、頼み事みたいに言われても」

営業：
「当たったらいいや～ん」

sk：
「まぁ確かにいいですね、当たれば。
俺もよく買ってない宝くじ当たらへんかなぁっとか考えますし」

営業：
「買ってないもん当たるかい」

sk：
「買っても当たらないですけどね」

営業：
「俺なぁ、思うんやわ。
神様って忙しいんとちゃうんかと。
でな、俺が祈ったところで神様んとこまで届かへんねやわ。
だから神様に祈るとき両手合わせてお祈りした後にな、

住所と電話番号と名前

を伝えることにしてんねん」


sk：
「末期すね」

ExceptionとErrorとエラー処理

• まだだ、まだ終わらんよ！
  →Exception
• 我が生涯に一片の悔い無し！
  →Error

try~catchが使用可能な言語を使用していればこんな感じだと思います。
プログラムの流れとしてはこいつらが飛んで来た時に受け止めて何か処理、受け止められなければさようなら。
そいでですね、こいつらを受け止めた際にメッセージか何かを表示させるのが王道だと思うんですが、そこに表示させるメッセージってException.toString()とかそのまま表示させて良いもんなんでしょうか。
正直ユーザーからしたらstd.utf.UtfException: illegal UTF-16 valueなんて表示されても「なにコレ？　バカ？」としか思わないんじゃないんだろうか。
組んでる人間も「知るかよ、動けよ」としか思わないわけですし(俺だけか)。

こういった場合に一番良いのは何だろう。

1. タイトル：例外発生
   メッセージ：UTF-16文字列が不正です
   詳細：std.utf.UtfException: illegal UTF-16 value
2. タイトル：文字列処理失敗
   メッセージ：入力された文字列を処理できません。※UTF-16文字列を使用してください。
   詳細：std.utf.UtfException: illegal UTF-16 value。
3. タイトル：エラー
   メッセージ：std.utf.UtfException: illegal UTF-16 value

作ってる人間からしたらどれも一緒だなぁ…。

例外とAccess Violation

import std.stdio;

void main() {
Test test;
writeln(test.toString);
}

class Test {
override string toString() {
return "test method.";
}
}

> dmd -run Z:\test.d
> object.Error: Access Violation

頼むからもう少しまともなエラーを出してくれないか、DMD。
インスタンス生成してないことに気付くのに10分はかかったよ。

先頭からこんなこと書いてますが何が言いたいかというと、

Visual Studioが素晴らしすぎる。

DMDだけだと開発効率最悪な感じがします。
100行程度の小物作るには問題ありませんがWindowsAPI使うようになってくるともうダメダメ。
あの時このプログラムはどうなって死んでしまったか、といった情報も分かりにくいんでとりあえず-debugではstd.writeでログ書き出し、そしてひたすら追う。
それはそれでD(実質DMDがD言語)っぽいから面白いんですがねぇ…？

はやくIDEが欲しいです。
純正、って言うのもおかしいですがD専用のIDEが。。。

基底←継承←継承←継承←継承←バグ倉庫

オーナードローメニューの設計ミスった。

仕事場でのRDPが革命過ぎて窓際一直線

最近家に帰るのが早くて20時には帰宅しています。
いや～、仕事が無いってのも疲れるなぁ。
今年度の前期が嘘のようですよ。

で、帰宅が早いのでﾈﾑぃに取り組む時間が増えました。
ちょっと贅沢にメモリを使いまくって快適にプログラミング、
のはずだったんだけど詰んだ。
もう精一杯詰んだ。

＠文字列
ああ、わかってるさ。
Dの文字列が0終端じゃないってことくらい十二分に分かってるよ。
むしろ変に理解してたから駄目だった。

ﾈﾑぃの内外(D部分とWin32API部分)の橋渡しはTextって構造体が担当してるんだ。
省略して書くと

struct Text {
    /// 実態。
    wchar[] text;
}

こんな感じで内部に ptr ってメッソドがあるんだ。
こいつが駄目だった。

struct Text {
    wchar[] text;

    wchar* ptr() {
        return (text ~ null).ptr;
    }
}

text配列とnullを結合してたんだ。
コレで大丈夫だと思ってたんだ。
ここで0終端文字列を作ってると思ってたんでこいつをあっちゃこっちゃに使ってたんだ。
一通りの基盤部分が作り終わってメインウィンドウだけの結合をやってみる。
アイコンハンドル取ってくる関数でやたら落ちたりメニュー表示文字列がゴミつきだったりと散々なことに。
アイコンハンドル取得してるところは失敗したときに例外投げるようにしていてまだぜんぜんcatch書いてなかったので落ちても構わなかったんですが文字列にゴミが付くのはいただけない。
2-3時間ひたすら目で追ったりstd.stdio.writeしたり-covしたり。
でもね、writeで書き出される文字列はText構造体を表示させてたので当然引っかからない。
もう最後の望みを掛けてText構造体にメス入れ。
ゆっくり見直して text ~ null に違和感を。

あれ？　この null ってホントに 0 なのか？
空配列っぽくね？

struct Text {
    wchar[] text;

    wchar* ptr() {
        return (text ~ cast(wchar)0).ptr;
    }
}

ああ、修正したら直ったさ。
アイコンハンドル取得するところもアイコンアドレスにゴミ混じってたから落ちてただけさ。

＠GC
もはや何も語るまい。