DataGridViewのキー制御

相も変わらずキー制御がここ最近のテーマ。

某MultiRowコントロールはデザイン情報をテンプレートとして参照できたから、フォーカスのあるセルをチェックしてそれなりなショートカットキーを割り振ることができたんだよねぇ。
ところがDataGridViewはそういった情報がない。やるとしたらDataGridRowクラスあたりをチェックして・・・となるんだけど。

んー、コントロールがロードされたときの処理が色々多くなってきたから、そろそろ構造的に考え直さないとまずいかなぁ。

TabIndexがっ

今まで全然考えていなかったけど、今日になって「やばっ」と気づいたTabIndexを利用したキー入力制御。VB6までだとTabIndexはForm内部で重複なしだったから、単純にコントロールに設定されているTabIndexを元にして色々と制御を行うことができたんだよね。<br><br> ところが。

.NetになってForm内ではなくコンテナ内で重複なし、と変わっていた・・・。

これ、ちゃんと制御しようとするとコンテナのTabIndexとかもきっちり見ていないとできないなぁ・・・。今のところは、実装してもらう人に注意してもらう方法でやりくりする予定だけど。グリッド系のコントロールがなければ、SelectNextControlメソッドやProcessDialogKeyメソッドあたりのオーバーライドですむんだけどなぁ。

DataGridViewのProcess～系メソッド

DataGridViewのEnterキー対応のサンプルは結構みつかるんだけど、だいたいはProcess～メソッドのオーバーライドによって対応しているみたいで。

でも最近思ったのが、CellValidatingイベントでキャンセルした場合、Process～メソッドで例外が発生するんだよね。処理の内容を考えると、例外が発生するのは当たり前（キャンセルしているのにセルを移動しようとしたため）なんだけど、これに対応しようとするとTry～Catchでトラップするか、Validatingイベントの結果を保持していないといけなさそうなんだよね。

なんかTry～Catchで対応するってのがしっくりこないんだけど、ほかに方法があるんだろうか？

MultiRow・・・

ここしばらくまともに実装はしていないけど、近々やる事になりそう（というよりもやらないとピンチ）なのがMultiRowコントロールが関連した画面の表示されるまでの時間短縮。キー制御の都合もあって、MultiRowコントロールは色々と下準備する事があるんだけど、その甲斐あってか（？）表示されるまでの体感時間がえらいことに・・・。

やっぱり表示されるまで１０秒近くかかるのはシャレにならんよねぇ。

つーことでソースの見やすさ云々は忘れて、久々速度へ挑戦することになりやした。どこまでできるかは不安だけどね。

.Net3.0

たまに3.0の力を試すべく、Expressionを試しているんだけど、WPFってスゲーというのが正直な感想。まあGPUを普通に使えるからなんだけど、描写能力が圧倒的に違う。普通にWindowsFormとかで作成している限り、絶対に勝ち目がないぐらい。

業務用アプリだから、といっておろそかに出来ない時期がそう遠くないうちにくるんだろうなぁ・・・。時間さえあれば、今からでも切り替えたいくらいだ（ｗ

Validating周りで

最近Validatingイベントの抑制をやってみた。理由は簡単で、現在の案件の仕様が、Validatingでチェック（と名称の表示など）を行うようにやっているんだけど、毎回毎回値の変更があるかどうかをチェックしないといけないの？という要望からだった。

考えてみると全くその通りで、今まではValidatingイベント内部で値の変更をチェックし、変更されている際はマスタから名称の取得などをやるようにしていたんだけど、そもそも「Validatingイベントが値変更時にのみ発生する」という条件が付与できれば。
結果は良好なんだけど、一部で厄介なパターンも。

グリッド系コントロール（DataGridViewとか）だと、セルのValidatingイベントは起きないケースがあるということ。タイミングとしては最終セルから別コントロールへ移動した時とかかな。
現状はこのタイミングで別のValidating処理用イベントを発生させているんだけど、こうなるとValidatingの結果キャンセルされた、という処理がマズイ事に。

打開策は今のところ思いつかないので後回しなんだけどね。他では多分こういう方法は使わないんだろうなぁと思いつつ。

質問と回答と

何らかの質問に対して回答を出す。普通に行われる事だけど、最近ふと思うことが。

特に掲示板上でのやりとりを見ていると感じることが多いんだよね。それは「質問者自身に気づかせるようなレスをつけること」。これ自体はとても難しいやり方であるし、実際にそれを行っている人達は素直にスゴイと思える。

