C#3.0の話題を出したときに、少しだけでていたラムダ式。
CodeZineでサンプルがでていたのでちょっと張っておく。
Common Lispでのラムダ式の一例
(setf f #'(lambda (x) (expt 2 x))) (funcall f 10)
おびただしい量の括弧です。しかし、C# 3.0のラムダ式も負けてはいません。次のようになります。
カッコいいラムダ式の一例
Func<int, int> f = (((x)=>((((x)>10))?(((x)+x)):((x*(x))))));
f( 9 );
これ、なんていう正規表現？可読性の「か」の字もねぇぞ！
[HOWTO] ADO プログラムからのセッション プーリングの実装
なんでいまさら・・・と思ってみてみたら、Ado.Netじゃなくて純粋にADOだった。つまるところ、既存のVB6資産でも有効にできるってとこだねぇ。といってもウチの社内では「セッションプーリング」を判っている人はいないだろうから、多分今まで通り「ＡＰ起動時に接続、終了時に解放」という流れはそのままなんだろうなぁ。
まぁ自分もプーリング知るまでは、それしかない、と思っていたからあまり強くはいえないｗ
しかし接続文字列で指定できたとはねぇ・・・意外とまだ知られていない（公表されていない）設定があるんじゃないのかな？
業務アプリ作っていると必ずといっていいほど、話題になりやすいのがEnterキー制御。
昔からの習慣で、Enter押下で次の項目へカーソルを移動、というのが多いんだよね。それ自体は特に否定も肯定もしないけど。
ただ、その機能をDataGridViewに追加しようとする前に、ちょっとだけ考えてみて欲しい。
Enter押下→次のセル、だけでいいのかどうか？
画面によってはEnterで次コントロールというのがあるだろうし、下のセルへ移動させるのもあると思う。そのあたりを踏まえてどう拡張するかってのを考えて欲しい。そのあたりを踏まえていれば、あとあと「えー」なんて文句をいいたくなる事も減ると思うｗ
実際の対処なんて、大したことはないんだよね。
ProcessDialogKeyメソッド、ProcessDataGridViewKeyメソッド、ProcessRightKeyメソッドあたりを調べてもらえばわかると思うけど、このあたりで「Enterの際にはセル（またはコントロール）を移動する」というロジックにしてあげればＯＫ。
ひっかかるとしたら、編集状態がからむとき。
EndEditメソッドを呼び出して、その結果ＯＫなら移動してあげる、とかそういう制御は必要だろうね。
DataGridViewを利用しているとやっぱりExcelみたいな使い方をしたくなると思われ。
前回（アンバウンドなDataGridViewでフィルター機能）書いたのもその一つ。なので今回はセルの検索をやってみようと。
セルを検索するときも、バインディングしているかどうかでロジックは変わる。
バインディングしている際は、現在のDataSetからDataViewを作り出してしまってしまえば、どの行が対象なのかがわかるので、後はどのセルかを走査してあげればＯＫ。
アンバインドの場合は、元となるDataSetがないのでDataViewを使えない。なので力技の出番となるんだよね。
共有行を一気に非共有行へとしてしまうように（ｗ）、全ての行とセルを一斉に走査するしかないんじゃないかなぁ。
あ、もちろんDataGridView自体をカスタマイズして、仮想モードでちゃんと動くようにしてある場合は別ね。
元ネタはニュースグループに投稿されていた、「WindowsVista上でのVB6sp5のインストールにて」という件について。
Vistaでは今までのMDACと互換性を保持しているWindowsDACというものがインストールされている。そしてこれはMDAC2.8として扱われるのでそれ以前のバージョンはインストールすることはできない。
今回の件では、VB6Sp6であればインストール可能という事なのでどうにかなるだろうけど・・・。つか、とっくにサポートされていないSP4やSP5を使おうと考えるのが、もうダメってことなんだろうね。
自分としてはふるくさーい人間なんで、丸付き文字は「機種依存だコノヤロウ」と、問答無用で拒否する傾向にあったり。
で、いろんな話を聞いているとそのあたりの情勢も結構変わってきたようで。
旧来のShiftJis（JISX0208）では、１～２０までしかなかった。なのでそれをベースにしているeuc-jpやISO-2022では表示できない。
ところが現在はJISX0213という規格もできて、そこでは１～５０までがサポートされているんだよねぇ。ついでにいくとUnicode3.2規格でもサポートされるので、今後は普通に使っていい、とする必要はあるかも。
今現在請求周りの再設計・・・。
そこで今まで考えてはいたけれど、ということを改めて見直してみた。それは「請求の裏返しが支払」という事。まぁ販売管理やっている人だと、結構こういう事言うのはあるね。
でも、それを実際にやってみたことはないんだよな。
絶対にデータのストレージ先は分けて設計しているんだよな。
ということで、頭の回路をフルフルに動かして考えてみた。結果、多分いけそうだね、という形までは思いつけたのよ。大元の考え方は次のような感じで。
ある科目なり項目に対して、金額（売掛または買掛）が発生するその金額に対して回収または支払の予定をたてる予定に対して金種（現金や振込み）の移動が発生する
こういう観点から見れば、売上～入金も発注～出金も同一のフレームワークで定義できるんだよね。
ついでなんでよく言われそうな点についても考えてみた。
（１）売掛と買掛を同一テーブルにすると見づらいし、メンテのときに面倒
ビューを利用すれ。本来はテーブルを直接触るほうが変。つか「見づらい」という観点でＤＢ設計するな。（２）売掛と買掛は意味合いが違うんだから、別テーブルじゃないとおかしいのでは？
情報を定義する際の視点の違い。どちらでも意味がちゃんと通るので、「こうじゃないとおかしい」のは成り立たない。どちらでもいい、が正解。
・・・まぁこんなところかと。ああ、なんかグチっぽいなぁｗ
昨日、自動採番周りを再設計していた際に思い出した。
別の案件で同じように自動採番の仕組みを構築していたんだけど、排他制御まわりで上手くいかなかったんだよね。
で、そこで単純なことを忘れていたのに気づいたわけで。
「大きなトランザクション中だから、自動採番近辺でトランザクション終了してもロックが外れるワケがない」
・・・あたりまえだわなｗ
ということで今回はくだらないミスをしないためにも、自動採番周りは別セッション開いてやることにしようかと。ついでに、コネクションブールを考慮して、トランザクション終了時に自動で接続切るようにしてしまおうかな。
昔と違ってコネクションの接続解放のコストって大分なくなってるからねぇ。ＡＰ単位でコネクション維持しておく必要がなくなってるもんな。
データバインディングした状態で、フィルタ機能をDataGridViewに実装するのはサンプルがMSDNにあるんだよね。DataGridView 列ヘッダー セルのドロップダウン フィルタ一覧を作成する
ただしアンバウンドな状態でのサンプルってのはないんだよな。
というのもアンバウンドな時にフィルタリングする、というのは処理的に大した話じゃないんで。
バインディングのときはDataViewを利用して簡単にフィルタを行えるけど、アンバウンドのときはそうはいかないのよ。同じ手法でやるとすると、「今現在保持している値をDataSetに収納する」ということをやってからじゃないと、DataViewでフィルタはかけることができないね。地味にこの部分がコスト高い。
なのでそこはすっぱりと諦めて（ｗ）バインディングしているかどうかでフィルタ処理を行うクラスを切り替えてしまう、というのが一番いいんじゃないんだろうか。
ちなみにアンバウンドな時のフィルタというのは、「DataGridViewRow.Visible = False」にするだけ。
これだけな話なのでサンプルがないんだよね（ｗ