個人的にしばらく悩んでいたReportViewerを利用しての印刷が何とか解決したっぽい。プレビューとプレビューからの印刷は問題がなかったので、確実に印刷メソッド周りで実装がミスっているんだなぁ、と思って調査していたんだよねぇ。
分かってみればやっぱり簡単な話で。
PageSettings.PaperSizeプロパティ以下の各プロパティを設定しても、実際の印刷については影響がないってのが原因だったのよねぇ。しかしPaperSize.Heightとかも不思議な動きで、変更できないならReadOnlyにしてしまうか、例外でも発生させてくれればいいのに・・・と思ってみたりしたけど、結局は自分が動作を理解していなかったという事なんだよな。
まぁとりあえず一つはＯＫ。次は数値入力関係かな・・・厳密にキー制御しようとすると、結構面倒なんだなぁ。
今週に入ってＧＵＩ周りのデザインを開始。しっかし元々苦手分野ということもあって、ものすごく悩みまくり。なんちゅーか、「使いやすいデザイン」というのがみじんも思い浮かばなかったりする。
正直オフコン時代の思想をそのまま使ってもいいとは思うんだが、今回のお客さんは多分そういう「今までと変わらないもの」というのが気に入らないタイプなんだよなぁ。
極端でも「キーボードを使わない」デザインってのを考えてみるかなぁ・・・。
HibernateとかSpringとか色々なデータ周りのフレームワークを参考にしつつ、自分なりのフレームワークを改良し続けているわけだけど、ここのところかなり停滞気味。
なんというかテーブル間のＪＯＩＮをどう扱おうかってところで現在混乱中。ＶＢ６時代に作っていたのは、ＳＱＬ文を生成するだけなクラスだったからオブジェクトの属性なんて何も考えなくて済んでいたのよね。テーブル間のリレーションが属性として設定できるようにしていただけで。
んでも、今回はデータクラスとして、というのがスタートラインだったから「リレーションを考える前にある程度形にしてしまった」のよ。今にして思えばこれがマズかった。これだとＯ／Ｒマッピングが大変な事になってしまうんだよねぇ。
Ado.netだとテーブルリレーション関連のクラスが色々あるみたいだから、そっちも構造を参考にしてみようかな・・・
この間セミナーというか説明会に行ってきたんだが、Officeも2007になってかなり「使ってみたい」ソリューションになっているなぁ、という感じがする。
特に今までは単品単品での使い方しか考えていなかったんだけど、今回はShareServerやFormsServerなど連携して使ってみたくなるんだよねぇ。個人的には承認ワークフロー周りの機能を用意してくれている部分かな。
とりあえずベータ２で試してみる事にしようかと思ってみた。
WinFormでReportViewerコントロール利用してプレビューを表示していて気づいたんだけど、プレビュー画面が表示されただけでは、物理ページ数でページコントロールが更新されていないのよねぇ。
手作業でページスクロールかページ指定するとはじめて更新されるのよ。ＰＤＦエクスポートというもう少しなんだよねぇ。まぁＰＤＦ周りは独自で拡張できるみたいだけど、ページだけは継承して拡張しようとか、インターフェースも用意されていないとかでいかんともしがたいのよ。
WebForm版は問題ないくせになぁ・・・。
継承できるってなんてスバラシイ！、というのが一番思うトコだろうか。ＶＢ６でなんちゃってＯＯＰ形式なプログラムを作っていた身としては、普通に継承できるっていうことだけでもかなり感動なんだよねぇ。
でも、ＯＯＰなやり方を見たこともやったことない人にしてみると、これがそうでもない。まぁ、自分も体感するまでに数年かかっているから気持ちは分かる。
でも「そんなレベルで社内標準とかを語る」のはやめてくれ。マジで。おいらが何も言っていないのは、それでいいと思っている訳じゃなくて、「あなたに理解してもらうのが面倒だから」なんだよ・・・。
今回のシステムでは帳票関係としてエクセルへの出力が必須となっていたり。まぁ理由も簡単で、レイアウトの微調整などが発生しやすいから、なんだよねぇ。そこのお客さんでは、今まで利用していたシステムではプレビューがなかったり（！）、外部出力がｃｓｖだけだったりしていたそうなので、独自にエクセルシートを作成してデータ貼り付けて色々ドキュメントを作っていたそうだ。
ま、こういうふうにシステムのデータを加工してやってくれる風土があるってのが個人的には嬉しいんだよねぇ。システムを上手に活用する方法を考えてくれるから。なもんで、今まで自分が関わったシステムではできるだけ、データとして出力できるような仕組みはシステムとして用意していたんだよね。利用されるシーンはまだそんな多くはないのが難点だけど・・・。
んでもってさすがに帳票ツール決めていないのは問題なので、もう自分の中では決めてしまうことにした。今回はエクセルとReportViewerの２本で行こうかな、と。
費用云々な話もあるけど、ReportViewerってその後の展開を考えたときにも、結構他ベンダーの製品より有利にはたらきそうなポイントがあったりするのでねぇ。自分の中ではActiveReportよりも色々いけそうな気がしてならないしなぁ。
まぁ、腹を決めた以上はやいところ今回の仕事用ライブラリ作っていかないとねぇ。ReportViewerは用意してあるけど、エクセル関連って何もやってないから結構急がないとね・・・。しかしそうなると今回のOffice2007で大きい変更がないことを祈るよ。
現在帳票系のソリューションとして評価中。元々自分の中ではＸＭＬを主体としてシステムを構築してみたいという気持ちがあったので、できれば導入したいと考えてはいるんだけど。Ｃ／Ｓ系システムで効果的に利用するには、どうしてやればいいかねぇ。
最も効果的に利用できるのはｗｅｂ系なんだろうけど、今回のお仕事はＣＳなのでそういった選択はナシなのよ。
自分として最も望ましいのはこんなソリューション。
・帳票デザインの為にかける時間が少なくてすむ（直感的にデザインできる）
・用紙に対する制御が豊富（ストックホームや伝票系も楽にデザインできる）
・プレビュー画面などはこちら側で継承することによってカスタマイズが可能
後は変更に対して強いとかもあるけど、これは帳票側というよりはシステム側だろうしねぇ。ちなみにXMLFormatterを評価していて、一番どうしようかと考えているのは、ＰＤＦありきな点かな。なんとかイメージデータとしてＣＳ間でやりとりできないものかなぁ。詳しく見ていないからなんとも言えないけど、今の知識だとＰＤＦ生成→ローカルコピー→Reader起動という流れになりそう。なんつーか、しっくりこない。予算的に余裕があれば、クライアントすべてにFormatter導入とかでいいんだろうけどねぇ。それもなんだかなぁ。そんな環境構築を面倒にすることはやりたくないしね。今回はシステムメニューをClickOnceで配布してそれ以外はメニュー内部で更新制御を行うつもりだから出来るだけ楽をしたいのよねぇ。
将来のためにもどうにか使ってみたいんだけど・・・もう少し時間が欲しいね。
今さらになってDataGridViewを利用したエントリ系を調査中。以前のDataGridに比べると確かにデフォルトでの表現力などは向上しているので凄いと思う。
でも「もう少し」なんだよな・・・。
Textのセルなのに、TextBoxと違う実装がされていたり「なんで？」という部分も色々あったりする（まぁそういった所は自分で拡張しなさい、って事なんだろうけど ←事実そうしました）。技術者としては色々手を加えることができそうなので面白いのはあるね。でも他の人に使って貰うとなると、ちょっと微妙。
中小企業の開発で使うコンポーネントとなると、おそらくはグレープシティ社とかそういったところから色々出ているコンポーネントを素直に利用するのが多いと思う。
ただ最初の開発案件によってはサードパーティ製品を利用するってのは難しいところもあるねぇ。受注額として７桁とかだと恐らくは次の案件にて購入する、とか今回の案件の開発費用として計上するのは難しいだろうしね。まぁそういった縛りがあるからMSのReportViewerとかをみつけることが出来たってのはあるけど。
なので個人的にはしばらくDataGridView周りを色々と調査して、サードパーティに頼らない開発基盤を用意できるようになりたいもんだ、と思いますわ。
社内で独自に進めていた.Net用フレームワークもある程度の形になってきたので、今月に入ってからは一緒に仕事している人にメンテナンスと更新系を何本か作成してみてもらった。
更新系は俺がきれいさっぱりと忘れていた、IDataReaderをオープン中にはそのConnectionからSQLは実行できないという罠に引っかかっていたので、急遽DataSetを利用したループ構造が作れるように変更。メンテナンスだとそんなロジック作らないから、モノの見事に忘れていたんだよねぇ（最初はTransaction関連が原因だと勘違いしてたくらい）。
でも実際にメンテナンスを作ってもらって今日のところ、１本２時間未満で用意できるようになってくれたんだよね、これが。心底嬉しかったねぇ、目指していた方向が間違っていないってのが見えたもんで。別の都合があって３層構造にするのは断念したけど、今回のフレームワークに慣れてもらえば、次の開発案件あたりでは３層構造も導入できるかもしれないな・・・。とりあえず目標の一つである、実装量を減らして品質の高いＡＰ作成ができるってのは実現できそうだなぁ。
それとスケルトンをフレームワークと言っている人たちへはこっちで用意した仕組みではなく、ロジックゴリゴリなサンプルを渡してやったりした（ｗ
俺の気持ちとしては、「とりあえず頭抱えて苦しんでこい。話はそれからだ」というところなんでＯｏな設計とそうでない設計の違いをそのうち見せてやる！、とある意味間違った方向に熱意を傾け中（ｗ
次の課題はやっぱり帳票・・・。いまだにツールが選定できませぬ。
(;´Д`)y─┛~~