<\/a><\/span>';
li += "<\/li>";
return li;
}
// デフォルトで表示されるリストを構築する
htmlstr += '
Visual Studio 2008 を Eclipseライクなフォント・配色にしてみる
2009-03-30 Mon 12:42 |
Visual Studio 2008 のフォントや配色がいまいち見にくい。
そう思うのは、おそらくJavaで利用していたEclipseの外観に見慣れていたからに違いないということで、Visual Studio のフォントと配色を変更して、Eclipseライクにしようというのが今回の目標です。
では、実際にどうやったかというと、
設定はすべて「ツール(T)>オプション...(O)」から呼び出したオブション画面中の「環境>フォントおよび色」で行います。
まず、フォントについてです。「フォントおよび色」の画面を表示した状態で、「フォント」を「Courier New」にします。これだけで、ものすごくEclipseっぽくなります。
配色は完全に同じにということは設定の種類による制限上不可能なのですが、その制限の中で見やすくしてみた結果を書いてみます。
以下、設定の上から順、C#向けです。(※カスタム(63,95,191)という表記は、色の選択でカスタムから色の作成を選んで、赤63,緑95,青191にするという意味です。)
以上です。
これで、あとは自分好みに変更してみてください。
そう思うのは、おそらくJavaで利用していたEclipseの外観に見慣れていたからに違いないということで、Visual Studio のフォントと配色を変更して、Eclipseライクにしようというのが今回の目標です。
では、実際にどうやったかというと、
設定はすべて「ツール(T)>オプション...(O)」から呼び出したオブション画面中の「環境>フォントおよび色」で行います。
まず、フォントについてです。「フォントおよび色」の画面を表示した状態で、「フォント」を「Courier New」にします。これだけで、ものすごくEclipseっぽくなります。
配色は完全に同じにということは設定の種類による制限上不可能なのですが、その制限の中で見やすくしてみた結果を書いてみます。
以下、設定の上から順、C#向けです。(※カスタム(63,95,191)という表記は、色の選択でカスタムから色の作成を選んで、赤63,緑95,青191にするという意味です。)
- XML ドキュメント コメント → 前景色：カスタム(63,95,191)
- XML ドキュメント タグ → 前景色：カスタム(127,159,191),太字
- キーワード → 前景色：カスタム(127,0,85),太字
- コメント → 前景色：カスタム(63,127,95)
- コンパイル エラー → 前景色：赤
- ユーザー キーワード → 前景色：自動
- ユーザー タイプ → 前景色：カスタム(0,0,192),太字
- ユーザー タイプ(インターフェース) → 前景色：自動
- ユーザー タイプ(デリゲート) → 前景色：自動
- ユーザー タイプ(値の型) → 前景色：自動
- ユーザー タイプ(列挙型) → 前景色：自動
- 文字列 → 前景色：カスタム(0,0,192)
- 文字列(C# @ Verbatim) → 前景色：カスタム(0,0,192)
以上です。
これで、あとは自分好みに変更してみてください。
.NET ジェネリクス版SortedList について 訂正
2009-03-28 Sat 02:29 |
前回のSortedListに関する記事で、System.Collections.IComparableの代わりにジェネリクス版ではSystem.Collections.Generic.IComparer<T>を利用すると書きましたが、System.Collections.IComparableの代わりは、System名前空間にSystem.IComparable<T>として存在しているみたいです。
つまり、MSDNによれば、
ふむふむ、って感じです。System.Collections.Generic.SortedList<TKey, TValue>よりもその名前を気にせずに、System.Collections.Generic.List<T>を利用して、List<T>.Sort()メソッドを利用した方がわかりやすく、柔軟な気がしました。
というか、Javaの方が使いやすく感じた記憶が強いのはなぜなんでしょうか・・・
つまり、MSDNによれば、
ということらしいです。基本的にSortedList<TKey, TValue>のTKeyに使うクラスは、System.IComparable<T>を実装しているべきであるそうです。そして、もし、その実装ができない(したいクラスのソースがない場合など)には、外部にSystem.ICompararer<T>を用意して、それを利用して比較させる(この文章は完全に私の解釈です)
ふむふむ、って感じです。System.Collections.Generic.SortedList<TKey, TValue>よりもその名前を気にせずに、System.Collections.Generic.List<T>を利用して、List<T>.Sort()メソッドを利用した方がわかりやすく、柔軟な気がしました。
というか、Javaの方が使いやすく感じた記憶が強いのはなぜなんでしょうか・・・
JRE 6 Update 13 リリース
2009-03-26 Thu 23:52 |
SortedListと、ジェネリックス版SortedListにはまる
2009-03-26 Thu 06:19 |
.NET Framework 2.0 でジェネリクスが導入されたのですが、Javaに比べるとほんのちょっととっつきにくい感じがしていました。で、今回は、SortedListの非ジェネリクス版とジェネリクス版とにおける、Keyの比較方法の実装方法(形式)の違いについてです。(いつも通りメモなので、不完全です…)。「配列にある 2 つの要素を比較できませんでした。」というエラーが出てしまったら、これが原因・・・かも。
非ジェネリクス版とは、System.Collections.SortedList(以下、SortedList)のことで、ジェネリクス版System.Collections.Generic.SortedList<TKey, TValue> (C#風の書き方の場合、以下、SortedList) です。
ここからは、.NET Framework の現在での最新版である.NET Framework 3.5 のMSDN ライブラリ を参考にしつつ、、現在 .NET Frameworkを利用するなら、ジェネリクス版(SortedList<TKey, TValue>)を利用した方がいいと言うことを前提にします。扱いやすいですし。
以下本題。
目的は、SortedList<TKey, TValue>に自作のクラスDataClassのインスタンスを格納しようということです。
SortedList<TKey, TValue>に、DataClassのインスタンスを入れようとするのですから、普通DataClassは順序づけができる(比較ができる)はず(Sortしたいから)なので、DataClassにIComparableインターフェースを実装して、IComparableインターフェースのCompareTo(object obj)が実装可能なはずです。
そして、SortedList<TKey, TValue>をここではSortedList<DataClass, DataClass>として、new SortedList<DataClass, DataClass>()で作ったインスタンスを作ります。
このdataListに追加したいオブジェクト(=data)をAddすればいいわけです。
これでいいんだと思ってました。しかし、これは非ジェネリクスのSortedListでの方法で、IComparableもSystem.Collectionsにあります。しかし、これでも、ちゃんと動いちゃうんです！互換かな？
じゃぁ、MSDN通りにするにはどうするかというと、IComparableにもジェネリクス版というか、ジェネリクス用にIComparer<T>があります。これを使えという訳です。
しかし、ほとんど同じだろうと思って使ってみると全然違うみたいです。
名前をよーく見ると、ICompar"er"なので、比較する道具、つまり、ものさしみたいなイメージですね。なので、実装するメソッドも、Compare(T x, T y)となっていて、2つのオブジェクトを外から比較するようになっています。
じゃぁ、どうするのかと言いますと。実際にIComparerを実装したクラス(正直、DataClassでもいいんですけど)のインスタンスを作成して、この"ものさし"オブジェクトをSortedList<TKey, TValue>に登録してあげます。そうすると、その"ものさし"のCompareメソッドを利用して比較してくれるというわけです。この登録は、必ずSortedList<TKey, TValue>のコンストラクタの引数として設定してください。
なぜ、コンストラクタが必要なのかというと、SortedList<TKey, TValue>.Comparerは、読み取り専用プロパティだからです。後から設定し直すことができないからです。
ふぅ、メモ完了。ポイントは、IComparerはIComparagleとは違って、"ものさし"なだけだから、ちゃんと"ものさし"専用オブジェクトを用意して、SortedList<TKey, TValue>のコンストラクタで指定しなければならないということです。似てるけど、違うんですね。
ちょっと宣伝。
Javaを始めたいという方は、このJavaの環境の作成の仕方ページを参考にしてみてください><
非ジェネリクス版とは、System.Collections.SortedList(以下、SortedList)のことで、ジェネリクス版System.Collections.Generic.SortedList<TKey, TValue> (C#風の書き方の場合、以下、SortedList
非ジェネリクス版：System.Collections.SortedList
ジェネリクス版：System.Collections.Generic.SortedList<Tkey, TValue>
ここからは、.NET Framework の現在での最新版である.NET Framework 3.5 のMSDN ライブラリ を参考にしつつ、、現在 .NET Frameworkを利用するなら、ジェネリクス版(SortedList<TKey, TValue>)を利用した方がいいと言うことを前提にします。扱いやすいですし。
以下本題。
目的は、SortedList<TKey, TValue>に自作のクラスDataClassのインスタンスを格納しようということです。
SortedList<TKey, TValue>に、DataClassのインスタンスを入れようとするのですから、普通DataClassは順序づけができる(比較ができる)はず(Sortしたいから)なので、DataClassにIComparableインターフェースを実装して、IComparableインターフェースのCompareTo(object obj)が実装可能なはずです。
そして、SortedList<TKey, TValue>をここではSortedList<DataClass, DataClass>として、new SortedList<DataClass, DataClass>()で作ったインスタンスを作ります。
// DataClass : IComparable
SortedList<DataClass, DataClass> dataList;
dataList = new SortedList<DataClass, DataClass>();
このdataListに追加したいオブジェクト(=data)をAddすればいいわけです。
// SortedList<TKey, TValue>.Add(TKey key, TValue value)
DataList d1 = new DataClass(1); // たとえば
DataList d2 = new DataClass(2);
dataList.Add(d1, d1);
dataList.Add(d2, d2);
これでいいんだと思ってました。しかし、これは非ジェネリクスのSortedListでの方法で、IComparableもSystem.Collectionsにあります。しかし、これでも、ちゃんと動いちゃうんです！互換かな？
じゃぁ、MSDN通りにするにはどうするかというと、IComparableにもジェネリクス版というか、ジェネリクス用にIComparer<T>があります。これを使えという訳です。
非ジェネリクス版：System.Collections.IComparable
ジェネリクス版：System.Collections.Generic.IComparer<T>
しかし、ほとんど同じだろうと思って使ってみると全然違うみたいです。
名前をよーく見ると、ICompar"er"なので、比較する道具、つまり、ものさしみたいなイメージですね。なので、実装するメソッドも、Compare(T x, T y)となっていて、2つのオブジェクトを外から比較するようになっています。
じゃぁ、どうするのかと言いますと。実際にIComparerを実装したクラス(正直、DataClassでもいいんですけど)のインスタンスを作成して、この"ものさし"オブジェクトをSortedList<TKey, TValue>に登録してあげます。そうすると、その"ものさし"のCompareメソッドを利用して比較してくれるというわけです。この登録は、必ずSortedList<TKey, TValue>のコンストラクタの引数として設定してください。
// Monosashi<DataClass> : IComparer<DataClass>
Monosashi<DataClass> m = new Monosashi<DataClass>();
SortedList<DataClass, DataClass> list = new SortedList<DataClass, DataClass>(m);
なぜ、コンストラクタが必要なのかというと、SortedList<TKey, TValue>.Comparerは、読み取り専用プロパティだからです。後から設定し直すことができないからです。
ふぅ、メモ完了。ポイントは、IComparerはIComparagleとは違って、"ものさし"なだけだから、ちゃんと"ものさし"専用オブジェクトを用意して、SortedList<TKey, TValue>のコンストラクタで指定しなければならないということです。似てるけど、違うんですね。
ちょっと宣伝。
Javaを始めたいという方は、このJavaの環境の作成の仕方ページを参考にしてみてください><
HTTPヘッダ Connection : close
2009-03-25 Wed 04:40 |
C#+.NETで、HTTPヘッダを設定する際には、HttpWebRequestのAcceptプロパティやRefererプロパティの用に、用意されているプロパティを利用したり、HeadersプロパティにAddメソッドを使ったりします。
今回は、HTTPヘッダにConnection : close を設定したかったので、Connectionプロパティを使うのかなぁと思っていました。
それで、実行してみると、
「このプロパティを使用して、Keep-Alive および Close を設定することはできません。」
というエラーが。 はぁ、そうなんですか、じゃぁいつ使うんですか？って思っちゃいます・・・
それはいいとして、じゃぁ、どうすればいいのかと。
ちょっと調べると、HttpWebRequestクラスには、KeepAliveプロパティというのがあるみたいでした。
ということで、KeepAlive = false にすると、ConnectionがKeep-Aliveじゃなくなって、Closeになるのかな・・・と。とっても適当です（笑）
fiddlerで調べればいいんですけどね。ちょとメモ程度に書いておきます。
今回は、HTTPヘッダにConnection : close を設定したかったので、Connectionプロパティを使うのかなぁと思っていました。
それで、実行してみると、
「このプロパティを使用して、Keep-Alive および Close を設定することはできません。」
というエラーが。 はぁ、そうなんですか、じゃぁいつ使うんですか？って思っちゃいます・・・
それはいいとして、じゃぁ、どうすればいいのかと。
ちょっと調べると、HttpWebRequestクラスには、KeepAliveプロパティというのがあるみたいでした。
ということで、KeepAlive = false にすると、ConnectionがKeep-Aliveじゃなくなって、Closeになるのかな・・・と。とっても適当です（笑）
fiddlerで調べればいいんですけどね。ちょとメモ程度に書いておきます。
