脳log[2008-06-06～]

最終更新: 2010-07-05T02:44+0900

♪ [SakuraEditor] 現在適用されているファイルタイプを表示/変更するツールバーボタン

既存のコード(主に検索ボックス)の切り貼りで、とりあえず機能するものに。

ソース面の難はニンともしがたいが機能面の問題くらいは何とかしたいところ。以下、わかっている問題点。

• 検索ボックスより右に表示できない。(済み)
• リストにフォーカスがある状態では(検索ボックスと同様に)共通設定で割り当てたキーボードショートカットが効かない。(済み)
• マウスオーバーでツールチップが出ない。(対応しない)
• 頭文字を利用した選択。(Jを押すと Jで始まるアイテムを順番に選択する機能)(済み)
• ツールバーを非表示から表示にしたとき、現在のタイプ別設定を反映していない(2010-06-29追記&修正済み)。

 追記@2008-06-05: 「検索ボックスより右に表示できない。」を修正した。

switch-caseで break忘れというまぬけぶりが原因だった。

フォント(HFONT)の削除漏れも修正した。

ツールチップはリストの上下数ピクセルで出ていた。(役に立たない！でもマウスオーバーでツールチップが出てもうるさいだけなのでそのまま)

 追記@2008-06-05: リストのキーボード操作「頭文字を利用した選択」を有効に。

他に、WM_PAINTで行っていた処理を、本来あるべき位置である WM_COMMAND(CBN_SELCHANGE)で行うように変更した。

キーボードアクセラレータを有効にするのは難しい。矢印や PageUp/PageDownキーまでが登録されているから、単純に有効にするとアクセラレータにそれらの入力を奪われてリストの操作が行えなくなる。

 追記@2008-06-14: キー割り当てを有効に。

ドロップダウンリストにフォーカスがあるときでもエディタのキーボードショートカットを有効にした。優先順位は

1. リストの操作(↑, ↓, ←, →, PageDown, PageUp, Home, End, F4, Alt+↓で全部かな？)
2. キーボードショートカット (↑, ↓, ←, →, PageDown, PageUp, Home, End, F4を使わないものと、Tab、Shift+Tab以外のもの)
3. 頭文字を利用したリストアイテムの選択

なぜ一部のキーボードショートカットを無効にするかというと、リストの先頭のアイテムが選択されているときに Homeを押してもリストはこの入力を処理しない(すでに先頭が選択されているから)のだが、リストの選択位置に依存してキーの意味が変わってしまう(リストの先頭を選択↔キャレットを行頭に移動)のは不自然だと思うから。同様のキーをわかっている分だけ無効にした結果が上記リストの 2。モディファイアキーの状態やリストの選択位置を考慮して、もっと多くのキー入力をキーボードショートカットとして渡す余地はある(が、こんなアドホックな対処にこれ以上の手間をかけるのもどうかと)。

 SakuraEditorに欲しい機能

 ウィンドウのリサイズに追従する「現在のウィンドウ幅で折り返し」

追従しないことにむしろ驚いた。ブラウザにできてテキストエディタにできないはずがない。

 標準入力から編集テキストを読む機能

ファイル名も与えられていた場合は、それを上書き保存先にしてくれると尚良し。長めの出力をコマンドプロントからエディタに流して読んだりできる。

 svn diff hoge.rb | sakura --stdin "hoge.rb.diff"

 追記@2009-07-19: アップデート > SakuraEditor(Toolbar-FileTypeBox)_rev2.diff

Set/GetWindowLongPtr(hwnd, GWLP_USERDATA, ) の代わりに Set/Get/RemoveProp(hwnd, TEXT("MyData"), ) を使うようにした。

参考> http://hilbert.elcom.nitech.ac.jp/~taki/program.html

 1. そもそもあった疑問: GWLP_USERDATAはウィンドウクラスに属するのかウィンドウに属するのか？

以下のものを見つけた。

• Set/GetClassLongPtr()
• WNDCLASSEX.cbClsExtra
• WNDCLASSEX.cbWndExtra

答え。GWLP_USERDATAはウィンドウに属し、その領域は WNDCLASSEX.cbWndExtraの値に従って確保される。

 2. ぎゃっ！ WNDCLASSEX.cbWndExtraなんて変更してなかった。

いったいどこを読み書きしていたんだろう？ クラッシュしなかったのは Windowsが俺みたいなうっかりもののために余白を空けていたから？

