2008-09-24

IComparerを用いたリストのソート

IComparerを継承した独自クラスのインスタンスをリスト等で複数保持している状況下で、例えば、日付順にソートをしたい場合、以下の点に注意。

よくある手法（IComparer継承クラス内の記述）
//日時比較処理
public int Compare ( object x, object y )
{
TimeSpan ts = ( (UpdateHistory)x ).Date - ( (UpdateHistory)y ).Date;
return Convert.ToInt32( ts.TotalSeconds );
}

これだと、TotalSecondsで比較を行っている分には良いが、より厳密なTotalMiliSecondsで比較しだすと、オーバーフローを起こす。IComparerはint型のみの設定でLongが扱えないためである。
しかし、そもそもIComparerがintで必要十分なのは、以下のようになっているから。

同値の場合、０を返す
y>xの場合、Integerの範囲で０より小さい値を返す
x>yの場合、Integerの範囲で０より大きい値を返す

要するに、差分値を直接returnしているのは、横着した表記をしているだけなのだ。int範囲内であれば、有効だし、文句も無いが、厳密な日付比較によるソート等では、正しくは以下のように書くべき。

//日時比較処理
public int Compare ( object x, object y )
{
TimeSpan ts = ( (UpdateHistory)x ).Date - ( (UpdateHistory)y ).Date;
long longTs = Convert.ToInt64(ts.TotalMilliseconds);
if (longTs > 0)
{
return 1;
}
else if (longTs < 0)
{
return -1;
}
else
{
return 0;
}

MSDN：IComparer
http://msdn.microsoft.com/ja-jp/library/system.collections.icomparer.compare(VS.80).aspx

なんて事は無いが、一応メモ。

2008-09-22

GridView内でラジオボタンをグループ化する方法

2.0で起こる比較的有名なMSバグだが、どうやら3.0でも改善されていないらしい。
GridViewにRadioButtonコントロールを配置しても、IDが個々に振られてしまうため、グループ化できず、いくらでもラジオチェックできてしまうというもの。
javascriptを使用する等、回避法はあるが、ここは1つ、RadioButtonカスタムコントロールを作成する方が無難かと。あちこち、同様な内容が出回っているが、カスタムラジオボタンを作る上での必要そうなメソッド群を一応、メモ。
以下、publicなクラスCustomRadioButtonで記述。

protected override bool LoadPostData(string postDataKey, NameValueCollection postCollection)
{
// このコントロールが選択されたか否か
bool newChecked = postCollection[GroupName] == this.UniqueID;
if (this.Checked != newChecked)
{
this.Checked = newChecked;
// コントロールが新たに選択されたときのみtrueを返す
return newChecked;
}
return false;
}

protected override void Render(HtmlTextWriter writer)
{
// 出力先を独自のTextWriterとして出力する
base.Render(new WriterWrapper(writer, this));
}

以下のprivateなクラスWriterWrapperも記述。

///

/// 属性を変更して出力するためのTextWriter
///

private class WriterWrapper : HtmlTextWriter
{
private CustomRadioButton control;
public WriterWrapper(HtmlTextWriter writer, CustomRadioButton control): base(writer)
{
// コントロールへの参照を保持しておく
this.control = control;
}
///

/// 属性の追加
///

/// 属性を表す列挙値
/// 属性に設定する値
///
/// RadioButtonが属性の設定のために本メソッドを呼び出すため、本メソッドで変更したい属性値を設定する
///
public override void AddAttribute(HtmlTextWriterAttribute key, string value)
{
switch (key)
{
case HtmlTextWriterAttribute.Name:
// ラジオボタンのグループを表す
// ユニークとせず、もともとプロパティで設定した値を出力する
base.AddAttribute(key, control.GroupName);
break;
case HtmlTextWriterAttribute.Value:
// POST時に出力する値を表す
// コントロールを識別する必要があるため、ユニークとする
base.AddAttribute(key, control.UniqueID);
break;
default:
base.AddAttribute(key, value);
break;
}
}
}

カスタム化しなくても、純正のRadioButtonが気兼ね無くGridViewに配置できる日が来る事を願う。

2008-06-01

「要求を仕様化する技術、表現する技術」読書会を終えて

備忘メモを粒度無視で。

要求において、品質要求はおろそかにされがち。機能要求等と同等に重要。
明文化するのは、作るものの「合意」を取るため。
理由"Reason"を、仕様書に設けるのは良いかも。上げられた要望が、何のために必要なのか後から精査しやすいし、顧客とのすり合わせでも使える。
アバウトな表現は使わない（〜等、etc）。全て挙げること。
「要求」と「仕様」をはっきり区別すること。混同して利用している場合が大多数。
要求をあいまいにしない。
否定的な表現が出てきたら、怪しいと思うこと。
全てのパターンを網羅すること（IFがあれば、ELSEもちゃんと考えること）。

2008-05-28

DataTableにデータを格納した状態で、カラムを指定してDISTINCTをかける方法。

便利そうなので、メモ。

DefaultViewを使用する。

DataTable dt = GetAnyData();
DataView dv = dt.DefaultView;
DataTable dtResult = dv.ToTable("テーブル名", true, new string[]{"カラム1", "カラム2"});

ToTableにはいくつかオーバーロードがあるので、状況に応じて、使用するメソッドを選択すると良い。引数のbool部分が、DISTINCTを実施するか否かを設定する箇所。テーブル名を指定しなくてもOK。

2008-03-26

LINQプロバイダ

これまで、ADO.NET（特にDataSet周り）に苦しめられてきた経験上、LINQの活躍に一応の期待を寄せているのだが、中々に魅力的。

LINQプロバイダとして、以下のものが用意されるとの事。(at .NETFramework3.5)
- LINQ to Object
- LINQ to SQL
- LINQ to DataSet
- LINQ to XML

既存のDataSetへのクエリも記述でき、これまでの"Selectメソッド"に頼らなくて済む点が、素晴らしい。コレクションや配列への問い合わせも、XPathに頼らない要素の取得も、可能。統一的なLINQ構文で、様々なデータアクセスが行えるのは、ありがたいかも。
実装における、これらLINQの潜在能力がどれ程かは、使用者側に依るものだろう…。