自分もできるだけそのように受け答えできればいいねぇ、とは考えているけれどもまだまだそんなレベルにはあるわけもなく。回答をズバッと言ってしまうことが多い。これじゃあいかんよなぁ、とはわかっているんだけどねぇ。

で、最近気になるというのがこのあたりで、「揚げ足取りしているようにしか見えないレス」が紛れ込んでいるというところ。多分レスした本人はそういうつもりはないんだけど、いかんせん書いた内容を見ているとそうとしか取れない事があるんだよね。
自分がよく参考にさせてもらってる＠ＩＴの掲示板とかでも結構見かけるので、「こういったやり方って難しいねぇ」と思う。現実世界ですらままならないってのに、文章のみなネット上でそれを行うってのはスキルいるよなぁ・・・。

おまけ
現在ＤＳでWishRoomはじめますた。絵柄がたまらん。

人を育てるってこと

ITMediaの「「どうして頑張るの?」に答えられるか」という記事。
(http://www.itmedia.co.jp/enterprise/articles/0701/23/news002.html)

結構共感。自分の中でも、「短所の指摘よりも長所を生かす方向で」というのが主な考え方だったので特に。今の会社も前の会社もそうだったんだけど、昔の（というほど昔じゃないけど）育て方は「短所を減らす」というやり方だったような気がする。そんな中で自分も育ってきたから、ある程度年がいっている人たちが同じように育てていこうとするのは理解できる。

でも自分の下に人がつく、または複数人と仕事をしていく環境が多くなるにつれて「それじゃマズイ」という気持ちが大きく。自社の社員だけだったとしても、昔と同じ教育方法では次につながる人材ってのは育たなくなると思う。自分の環境に限って言えば、それが今の「中間層がいない」という現実で現れているんだと思う。

人の短所ってのはその人が持っている長所で補えればそれでいいと思うし、苦手なところを克服するよりも得意なところを伸ばす方が遙かにモチベーションもあがるってもんで。
実家が学習塾なぞやっていた事があるんで、なんというか「物を教える」とか「人を育てる」という場面は少しは見てきている。それを踏まえるとやっぱり、今の勤務先での育て方ってのは「後で後悔することになる」と考えちゃうんだよねぇ。

スキーマの異なるDataTable間でのデータコピー

同じようなレイアウトの帳票を作成する際にぶちあたってしまった問題がこれ。今現在利用している、ReportViewerテクノロジでは帳票定義であるrdl（またはrdlc）ファイルにてデータ取得対象となるDataSetの情報（というかDataSetに限らず取得元の情報）を保持してしまっているので、プレビューなり印刷する際にはフィールド名などが帳票定義で保持している情報と一致していなければならないのよ。

データベースから取得したデータだけが帳票の対象だ、ってならＳＱＬ実行時に別名をふってあげれば済む話なんだけど、実際はそうでもなくプログラム的に生成したデータや、別途保存してあるファイルから取得したデータも対象になる場合が多いので、単純に「別名ふって取得すればいいじゃん」とできないのよ。
となると、取得結果がDataSetとして生成された「 後 」にカラム名を変更するか、という方向を考えたんだけどここもなかなか問題が多い。

面倒なのは取得したDataSetの中で、直接DataTableが保持しているカラム名を書き換える方法。この方法がうまいこといけば一番レスポンス的にはいいんだよね。んじゃあ、何が問題になるかというと、変更後のカラム名が既存のカラム名と重複する場合。この場合は単純に行かなく、重複しているカラムを先に適当な名称に置き換える必要がある。ここから先はまだ試していないけど、DataColumnクラスでは元々の取得元情報であるTableプロパティもあるのでそことの関連がちょっと不明。ここも書き換えるのか、そもそもTableプロパティで参照できる取得元情報自体を消してしまえばいいのか。

このあたりが全然解決というか調査しきれていなかったので、今現在はカラム名を変更するのではなく、新しいDataTableを生成してそっちにデータコピーして返却するようにしているんだけど、このデータコピーが・・・素直に書くと速度的にキツイ。
スキーマが同じならImportRowメソッドやらDataTableのCopyやら手段はあるんだけど・・・。

なんかうまいこと行く方法を見つけておかないと、あとあと大量データでカラム名の変更なんてやろうとした日には確実に泣けるなぁ・・・。

さてさて

年も越して明日からは通常通りな勤務になるんだよねぇ。今月は汎用的なマスタメンテを２パターン作ってもらうのを外注さんにお願いして、自社の社員はデータクラスやらなんやら色々と実装してもらっていかないと・・・。

人に出す作業を考える時間がかなりかかっているのが正直キツイ。自分の作業がある意味一番遅れてるってのがなぁ・・・。