言い訳。msdnのこの記述は非常に誤解を招きやすいと思う。予め 32ビットだけメモリが確保されてると勘違いしても仕方ないじゃない？

GWLP_USERDATA | ウィンドウに関連付けられた 32 ビット値を取得します。この 32 ビット値は、ウィンドウを作成したアプリケーションで使用する目的で各ウィンドウが持っているものです。この値の初期値は 0 です。

現状の理解で、この「32 ビット値」の出所は、読み書き(Get/Set)の単位が 4バイトだというところから。LONG=32ビットだから。

ここで、LONG_PTRが 64ビットのとき、GetWindowLongPtr(,GWLP_USERDATA)は 64ビット値を取得するのでは？ドキュメントあってる？という新たな疑問。

 3. いずれにしろ

GWLP_USERDATAのように汎用的な場所から取得した値を恐る恐る CMainToolbar* にキャストするより、特別な名前をつけた場所に保存した値をキャストする方がまだ安心できる、という理由で改訂した。

ありふれた課題のようで GWLP_USERDATA を検索するだけで似たような話が見つかる。最初にリンクを張ったページは理解しやすかったが ATLのは難しい。これから読む > WTL/ATLのメッセージマップ実現のしくみ

GWLP_USERDATAと WNDCLASSEX.cbWndExtraが別物の可能性。

別物。GWLP_USERDATAは負のオフセット(-21)。cbWndExtraで確保した領域には 0から始まるオフセット(バイト単位)でアクセスする。

GWLP_USERDATAの有効な領域はポインタのサイズに関係なく、ドキュメント通りの 32ビットなのかについては winuser.hを見てもよくわからない。GWLP?_USERDATA(-21)から GWL_EXSTYLE(-20)まで差が 1しかないし……。GWLP?_* というのはオフセットでなく特別扱いされる値で、Windowsのソースを見ないと何もわからない、ということ？ GWLP_USERDATAにポインタを格納できるのとできないのの差は大きいからハッキリ 64ビットサイズだと知りたい。

/*
 * Window field offsets for GetWindowLong()
 */
#define GWL_WNDPROC         (-4)
#define GWL_HINSTANCE       (-6)
#define GWL_HWNDPARENT      (-8)
#define GWL_STYLE           (-16)
#define GWL_EXSTYLE         (-20)
#define GWL_USERDATA        (-21)
#define GWL_ID              (-12)

#ifdef _WIN64

#undef GWL_WNDPROC
#undef GWL_HINSTANCE
#undef GWL_HWNDPARENT
#undef GWL_USERDATA

#endif /* _WIN64 */

#define GWLP_WNDPROC        (-4)
#define GWLP_HINSTANCE      (-6)
#define GWLP_HWNDPARENT     (-8)
#define GWLP_USERDATA       (-21)
#define GWLP_ID             (-12)

 追記@2010-06-29: ツールバーを非表示から表示にしたとき、現在のタイプ別設定を反映していないのを修正

// まだファイルタイプは取得できないっぽい。常に基本(0)になる。
//::SendMessageAny( m_hwndFileTypeBox, CB_SETCURSEL, m_pOwner->GetDocument().m_cDocType.GetDocumentType().GetIndex()+1, 0 );
::SendMessageAny( m_hwndFileTypeBox, CB_SETCURSEL, 0, 0 );

とコメントアウトしていた部分を復活させて

::SendMessageAny( m_hwndFileTypeBox, CB_SETCURSEL, m_pOwner->GetDocument().m_cDocType.GetDocumentType().GetIndex(), 0 );

ちょっと修正した(謎の+1を取り除いた)だけ。

アプリケーションの起動と同時にツールバーが作成されるときであれば、コメントの内容は正しい。アプリケーションが起動してファイルが読み込まれた後でツールバーが表示する設定に変更されたとき(このときもツールバーが作成される)は、そうではなかった。

♪ [BAD BOY] スラッシュドット・ジャパン｜道交法の改正をどう思います？

どの言い分もわかる。結局問題なのは、

• ルールを守らない自転車乗りと
• 車道を自動車四輪自動車のものだと勘違いしたドライバー

なのだが。自転車や自動車を一括りにしたって何も始まらない。なくそうと思えば両方を取り締まればいい。

取り締まればいいんだけど……

• 左折レーンのある交差点で自転車はどう動くべき？
• 雨の日は歩道をてれてれ走りたい

