2008年3月27日木曜日

DataRepeaterコントロール

DataRepeater

ちと今回は別の話題として。

VisualBasicPowerPack3.0として最近アップデートリリースされた追加コントロールライブラリ。ShapeとかLineとかVB6までの開発者を対象としたコントロールが含まれているだよね。その中に要望が結構高めだったDataRepeaterコントロールが。

とりあえず入れてみてささっと触ってみると、デザインがドラッグドロップでできる分やっぱり使い勝手いいなぁ(w、などと思えた。まぁ.Net特有の「DataSetありき」というのはいたしかたないところだろうけど。

ツールバーが強制的に配置されてしまったり(消せるけど)するけどそこらへんは大した問題じゃなさそう。どちらかというとDataGridViewの様に、常に新規行を表示させる設定がない(デザイナ上ではない。プログラムからは行えるハズ・・・未確認)とかそういうところの使い勝手が異なるのが気になるくらいかな。

このサイトでやっている伝票入力用セルを作るというのも、こいつがもう少し早くに見えていれば実行しなかったかも(w
あー、でも列ヘッダがないとかそういったところで色々手を加えないといけないから、そんな変わらなかったかな?

誰が書いても同じ?

元ネタ
「誰が書いても同じコード」は大事なことなのか - ひがやすを blog
誰が書いても同じコード幻想(凪瀬Blog)

ネタとしては「誰が書いても同じコードというのは大事か?」というハナシなんだけど、ここらへんは労働環境というかその会社の風土、意識が大きくかかわってくると思う。大企業になればなるだけ、画一的なコードを保守性のために求めコーディングを行う人によってコード(アルゴリズムの方が適してるかな?)が異なるなんてことを避けようとするね。
対して中小規模の企業となるとそうでもないところが増えてくると思う。
このあたりは色々と意見が分かれるのが当然だとは思うんだよねぇ。
どちらのリンク先でも、コメントが大体2分されているところを見てもそうだったように。
自分としての意見は「まず結果(アウトプット)の要件を満たすこと」が一番大事であり、「アルゴリズムが仕様通り」というのはそれ以下の扱いでいいと思っているんだよなぁ。
極論的に言うと「アルゴリズムはどうでもいい(w」。そこは実際のコーディングを行う人間の裁量範囲だと考えているんだよね。まぁ詳細仕様として一例となるアルゴリズムを記載する必要はあるかな?と思うところはあるけど。それを使わないといけないなんて事はないよなぁ・・・。

重要なのは。
コーディングを行う人と仕様を起こす人との間でちゃんとコミュニケーションが取れるという事だと。コーディングを行う人が「このようなアルゴリズムでやろうと思う」という意思を、仕様を起こす人へ伝えて、そこでちゃんと意見・意思のやりとりができていること。

ここに尽きると思う。
仕様を起こす人は機能の目的を定義し、コーディングをする人はその目的を達成する方法を定義する。今のところ自分としてはそういう役割分担が適していると思っているし、悲観的な見方としては「そうせざるを得ない」というのもあるんだけどね(w

ついでに読んでおくと面白いところへのリンク。
The Joel on Software Translation Projectというサイトより。
やさしい機能仕様 パート1: なぜわざわざ書く必要があるのか?
やさしい機能仕様 パート2: 仕様書とはどんなものか?
やさしい機能仕様 パート3: だけど・・・どうやって書くの?
やさしい機能仕様 パート4: ヒント

2008年3月26日水曜日

ひぃっ

3月ももう終わろうとしてるじゃないかw

ただいま技術講習と仕様作成、打合せなどてんこもりな毎日。
時間なさすぎ。やること多すぎ。問題多数です。本当にどうにかなるのかなぁ・・・?

2008年3月25日火曜日

OOとAO

これだけしか書いていないと、なにがなんだか(w
OO(Object Oriented)はオブジェクト指向で、AO(Aspect Oriented)はアスペクト指向の略。

今現在のフレームワークのようにオブジェクト指向(的な)で設計・開発を行っていると、どうしても面倒なというか、あまりスッキリしない部分というのが色々とでてくるんだよね。

それは「どこでもやるような共通的な処理」。

オブジェクト指向は名前の通りオブジェクト(=物)を基本とした考え方なので、売上伝票とか契約書とか、そういった実際の物をベースとした設計になるんだよね。今回もデータクラスのまとめ方はこの発想になっている・・・つもり(w
でもそのオブジェクトの中では、ログへの出力とかトランザクションの制御とか、どこでも必ずやるような共通的な処理というのも出てくるわけで、こいつが思想の上ではなかなかに相性が悪かったりするわけだ。というのもそういった共通的な処理というのは、そのオブジェクトが本来するべき振る舞いとは異なるから、なんだよね。

そこでそういった本来の振る舞いは本来のクラスで、それ以外の処理は別のクラスで分けて管理したほうがスッキリとして扱いやすくなるんじゃないのか?、というのがアスペクト指向。

.NetFrameWorkとしてはそういった思想は持っていないので、言語レベルやフレームワークとしてのサポートはないけれど、属性を利用してそれとほぼ変わらないことは実現できるんだよね。そのあたりをもうちょっと手を入れて使いやすくしたのが、Spring.NetとかS2Container.Net(Seaser2)とか、そういった有志の手によって製作されているフレームワークだったりするわけだ。

AO自体はDI(Dependency Injection:依存性の注入)と一緒に語られることが多いね。DI自体は今回の手法だと、DataComponentクラスとか定義ファイルからのデシリアライズとかで行っているのよ。あとはコレをうまいこと扱えれば・・・。

自前でそういったことをやろうとすると、でてくる壁はカスタム属性とかにたどり着くんだよね。んー、あると確実に楽なのはわかっているから何年かかけてとりこむべきだなぁ・・・。

2008年3月24日月曜日

DataGridViewのHitTest

MultiLayoutなる伝票入力用のセルや編集コントロールを用意するところまでは、これまでの記事にて色々書いてきたのである程度のイメージはついていると思う。

ここまでやってくると次に出てくる問題は、
セルをクリックした際にその直下のコントロールへとフォーカスしてほしい
というところにきてしまうんだよねぇ。使ってみると当然そう思うんだけど。

というのもDataGridViewの仕組み上、セルにフォーカスが移るけどその中のフォーカス制御なんてものは当然やるわけがないからなんだよね。いや、もともとここまでの使い方しようなんて酔狂は少ないから当然なんだけどねw
ここまでやる前にサードパーティ製品を探すからw
でもそこは、あえてDataGridViewでがんばってしまうのがこのサイト。
け、決して貧乏だからとかじゃないんだからね!
某社の製品購入したはいいけど遅かったからやめた、なんてこともないんだからね!

くだらないやりとりはおいといて、この問題を解決するにはHitTesと呼ばれるものを利用する必要がある。
まー、DragDropとかでも利用しているんでたいした話じゃーないけどね。
要は、セルがクリックされた際の座標を編集コントロールにも伝えてあげればいい、というだけだから。

ということで具体的なことは次からの記事で書いていきます。

2008年3月21日金曜日

Excelでの小技

どこかのサイトで見た内容で、右クリックメニューにセルの結合・解除を追加するというのがあってやってみた。まぁマクロとして組み込んでおけ、というハナシなんだけどね。これが非常に便利だったりする。

Sub auto_open()  
'auto_open に既に他のマクロが記述されている場合には、  
'この1行だけを追加する  
    Add_RightClickMenu_2 1  
EndSub  

Sub Add_RightClickMenu_2(num%)'標準メニューの下に追加  
  Dim iAsLong  
  Dim cstBarAs CommandBar 
  Dim wcbAs CommandBar 

  i = 0 
  For Each wcb In CommandBars 
    i = i + 1 
    SelectCase wcb.Name 
      Case "cell","Cell","column","Column","row","Row" 
           Application.CommandBars(i).Reset 
           Set cstBar = CommandBars(i) 
           cstBar_sub_2 cstBar 
    EndSelect 
  Next 
EndSub 
Sub cstBar_sub_2(cstBarAs CommandBar) 
  Dim i% 
  i = cstBar.Controls.Count + 1 

  With cstBar 
      .Controls.Add Type:=msoControlButton 
      .Controls(i).Caption ="セルの結合(&B)" 
      .Controls(i).OnAction ="CellMerge" 
      .Controls(i).FaceId = 798 
      .Controls(i).BeginGroup =True 
  EndWith 

  i = i + 1 
  With cstBar 
      .Controls.Add Type:=msoControlButton 
      .Controls(i).Caption ="セルの結合解除(&R)" 
      .Controls(i).OnAction ="CellDivide" 
      .Controls(i).FaceId = 800 
  EndWith 
End Sub


これを個人用マクロとして組み込んでおけば、常に右クリックしたときにセルの結合とセルの結合解除が出てきます。
個人的にはこれはもう必須(w
ないとやってけないくらい。

ライブラリ屋さんとして

元ネタ:ディベロッパー製品開発統括部 Blog : 開発者共通の悩み?Yomi-Autocompletion の動作に関して

いやぁ、よくわかるわこの悩みが・・・。
案件に依存したものしか作っていない場合には、絶対にたどり着かないこの悩み(w

汎用性と専門性とのバランスというのは、常に悩みどころなんだよね。
極端な話、案件依存したヤツは社内で統一的に使うライブラリにはなるわけがないし(w

いや、声を大にして言えないけど。

2008年3月11日火曜日

DataGridViewのTabStop対応(4) Process~系のメソッド

DataGridViewでキー制御をカスタマイズする際に利用するProcess~系統のメソッド。
ちょっとだけ困ったことがあって、Process系のメソッドのうち一部はOverridableになってないんだよね。
まぁそのあたりも含めてまずは使う必要が多いメソッドについて。

  • ProcessDataGridViewKeyメソッド
  • ProcessDialogKeyメソッド
  • ProcessRightKeyメソッド、ProcessLeftKeyメソッド(Overridableでない)

主にオーバーライドを行うのはこのあたり。場合によってはRight、LeftだけではなくUp、DownなどのProcess~メソッドもオーバーライドする必要が出てくるね。Right、LeftはOverridableでないので、Shadowで書き換えてしまいましょう。
なので、DataGridViewとしてキャストした場合は書き換えたロジックが走らないので注意がいりますな。

基本的なところはMSDN2でも見てもらうとして、実際に呼ばれるのはProcessDataGridViewKeyメソッドとProcessDialogKeyメソッドの二つ。ここがキー制御の大本だと思っていいと思う。
若干呼び出されるケースが異なるくらいだけど、どちらもやる内容としては似たようなもんです(w

極端に言えば、Enterキーを押したら右のセルに移れ!という場合、ProcessDialogKeyメソッドとProcessDataGridViewKeyメソッドにて、Enterキーをキャッチした時にProcessRightKeyメソッドを呼ぶとか直接セルを移動させるとかしてあげればいいんだよね。

前回までに書いていたTabFocus関連の話は、ProcessRightKeyメソッドとかProcessLeftKeyメソッドの中で利用してあげるのが、結構スマートかな、なんて思います。
・・・当然もっともっとスマートな方法はあると思うけど。

2008年3月7日金曜日

オブジェクト初期化子

VB9から利用できるようになったというオブジェクト初期化子。
こいつを使うとクラスをNewする際にプロパティを指定して初期化できるってヤツで。

Dim cust As Customer = New Customer() With { .Name ="libaty" }

これ、今からでも欲しい!コイツが使えると、引数つきコンストラクタ作らないで済む!
ライブラリ屋としては今すぐにでも欲しい機能だ!