こっちも久々に更新。
気がつくと2007年も終わり。今年は.Netに始まって.Netに終わる一年だったなぁ。おかげで当初に比べると色々なことがわかってきて、色々なことができるようになってきたね。
DataGridViewとはまだまだ付き合い長いだろうけどねぇ。未だにわからないところが多々あるし・・・。
ただ、実際にはもうWPFとかに移行していかないとマズイんだろうな。
ま、今年も色々ご迷惑をおかけしましたが、来年もまた変わらずよろしくお願いします。
DataGridView や DataRepeater にこだわりつつ
時代は Workflow Foundation などと言い続けていたら
これからは LogicFlow だろ! と思い始めてきた
色々浅く広くやっていく古い技術者の Blog
こっちも久々に更新。
気がつくと2007年も終わり。今年は.Netに始まって.Netに終わる一年だったなぁ。おかげで当初に比べると色々なことがわかってきて、色々なことができるようになってきたね。
DataGridViewとはまだまだ付き合い長いだろうけどねぇ。未だにわからないところが多々あるし・・・。
ただ、実際にはもうWPFとかに移行していかないとマズイんだろうな。
ま、今年も色々ご迷惑をおかけしましたが、来年もまた変わらずよろしくお願いします。
Download details: Microsoft Filter Pack
SqlServer2005用に提供されているOffice2007ファイルに対してのフルテキスト用IFilterパック。実は元々Office2003までのファイルについてはbinary項目としてテーブルに保存して、そこに対してのフルテキスト検索は行えていたんだけど、今回提供されたこれでようやく2007までのほぼ全てのOfficeファイルに対して直接検索が行えるようになったんだよなぁ。
んで、当然ExpressEditionでも利用可能、とうたっているんだよね・・・。
こう考えると無償でできる範囲ってのは、一昔前のウン千万クラスな案件だと、かなり対応できてしまうくらい広くなっているんだよねぇ。
こうなってくると「支払ってもらうだけの価値」を認めてくれるくらいのモノを作れるようにならないとね・・・。
ClickOnceとかWindowsInstallerとかで配布することを考えると、どうしても今の案件のようなファイル構成というのはあまり相性がよくない。良くないというか発想が間違っている(w
今みたいに画面単位=Exeファイルという構成がどう考えてもマズイ。
そうなると基本的にシステムとしてはExeファイルは一つで、画面単位はDllファイル一つ(もしくは複数を合併)させた形でないと、Vista以降の環境においてはどうやっても問題が出てくるなぁ。
「インストール時に制限すればいいんじゃね?」
という考えもあることはあるけど、それはシステムを提供する側としては問題アリだと考えるんだよなぁ。完全にこっちの都合だし。
アプリケーション(またはソリューション)を「どこにインストールするか」は、そのクライアントPCの利用者が決めることであって、開発者が決めることじゃないのがあるべき形だと思う。
というか、自宅PCとかで考えてもらえば、普通のソフトはそうなっているじゃないの?なんでそれを業務用だからといってルールを変えようとするんだろうね。どっちもWindows上で動くソフトなんだけどなぁ。
対象となるフィールドにインデックスをはっていても、後方一致(’%ああ’とか。ワイルドカードが頭につくタイプ)を行った場合は、無条件でインデックスは使用してくれないんですなぁ。それでそういった場合の対応策というのが調べ物していて見つかったのでメモ。
元ネタ:後方一致を計算列とインデックスでチューニング
リンク先に書いてあるように、要は後方一致時に利用できるようなインデックスを用意する、というのがポイントになるとのこと。ただし、後方一致の際は検索条件を逆転させて(’%いあ’→’あい%’)検索を行うことになる。そしてその対象となるような項目を用意しておけばいいんだけど、面白いポイントはここ。
後方一致用の対象は普通の項目の反転した結果となる
ので、そこはデータベースに計算させてしまおう、というところ。計算列というんだけど、自分はまだちゃんと使ったことはなかったんだよね。
こういう合わせ技で使うと色々できそうな予感・・・。
見落としていたー!!
これをうまいこと使うと、INSERTやUPDATEなどの実行結果をそのまま取得できるんだなぁ。
今回の案件だと、INSERTした後に必ずSELECTして実際のUIDを取得しているんだけど、この処理自体をすっぱりと削除できてしまうワケだ。
DBにものすごく依存している話なので、ライブラリのどこに実装するかは難しいけど、コレが用意されていると、結構楽になる事があるなぁ。
・・・試しに組み込んでみるかな?
忘れないためのメモとして。
大まかに言えば二通りに分かれるみたい。
一つ目はこれ。
SELECT *
FROM
TEST_FULLTEXT TFT
WHERE
CONTAINS(TESTSTRING,'"10*"')
二つ目がこれ。
SELECT *
FROM
TEST_FULLTEXT TFT
INNER JOIN CONTAINSTABLE(TEST_FULLTEXT, TESTSTRING,'"10*"') KFT
ON (TFT.TESTUID = KFT.[KEY])
ORDER BY
KFT.RANKDESC;
二つの違いは「検索結果のランクを利用するかしないか」。上が利用しない純粋な検索で、下がランクを利用した、どちらかというとGoogle先生っぽいやりかた。
恐らく今回は二つ目のやりかたになるだろうなぁ。
しかし試しに100万件のテストデータつくって検索してみたけど、LIKE検索よりも10数%は高速っぽい。
ついにというかVisualStudio2008がリリースされて、FrameWorkも3.5に突入。
そんな中でもこのBlogはDataGridViewだけに拘り続けていこうと思ってますw
いいじゃん、こういう役に立たないサイトが一つくらいあっても。
WPF?SilverLight?知っていますが扱いません。扱えませんよ!w
DragDropの時にはTypeを指定して実際の値を拾う必要があるんだけど、DataGridViewの場合それはDoDragDropイベント発生時の値は利用できないってトコなんだよね。そして標準で用意されているCell関係は全て値のTypeが定義されていない(=Object)なので、はてさてどう書いてあげればいいものか、というとこで悩み中。
DragDrop発生時はこんなコードで、セルの値をDragDropするぞ、とやる。
_dragDrop.DragEffectType = Me.DoDragDrop(Me.CurrentCell.Value, DragDropEffects.Copy)
そして値を受け取る際はこんなコードなんだけど・・・。
Dim targetCell As DataGridViewCell = Me.CurrentCell
Dim cellValueType As System.Type = targetCell.ValueType
Dim copyValue As Object = drgevent.Data.GetData(cellValueType)
targetCell.Value = copyValue
問題となるのは3行目。ここでTypeが必要なんだけど、CellクラスのValueTypeは見事にObjectでやんの。自前で拡張した部分だと、ここはちゃんとTypeを返却してくれるんだけど・・・。
利用できるTypeを取得するGetFormatsメソッドもあることはあるんだけど、それを利用した処理にしてしまうと問題があるような気がしてならないなぁ。
使い始めた当初は「だいぶマニアックで使っている人すくないだろうなぁ」と思っていたんだよね。
まぁ現時点でもそうなんだけどw
でも費用をかけないで~、という何か間違った(w)開発をする時には、コイツ抜きでは難しいんだよね。
機能的には世間一般の帳票ソフトといい勝負ができるんだけど、いかんせんちょっとクセがあるんだよなぁ。
まぁ色々やってみた内容はここで公開できればしていこうかと。
色々とカスタマイズしていてぶつかっているのがイベント周りなんだけど、
DataGridView_CellLeaveイベントとCellクラスのLeaveイベントで、DataGridView_CellLeaveイベントしか発生しないという現象が・・・。
これは自分がカスタマイズしている部分だけだからなのか、元々そういう仕様なのかが全然わからない。
時間がないのもあるんだけど、どのあたりから手を入れてみればいいかもさっぱりなんだよなぁ。