また、ドライバーに関しては取り締まる理由がないから*自転車が圧倒的に不利。無法な自転車乗りを取り締まると同時に自転車の車道での立場を固めてもらわないと困る。原付に乗ってても 250ccに乗ってても勘違いしたドライバーにでくわす確率はそうとう高かったのに、自転車の立場なんて確保できるとは思わないが。

 追記

タレコミに「危険だと判断した場合は自転車も歩道を走ることができる。」というような文言が見あたらなかったので上のような文章を書いた。現状の追認には特に反対しない。自転車乗りとドライバーの積極的な教育を大いに望む。

 追記: 自己解答>左折レーンのある交差点で自転車はどう動くべき？

交通の方法に関する教則( http://www.npa.go.jp/koutsuu/kikaku90/shinkyuu.pdf )から省略・抜粋。

道路を横断しようとするとき、近くに自転車横断帯があれば、その自転車横断帯を通行しなければなりません。

左折レーンのあるような交差点なので自転車横断帯はあるし(多分)、規定されてなくても実際そうせざるをえないんだけど、自転車横断帯を横断した後が問題。歩道と車道をうろうろするのは危険でしょ。自転車横断帯への誘導は歩道への誘導と同じこと。

「歩行者・自転車専用」と表示されている歩行者用信号機がある場合は、歩行者用信号機の信号に従わなければなりません。

見ない。歩行者用の信号の横に付いてるプレートなんて見ない。歩行者用の信号って先読みのためにあるんでしょ？<違

 追追記：左折レーンがあるが自転車横断帯はなかった

確かめてみたら自転車横断帯も歩行者・自転車専用のプレートもなかった。これでふりだしへ戻った。

• 道の真ん中で車と一緒に信号待ち。
• 自転車を押して横断歩道を渡る。

どちらも選べなくて困っている。

♪ 追記@2008-06-13: >http://homepage1.nifty.com/emk/symlink.html

この場合はshortcutは完全にsymbolic linkとして機能しているように見える。なぜすべての場所ではなくスタートメニューの中だけでこうなってるんだ？ Windows shortcutは一体どういう仕様になってるんだ？さっぱりわからん。

そこでlsしてたらもう少しだけ謎が解けていたと思います。

以前にも読んでいたのだがいいタイミングでページを再発見したので引用してみた。

どうして「わからん」になるのかを横から説明すれば

• dirの出力が ""(ファイル)でも <JUNCTION>でもなく <DIR>のくせに、
• エクスプローラでは種類が「ファイル フォルダ」ではない「ファイル」という他では見かけないものになっている。
• アドレスはスタートメニューの中にいることを示しているが、表示される内容がターゲットの内容。(ジャンクションっぽい動作)

書かれている通り、<DIR>であり「ファイル」であるディレクトリに入って ls(dir)してみた結果がこう。嘘つきが誰なのかわかれば何の不思議もない。

2008/05/30  00:09    <DIR>          .
2008/05/30  00:09    <DIR>          ..
2008/05/30  00:09               757 target.lnk

隠し属性つきで desktop.iniも存在している。内容は

[.ShellClassInfo]
CLSID2={0AFACED1-E828-11D1-9187-B532F1E9575D}
Flags=2

気付くためのポイントはスタートメニューの中でだけ有効だということ。dirとエクスプローラのどちらを信用するのかをちょっと考えれば、ディレクトリの他に(仮想)フォルダ(ごみ箱やマイコンピュータやデスクトップなど)を表示するエクスプローラ (もうひとつリンク)が時に嘘つきなのは以前から知っていたはず。

♪ [SHJS] 続・shjs-0.4.2: 重箱の隅、つっつきます

$ で GREPしてみたらこういうものが無数に見つかった。だいたいが一行コメントの中に対応した state。終了条件は行末で、URLを含んでいれば sh_urlとしてマークする。

    {
      'exit': true,
      'regex': /$/g
    },
    {
      'regex': /(?:<?)[A-Za-z0-9_\.\/\-_]+@[A-Za-z0-9_\.\/\-_]+(?:>?)/g,
      'style': 'sh_url'
    },

URLが改行の直前まで続いていれば、終了条件としての行末の検出がスキップされて一行コメントが次の行まで継続する。まさしく 20080513p01の問題の繰り返し。

結局、sh_main.jsに非互換な変更を加えるのは問題大ありだと判明したので sh_javascript.jsで対応することにしましたよ、と。

  [ // state 2: in "string"
    {
      regex: /\\[\\"]/g
    },
    {
      next: 6,
      regex: /\\$/gm
    },
    {
      exit: true,
      regex: /"|$/gm
    }
  ],

  [ // state 6: eat an end-of-line ※空行は食べられないよ
    {
      exit: true,
      regex: /^/gm
    }
  ]

動作確認は昨日の日記で。

♪ [SHJS] shjs-0.4.2: 重箱の隅、つっつきます

例えば、JavaScriptのリテラル文字列では \ と改行のシークェンスは空文字を意味している。つまりこういうこと

var str = "空白を含まない\
ひとつながりの文字列です";

このシークェンスを認めるように、ダブルクォーテーション文字列の終了条件として次のようなものを shjs/lang/sh_javascript.js に含めてみたがうまくいかなかった。

  [ // "string"
    {
      // \\ と \" と \(改行) を 1つのシークェンスとして
      // 食べてしまう。終了位置を見誤らないためであって、
      // 特に何をするということもない。/\\(.|$)/gm でも構わない。
      regex: /\\(?:[\\"]|$)/gm
    },
    {
      // エスケープされていない " に出会ったら "～" の中に
      // いるという状態(state)から exitする。
      // " がないまま行末に達したら、終端されていない不正な
      // 文字列だと判断して、やはり exitする。
      exit: true,
      regex: /"|$/gm
    }
  ],

少し前に「行末に達した時点でマッチングを打ち切っていたのが間違い。$は空文字列にもマッチする。全てのマッチに失敗するまで続ける必要があった(20080513p01)」と自分のミスを書いて、これを修正したのだが、shjs-0.4.2はもちろん正しく、全てのマッチが失敗するまで続けている。

そうすると何が起こるか。/\\$/gm にマッチした後でも /"|$/gm のマッチに成功してしまい、結果、行末に \ があろうがなかろうが exitしてしまう。

もちろん行末に達したからといってすぐにマッチングを打ち切っては 20080513p01と同じ間違いを犯すことになるので、同一 state内で*二回以上*行末にマッチすることがないように sh_main.jsを変更した。

内の方のループの、頻繁に実行される部分に if が増えたのが気に入らないものの、悪影響のある非互換でもないし、首尾は上々だし(冒頭の文字列のハイライト結果が見本)、悪くない。

var str = "終端されていない
不正な文字列です";

 追記@2008-05-30: この場合はどうする？

var str = "終端されていない\"
不正な文字列です";

*たまたま*行末にある \" にマッチしたことで、終了条件である行末の検出がスキップされて、次の行までが文字列だと判断されている*。\" とのマッチは \$ と違い行末を要求していないから、この場合は一行目で exitしてほしい。

♪ [正規表現] 今日やられた正規表現

/^(?=\W)/
/^(?!\w)/

二つの違いは？ (ヒント：空文字列/空行)

/^(?=\W)/  //=> 単語に使われる以外の文字から始まる行の頭にマッチ
/^(?!\w)/  //=> 単語に使われる文字から始まらない行の頭にマッチ
           //   (最初のパターンと違い、一文字もない場合(空行)にもマッチする)

♪ [Firefox][javascript][SHJS] <pre>が真っ白になり、黒色の領域が出現する。

例えばこのページ http://vvvvvv.sakura.ne.jp/ds14050/diary/20080112-7.html 。Endキーで末尾に移動して PageUpで戻っていくと空白の PREが目に入ると思う。その少し上にはページの内容を覆い隠す黒い領域があるはず。(そうでなければ修正されたのだろう。Firefox2で最初に確認し、Firefox3.0RC1でも直っていなかったが)

大量の PREが存在したり、一つだけでも巨大な PREが存在する場合に起こる様子。innerHTMLで PREの内容を置き換えているのも原因になっているかもしれない。

画面の末端にスクロールした状態でページをリロード(F5 or Ctrl+R)すると下方の PREが正常に表示される反面、上端付近の PREに同じ問題が生じる。遠方の PREの書き換えに問題があるのでは？

真っ白の PREの中で、右クリックしたりテキストを選択したりといったアクションを起こせば正常に表示されることが多い。

あと、PREの中から開始した選択は PREの外に出られなかったり。(これは TEXTAREAと違い PREでは Ctrl+Aで全文選択ができないために用意された代替手段だという気もする)