/ 最近 .rdf 追記 設定 本棚

log[2008-06-10]



20080610() 既に数年来 2chフリーなネト生活検索で過去ログが引っかかっても大抵ブラウザでは読めないから使えないmamimiとかかちーしゃとか使ってた頃が最後kage.exeの動作の仕組みは今でも興味津々<つまりは理解できていない


20080609() Firefox3(現在は RC2)にしてから IMEをオフにし忘れることが多いと思ったらロケーションバーで Enterを押した瞬間にフーカスが(文字入力できない場所へ)移動するからだ


20080607() Ultimate Extrasのサウドスキーム(Glass, Pearl)を削除してしまったら C:\Windows\System32\SoundSchemes.exeを実行

Visual C++ 2008 Express Editionのオレオレ仕様が許せない

  • なぜ新しいタブを左端に開く!
  • なぜ Ctrl+Tab(Ctrl+F6)で単純に隣のタブに移動しない!
  • Ctrl+TabTab(Ctrl+F6F6)Ctrl+Tab,Ctrl+Tab(Ctrl+F6,Ctrl+F6)を区別するな!

使用者の予測できない小賢しいことはしなくてよい

ところでこれってデスップにオーバーラップ表示された複数のドウに対するインターフェイスと同じだろう

  • 新しいドウは最前面
  • Alt+TabTabTabドウ選択
  • Alt+Tab, Alt+Tabは二つのドウを行ったり来たり

ドウとタブは違うタブコトロールは既に存在しているまねをしろ見た目をまねしたなら反応までドキュメトの上に常に表示されているタブリトは飾りじゃないんだよーバーラップ表示されたドウの切り替えには Z-Orderという手がかりがあるがそれに対する操作だけをまねしたタブドウには何がある? ユーザーの目の前のタブリトでなくプログラムが覚えてるだけの過去にアクブになった順番だそれでは先読みができないだろう毎回選択肢から探さなければならないのならっそ名前順でソトされてる方がましってもんだ

ところでところでOperaCtrl+TabVC++2008EEと同じだったんだな小さいドウで選択肢を表示してワンクッション挟むところまで WindowsAlt+TabVC++2008EECtrl+Tabと同じまことにまどろっこしい

OperaCtrl(+Shift)+F61(2)という隣のタブに移動する代替手段を用意しているがVC++2008EEには見つけられなかったSafariFirefoxと同じ操作感で良いけどっぱり Firefox + Tabs Open Relativeが理想的

つまりは VC++2008EEのタブ*だけがイレギュラーで使えない子ほんとうんざり

* 本当はVC++2008EEにとってタブと呼ばれるものは別にありここでタブといっている一個一個のものドキュメドウと呼ばれているこれも紛らわしくて迷惑な話本物のタブって見たことないんだけど


20080606() --force-log: 「ログメッセージを含むファイルを強制的に有効にしますは使用経験からする「ファイル名を含むログメッセージを強制的に有効にします(-m, --message の後ろのパスっぽく見える引数はログメッセージで間違いありません)だと思った原文はどうなっている?


20080605() マンガは場所を取るからほとんどは配信でいい


20080604() 状態表示系のボタンが好きでも基本はツールバー非表示

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

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

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

スクリーンショット(一部)

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

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

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

switch-casebreak忘れというまぬけぶりが原因だった

(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を使わないものとTabShift+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す。

GetWindowLongPtr 関数

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

ここでLONG_PTR64トのときGetWindowLongPtr(,GWLP_USERDATA)64ト値を取得するのではドキュメトあってる?という新たな疑問

 3. いずれにしろ

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


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


GWLP_USERDATAWNDCLASSEX.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を取り除いた)

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


20080603() こういうのを自転車乗りの議論といいます。(微妙に違)

[BAD BOY] スラッシト・ャパン|道交法の改正をどう思います?

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

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

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

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

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

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

 追記

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

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

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

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

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

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

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

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

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

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

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

* ケータイ片手ドライバーなんて見つけるのに苦労しないが理由のあドライバーに対してこんな状態で何をかいわんや二車線あるのに追い越しをしようともせずクラクションを鳴らされまくったのがつい先日後ろの様子なんてわからないから轢かれるんじゃないかと戦々恐々でっきょく排水溝のふた(段差)や砂利があってすぐパンクするようなところを走らされたこういうのどうにもできないでし


20080602() jsmin.js (2006-08-31): inputの最後の文字を peek()したあとの get()最後の文字を返さないんじゃなかろう


20080531() [Vista] スタトメニーにフォルダのシトカトを置くと展開してくれるのだなあ<右ボタンドラッグしていってシトカトの作成を選んだのにトカトでもジャンクションでもない不思議なものができていた

追記@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とエクスプローラのどちらを信用するのかをちっと考えれば、トリの他に(仮想)ォルダ(ごみ箱やマイコンピータやデスップなど)を表示するエクスプローラ (もうひとつリンク)が時に嘘つきなのは以前から知っていたはず。


20080530() ViewVCURLをパラメータとして与えて外部の生Subversionリポトリに ViewVCの皮をかぶせたい

[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
    }
  ]

動作確認は昨日の日記


20080529() 内容と関係のない画一的な帯は間違いなくゴミ(コバト文庫のことです)帯の下を意識させるデザインのときの帯もゴミ役に立つ文字が書いていない帯もゴミ帯を外すと間抜けなカバーはダメダメ(最近は買った本の帯をカバーの下に隠すことが多い<でも捨てられな)

[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してほしい

* 20080530p01で修正したので文章とハイラト結果が食い違っているかもしれない


20080528() コンテトネゴシエイションによる表示言語の切り替えはうまくない内容が同じなら日本語で表示された方が読みやすいが英語の方が情報が新しいのが常Accept-Languageを切り替えるより URLを書き換える方が圧倒的に楽でしょう読み手に選択肢を! >>>>>>http://www.mozilla.com/firefox/

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

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

二つの違いは? (ト:空文字列/)


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

20080527() [Firefox] 領域を選択してのソース表示はスクリトに書き換えられた最新の HTMLを反映しているのが便利

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

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

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

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

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


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