どの言い分もわかる。結局問題なのは、
なのだが。自転車や自動車を一括りにしたって何も始まらない。なくそうと思えば両方を取り締まればいい。
取り締まればいいんだけど……
また、ドライバーに関しては取り締まる理由がないから*自転車が圧倒的に不利。無法な自転車乗りを取り締まると同時に自転車の車道での立場を固めてもらわないと困る。原付に乗ってても 250ccに乗ってても勘違いしたドライバーにでくわす確率はそうとう高かったのに、自転車の立場なんて確保できるとは思わないが。
タレコミに「危険だと判断した場合は自転車も歩道を走ることができる。」というような文言が見あたらなかったので上のような文章を書いた。現状の追認には特に反対しない。自転車乗りとドライバーの積極的な教育を大いに望む。
交通の方法に関する教則( http://www.npa.go.jp/koutsuu/kikaku90/shinkyuu.pdf )から省略・抜粋。
道路を横断しようとするとき、近くに自転車横断帯があれば、その自転車横断帯を通行しなければなりません。
左折レーンのあるような交差点なので自転車横断帯はあるし(多分)、規定されてなくても実際そうせざるをえないんだけど、自転車横断帯を横断した後が問題。歩道と車道をうろうろするのは危険でしょ。自転車横断帯への誘導は歩道への誘導と同じこと。
「歩行者・自転車専用」と表示されている歩行者用信号機がある場合は、歩行者用信号機の信号に従わなければなりません。
見ない。歩行者用の信号の横に付いてるプレートなんて見ない。歩行者用の信号って先読みのためにあるんでしょ?<違
確かめてみたら自転車横断帯も歩行者・自転車専用のプレートもなかった。これでふりだしへ戻った。
どちらも選べなくて困っている。
* ケータイ片手のドライバーなんて見つけるのに苦労しないが、理由のあるドライバーに対してこんな状態で何をかいわんや。二車線あるのに追い越しをしようともせずクラクションを鳴らされまくったのがつい先日。後ろの様子なんてわからないから轢かれるんじゃないかと戦々恐々で、けっきょく排水溝のふた(段差)や砂利があってすぐパンクするようなところを走らされた。こういうの、どうにもできないでしょ。
最終更新: 2010-07-05T02:44+0900
既存のコード(主に検索ボックス)の切り貼りで、とりあえず機能するものに。
ソース面の難はニンともしがたいが機能面の問題くらいは何とかしたいところ。以下、わかっている問題点。
switch-caseで break忘れというまぬけぶりが原因だった。
フォント(HFONT)の削除漏れも修正した。
ツールチップはリストの上下数ピクセルで出ていた。(役に立たない!でもマウスオーバーでツールチップが出てもうるさいだけなのでそのまま)
他に、WM_PAINTで行っていた処理を、本来あるべき位置である WM_COMMAND(CBN_SELCHANGE)で行うように変更した。
キーボードアクセラレータを有効にするのは難しい。矢印や PageUp/PageDownキーまでが登録されているから、単純に有効にするとアクセラレータにそれらの入力を奪われてリストの操作が行えなくなる。
ドロップダウンリストにフォーカスがあるときでもエディタのキーボードショートカットを有効にした。優先順位は
なぜ一部のキーボードショートカットを無効にするかというと、リストの先頭のアイテムが選択されているときに Homeを押してもリストはこの入力を処理しない(すでに先頭が選択されているから)のだが、リストの選択位置に依存してキーの意味が変わってしまう(リストの先頭を選択↔キャレットを行頭に移動)のは不自然だと思うから。同様のキーをわかっている分だけ無効にした結果が上記リストの 2。モディファイアキーの状態やリストの選択位置を考慮して、もっと多くのキー入力をキーボードショートカットとして渡す余地はある(が、こんなアドホックな対処にこれ以上の手間をかけるのもどうかと)。
追従しないことにむしろ驚いた。ブラウザにできてテキストエディタにできないはずがない。
ファイル名も与えられていた場合は、それを上書き保存先にしてくれると尚良し。長めの出力をコマンドプロントからエディタに流して読んだりできる。
svn diff hoge.rb | sakura --stdin "hoge.rb.diff"
Set/GetWindowLongPtr(hwnd, GWLP_USERDATA, ) の代わりに Set/Get/RemoveProp(hwnd, TEXT("MyData"), ) を使うようにした。
参考> http://hilbert.elcom.nitech.ac.jp/~taki/program.html
以下のものを見つけた。
答え。GWLP_USERDATAはウィンドウに属し、その領域は WNDCLASSEX.cbWndExtraの値に従って確保される。
いったいどこを読み書きしていたんだろう? クラッシュしなかったのは Windowsが俺みたいなうっかりもののために余白を空けていたから?
言い訳。msdnのこの記述は非常に誤解を招きやすいと思う。予め 32ビットだけメモリが確保されてると勘違いしても仕方ないじゃない?
GWLP_USERDATA | ウィンドウに関連付けられた 32 ビット値を取得します。この 32 ビット値は、ウィンドウを作成したアプリケーションで使用する目的で各ウィンドウが持っているものです。この値の初期値は 0 です。
現状の理解で、この「32 ビット値」の出所は、読み書き(Get/Set)の単位が 4バイトだというところから。LONG=32ビットだから。
ここで、LONG_PTRが 64ビットのとき、GetWindowLongPtr(,GWLP_USERDATA)は 64ビット値を取得するのでは?ドキュメントあってる?という新たな疑問。
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)
// まだファイルタイプは取得できないっぽい。常に基本(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を取り除いた)だけ。
アプリケーションの起動と同時にツールバーが作成されるときであれば、コメントの内容は正しい。アプリケーションが起動してファイルが読み込まれた後でツールバーが表示する設定に変更されたとき(このときもツールバーが作成される)は、そうではなかった。
使用者の予測できない小賢しいことはしなくてよい。
ところでこれってデスクトップにオーバーラップ表示された複数のウィンドウに対するインターフェイスと同じだろう。
ウィンドウとタブは違う。タブコントロールは既に存在している。まねをしろ。見た目をまねしたなら反応まで。ドキュメントの上に常に表示されているタブリストは飾りじゃないんだよ。オーバーラップ表示されたウィンドウの切り替えには Z-Orderという手がかりがあるが、それに対する操作だけをまねしたタブウィンドウには何がある? ユーザーの目の前のタブリストでなく、プログラムが覚えてるだけの、過去にアクティブになった順番だ。それでは先読みができないだろう。毎回選択肢から探さなければならないのなら、いっそ名前順でソートされてる方がましってもんだ。
ところでところで、Operaの Ctrl+Tabも VC++2008EEと同じだったんだな。小さいウィンドウで選択肢を表示してワンクッション挟むところまで Windowsの Alt+Tab、VC++2008EEの Ctrl+Tabと同じ。まことにまどろっこしい。
Operaは Ctrl(+Shift)+F6、1(2)という、隣のタブに移動する代替手段を用意しているが、VC++2008EEには見つけられなかった。Safariは Firefoxと同じ操作感で良いけど、やっぱり Firefox + Tabs Open Relativeが理想的。
つまりは VC++2008EEのタブ*だけがイレギュラーで、使えない子。ほんとうんざり。
* 本当は、VC++2008EEにとってタブと呼ばれるものは別にあり、ここでタブといっている一個一個のものはドキュメントウィンドウと呼ばれている。これも紛らわしくて迷惑な話。本物のタブって見たことないんだけどー。
最終更新: 2009-08-30T23:50+0900
別に隠してないみたいだけど。
ftp://ftp.logitech.com/pub/techsupport/mouse/
ボタンが押されたことの通知を受け取ったり、LEDを制御したり、(持ってないけど) MX Airに関連した機能が用意されている。
もっとも、MX610HIDが既にあるので、メールの受信時にこれを叩けば LEDは点灯する。特に使い途はない。
例えば、Mailbox Alertというアドオンを入れて
[チェック] Execute a command: C:\path\to\MX610hid\mx610hid.exe mx mpg t60000 mx
というふうに設定すればメール着信後一分間ホタルのように光る。
なんだかんだで SONYが好きなのだろうか*。今、これだけが目に入る。
PlayStationは代替がないが、それ以外は比較検討した結果だ。もちろん VGF-WA1も。
VGF-WA1の決め手は安さ(¥17000)と、二度のファームウェアアップデートで、指摘された弱点(その1、その2)をきっちり潰しているところ。(もちろんハードウェアはどうにもできないが)
* SONYのデザイン偏重のカタログは 明確に 好きではない。要はターゲットの違いなんだろうが(つまり俺は SONYのターゲットではないということだが) TOSHIBAのマニアックでオタ心をくすぐるカタログが好ましい。
箱を開けたりしているうちはウキウキだった。さすが日本のメーカーだなー、とか。梱包とモノはすごくいい。でもいろいろつまずいた。
VGF-WA1がサポートしているのは IEEE802.11b/gの
説明書を見たら WPA-PSK AESは確かに抜けている。うちのアクセスポイントが古いのは認めよう。でもクライアントにはどんなアクセスポイントにも接続できるように幅広い対応を求めたい。仕方がないのでアクセスポイントを TKIPにした。
最新のファームが購入の決め手だったのに……。
デバイスドライバのインストールに失敗したというメッセージが出て失敗する。(VGF-WA1の液晶が updating firmware...と表示したままになるが、電源を切っても再起不能になったりはせず問題なかった)
説明書に Vista対応とは書かれているが、SP1なのがいけないのか、64-bit版なのがいけないのか。(ちなみに Vista対応を謳うのならそれは当然 32/64-bit両対応を意味するものと了解しているので、64-bitがいけないとは思っていない。原因である可能性は極めて高いと思っているが)
XP SP2を使ってファームウェアのアップデートだけはできたが、インストーラがファームウェアアップデートという、最初のプロセスでこけるので Vista機にワイヤレススピーカーマネージャをインストールできなかった。だもんで、VGF-WA1を PCのリモートスピーカーとして使用することができない。インストーラから個別のインストーラを展開できれば他のモノのインストールは成功する可能性もあるのに。
DLNAサーバーには Windows Media Player 11を使うことにした。
コントロールパネル > ネットワークと共有センター > メディア共有 > 変更...
で設定画面が開くがデバイスリストに VGF-WA1が現れない。パケットが届いていない可能性もあるかと思って、別の DLNAクライアント(I-O DATA AVel LinkPlayer2)を起動したらこれはリストに追加された。VGF-WA1は現れない。当然、VGF-WA1の方にもサーバーが現れない。
とりあえず Webラジオ*を聞きながら日記を書きつつ途方に暮れている。
追記: DELLの XP SP2パソコンでは問題なく共有できる。
追記: VAIO Media Integrated Serverなら Vista機でも共有できる⁑。でも余計なものはインストールしたくない。
追記@2009-03-23: LinkStation Mini(LS-WS1.0TGL/R1)を DLNAサーバーにした。 日本語の表示も問題なし。DLNAクライアントとしても使えるようになりネットラジオ専用機状態から脱却。
AVLP2/G-2の件が謎だが、どうもこのパソコンに問題があるらしい。Vistaなので Windows Media Connect 2.0をインストールしたり、WMP11を再インストールしたりできないのがつらい。WMP12をインストール(いつの話だ)したときに共有できるようになったらいいなあ。
AVLP2/G-2は OKと書いたが安定していない。起動してもなかなかデバイスリストに追加されない。
TVersityと VGF-WA1を起動した状態で、ルーターを再起動したりなんかしていて、ふと WA1の画面を見たら TVersityが現れていた。謎。WMP11ではやはり共有できない。
TVersityは Shift_JISな mp3タグが化けるので使いにくい。それ以外は設定項目が多くて良い。何よりサーバーとして役目を果たしている! でもアルファベットを問答無用でキャピタライズするのはやめて。
1.0.0.0 RC1を、UACオンの Vistaに XP SP2互換モードでインストールして、SSDP Discoveryサービスも動かしたままだけど問題ない。ただ、ハイバネーションから復帰したあとつながらなくて、TVersityのサービスを再起動する必要があったりする。文字コードも iTunesと同じ Unicodeにしたら化けないし、もはや何のソフトが原因で Shift_JISにこだわっていたのかも思い出せないのでタグは、Unicodeに一括変換してしまう。
これで VGF-WA1を使い倒す環境が整った、わけではなくて、WMA Losslessをこのように
PC --(IEEE802.11g)--> AP --(IEEE802.11g)--> WA1
無線で送り出して無線で受け取ろうとすると再生が途切れ途切れになる。WMAファイルのプロパティを見たら 1Mbps弱だったから、理論上限値 54Mbpsの IEEE802.11gにはがんばって欲しい。
(余談) WMP11の共有もずっとオンにしているが WA1から見えたことはない。