検索ボックス
昨日のWindows UpdateでIE11に検索ボックスが帰ってきた。
なつかしい。なくなったのはいつだったっか。
でもなんで、月例アップデートで追加?IEにはもう積極的に機能追加はしないんじゃなかったの?
うーん、不思議。
パターンマッチ
入るらしい。範囲も欲しい!
http://www.infoq.com/news/2014/08/Pattern-Matching
Microsoft Natural Ergonomic Keyboard 4000 のズームをスクロールにする方法(再び)
2006年に書いた記事のアップデートです。最近、また表題のでかいキーボードに戻ってきました。
不満は前と変わらず、でかい!のと、ズームをスクロールにしたい点です。
でかいのはどうにもなりませんが、ズームをスクロールにすることはできます。
C:\Program Files\Microsoft Mouse and Keyboard Center にある commands.xml ファイルの中身を書き換えます。itype などのバージョンによってフォルダの場所が違ったりしますが、見つけてください。書き換える前に、元のファイルはどこかにバックアップを取っておいてください。
C319 と C320 ではじまる要素をズームからスクロールに書き換えます。
↓
必要なアプリの要素と
Firefox は
(追記) commands.xml を書き換えたら、タスクマネージャーから itype.exe を終了させます。そして itype.exe をふたたび実行すると書き換えた内容が有効になります。
では、よいキーボード・ライフを!
遅延付き pure CSS ドロップダウンメニューの作り方
How To Create a Delayed Pure CSS Dropdown Menu
CSSはやりたいことと表現が乖離していてひどい言語ですね。いつかグーグルかアドビあたりが簡単できれいな新スタイルシート言語を出して広まってくれればいいと願ってます。
さて、表題のとおり、最近ではJavascriptなしでCSSだけでドロップダウンメニューを作れます。利用しているサイトもちらほらとあります。
ですが、ドロップダウンメニューが開くまでの遅延時間を設けていないサイトがほとんどで、とってもウザいことになっています。マウスが通過するだけでぺろっとゴミが…おっと失礼、メニューが開いて記事本文の上にかかって邪魔したりします。
どうせ誰も使わないメニューなんかないほうがいいのですが、ちゃんと先端行ってますよアピールのためにはゴミメニューを表示しないといけない事情もありそうなので、今日はCSSだけで遅延付きドロップダウンメニューの作り方を説明します。
まずは、遅延なしの場合ですが、↓ここを見てください。すばらしい!
http://line25.com/tutorials/how-to-create-a-pure-css-dropdown-menu
では、これを遅延ありに改造します。CSS3 transitions を利用します。nav ul ul と nav ul li:hover > ul を置き換え、nav ul li > ul を追加します。
nav ul ul { display: block; visibility: hidden; transition-property: visibility; -webkit-transition-property: visibility; } nav ul li > ul { transition-delay: 0s; -webkit-transition-delay: 0s; visibility: hidden; } nav ul li:hover > ul { transition-delay: 300ms; -webkit-transition-delay: 300ms; visibility: visible; }
できあがり!マウスが上に乗ってから 300ms 後にメニューが表示されます。消えるときは遅延はありません。display はアニメ効果がつけられないので、効果をつけられる visibility を利用しました。
まあ、説明しておいてなんですが、メニューにごてごてと詰め込みすぎても誰も使わないですよ。シンプルであることのほうが重要だと思います。
C# 5 での互換性のない変更
C#5 では、ループ変数とラムダ式の嫌な問題を一つ直すようです。
var values = new List<int>() { 0, 1, 2 }; var funcs = new List<Func<int>>(); foreach ( var v in values ) funcs.Add( () => v ); foreach ( var f in funcs ) Console.WriteLine( f() );
このコードを実行すると C#4 までは予想に反して「2 2 2」ですが、C#5 からは「0 1 2」となります。Windows 8 CP 上の Visual Studio 11 で試した結果です。C# の「破壊的」仕様変更であり、後方互換性がなくなります。
これまでも、この問題には簡単な回避策があり、ループ中で v をいったん var v2 = v; と別の変数に入れてラムダ式から v2 を参照すれば、まともに動きます。しかし、これまでの動作は誰も得しないので仕様を変更してまで修正するようです。
foreach はコンパイラによって while を使ったコードに展開されますが、このときループの外で変数を定義していたのを、ループの中で定義することで修正します。Eric Lippert さんの blog から引用します。
{ IEnumerator<int> e = ((IEnumerable<int>)values).GetEnumerator(); try { int m; // OUTSIDE THE ACTUAL LOOP while(e.MoveNext()) { m = (int)(int)e.Current; funcs.Add(()=>m); } } finally { if (e != null) ((IDisposable)e).Dispose(); } }
この int m; を while の中へ。
try { while(e.MoveNext()) { int m; // INSIDE m = (int)(int)e.Current; funcs.Add(()=>m); }
従来は一つだけの変数の寿命が伸びていたので最後の値が見えていました。これからは、ループのたびに変数が作られ、それぞれの寿命が伸びることで解決します。
しかし! for は変更なしです。
var funcs2 = new List<Func<int>>(); for ( int i = 0; i < 3; i++ ) funcs2.Add( () => i ); foreach ( var f in funcs2 ) Console.WriteLine( f() );
この結果は「3 3 3」で変わりません(「2 2 2」でもありませんw)。
Eric Lippert さんが挙げる foreach の変更の悪い点。
- 互換性がなくなる破壊的変更であること。
- foreach の構文に矛盾しているように見えること。foreach ( int x in M() ) の右側にある M() より、左にある int x が内側にあるような感じ。左から右という一般的な規則に反する。
- foreach と for で一貫性がなくなる。
- 簡単な回避策があるのに破壊的変更は必要?
それでも変更するようです。
参考、および引用元:
- http://stackoverflow.com/questions/8898925/is-there-a-reason-for-cs-reuse-of-the-variable-in-a-foreach
- Eric Lippert さんの blog
おまけ。Eric さんの blog の最後の方にある pros or cons (pros and cons) とは、アメリカの子供が学校で習う考える訓練方法で、紙の真ん中に線をひき、左と右に良い点悪い点を書き出して考える方法だそうです。真ん中辺りの画像が参考になります。