元）零細社長のブログ一覧

.NET3.0のコントローラーはUIElementという抽象化クラスで扱えることになっているのでなんでもサブクラス化できる。
ドロップダウンリストにImageがそのままAddできちゃったときはおしっこ漏らしそうなほどびっくりしたものだ。

ちょっとこれ.NET2.0でやったら3日はかかるんですけど(ﾟДﾟ)

ならば
TreeViewにもImageやボタン、はては自作コントローラーもAddできるんでない？


まずは配列を作らなくてはいかん。
ObservableCollectionで自作コントローラーの配列を作ってTreeコントローラーにバインドしてみた。
すると確かに自作コントローラーが並んだ。
しかし階層化されない。
そりゃそうだ。
しかしどうやって･･･。うーむ。

まずは
例によって文献が超少ない中頑張って調べた。どうもHierarchicalDataTemplateというテクニックを使うといいらしい。
ここにサンプルがある（日本語版だとなぜかサンプルプロジェクトのリンクが切れてる）。

サンプルでは

親クラス

コドモクラスの配列（List） 名前

コドモクラス

孫クラスの配列（List) 名前

孫クラス

名前

と用意されていて、大元クラスが親クラスをメンバーとして保持。
コンストラクタで親・子供・孫と、適宜追加している。
なるほど。

で、XAMLでDataTemplateではなく、HierarchicalDataTemplateとしてリソースを作っている。
親・子供・孫それぞれ定義している。
コードを見ると、ItemsResourceのところに、保持する配列のクラスが定義されていることが分かる。
なるほど。

さらにいろいろいじって分かったこと

HierarchicalDataTemplateを定義する方法はXAMLを直に書くしかない。 階層クラスは子供・孫と用意する必要はない。自分をメンバー化すれば再帰的に階層化できる（まぁこれは普通）。

というわけで

親クラス

親クラス 名前 自作コントローラー

という構成でクラスを作って、大元クラスで親クラスを複数用意し、Addしまくって階層構造を作り、TreeViewにバインド。

しかし
名前しか出ん(´･ω･`)

バインド時にDataTemplateであれこれいじってもダメ。

無理なのか･･･？
いやまて、そのDataTemplateのXAMLコードを調べてみよう。
良く見ると並びがオブジェクトウィンドウのWindowの並びに似ている。
そうか、ということは･･･(-_☆)ｷﾗｰﾝ

結果

＜HierarchicalDataTemplate＞ ＜UserControler＞(ここにさっきまでTextBlockというコントローラーがあった) ＜/HierarchicalDataTemplate＞

これだけでよい。
これだけで自作コントローラーを階層表示させることができる。
経験者なら分かるが、これは本来なら非常に面倒で果てしない作業だ。

しかし.NET3.0ならたったの3行（いや、その上にソース引用元とか書かなきゃいけないんだけど）。
しかもロジックコードではなく、XAMLのコードだけだ。

信じられん！
なんて簡単なんだ！！！
(ToT)

WPFにはブラシというクラスがある。
.NET2.0にもあるが、比べ物にならないくらい強烈なやつだ。
.NET2.0ではせいぜい2色グラデーション塗りで満足するレベルだったが、WPFでは複雑なグラデーションもいけるし画像もブラシとして扱える。
PicturePanelが無くなるわけだ。

で、
ブラシはリソース化できる。
リソースというのは、まぁHTMLで言えばjpgみたいなものか。
1個用意して、いろんなシーンで参照する。
ブラシをリソース化すればいろんなコントローラーで利用できるのだ。
そうすれば再利用もしやすいし、イメージの統一もたやすいわけよ。


今回、
背景を動的に更新する方法を調べた。
その背景というのはいろんなコントローラーで利用してまったく同時に更新される。
で、
更新パターンも非常に幾何学的。
ならば、TileBrush(タイルパターンで塗りつぶしてくれるブラシ)の数字をちょこちょこっといじるのが高速かつシンプルだろう。(-_☆)ｷﾗｰﾝ

というわけでアプローチを考えた。
①タイリングの数字をバインディング
②コードで数字を更新
この２つが候補だ。

①ならコードを書く必要はまったくない。
しかし無理だった（BLENDのバグじゃないか？）
そこで②を検証してみた。
更新方法はスライダーを利用。

スライダーの数値が変わったというメッセージを受け取って、その数値でリソースブラシをいじれば良いはず。
しかし･･･。

いや、リソースの取得は成功したんだ。
この関数内でFindResourcesを実行すれば簡単にできた。
このFindResourcesはどの階層にあるリソースでも拾ってくれるので便利なことこの上ない。

で、そのリソースをBrushにキャストして、タイリングのプロパティにスライダーの数値をぶち込めば、スライダーの動きに連動して全コントローラーの背景が動くはずなんだよ。
だが、ここで問題発生。
「読取専用」と言われて例外扱いされてしまうのだ。
ならば
一旦コピーして、数字書き換えてそれをぶち込んでやる！ヽ(｀Д´)ノ
例外は出なかった。
だが更新されない。

なぜなんだぜ？(･ω･)

デバッグ情報ではちゃんと数字は更新されているようだが･･･。

こうなったら手も足も出ない。
助けを求めようにも、
こんな激レアなニーズ、ネットに文献があるはずもなく、社内のWPF使いはオレ一人。
あきらめて日報を書いた。そろそろ帰るか･･･。

否！
断じて否！！

.NET3.0の理念からしてできんはずがない！！
まだやる！！

というわけでインテリセンス出しまくって推理すること10数分。
SetValueというメソッドを発見。
そうか！
これだ！
これはDependencyPropertyに値をぶち込むヤツだ！
DependencyPropertyはなんだかよくわからんが、プロパティトリガーと深い関わりがある！！
これだあああああ！！！
素人プログラマーは論理より先に実行だぜ！（考えたってわからねー）

かくして
リソースブラシの動的更新は成功した。
そのコードは

リソースブラシをゲットして 数字を作って SetValue

たったの3行だ。

これが.NET2.0なら
画像を保持するクラスを作ってそれを各コントローラーのサブクラスにし、タイミングを計って更新するのが合理的だろう（計算・描画と更新を分けて作るわけだ）。

初期化部分 画像クラスを実体化 更新情報受け取った 画像をクリア DrawLineでちまちま描く（For文でタイリング数分まわす） で、各コントローラーの描画ルーチンを呼んで コントローラー描画部分（OnPaintオーバーライド） 自分の画像を、画像クラス情報で埋める。

とまぁ
描画計算が複雑でコントローラーが5個もあれば軽く100行は行く。そう、このブログのように。
色やフォントの保持、デリゲート設定などなど準備も大変だ。

それが.NET3.0なら
たったの3行！＼(^o^)/

もう.NET2.0には戻れねーーー！！（2ヶ月しかやってないけど）

管理もデバッグもカスタマイズも劇的に向上するぜ！？
なんでみんな使わないの！？
まじで感動するって！！
ああ、この感動を同僚ギャルに熱く語りたい･･･！！

ブレイクスルー
いい響きだ。
日常でこれを実感できることはなかなか無い。
今日は久々にブレイクスルーがあったのでいつものようにメモするー。

自作プロパティにトリガーを設定する方法

コントローラーの種類が倍くらい増えた.NET3.0だが、やはり「欲しい」コントローラーは自作する必要がある。
当然、プロパティもニーズに合わせてぼこぼこ並べる。
.NET2.0ならなんの問題も無い。

だが、

C#ではアクセサがイベントドリブンのカギになっている。
値が変わったからイベント発生
この処理の最初の門はアクセサなのだ。
だから.NET2.0ではアクセサ内でイベントメッセージを発行させていた。
値が変わったから今すぐ画面の文字を書き換えて再描画しなさい
という具合だ。

これが.NET3.0のコーディングスタイルと矛盾するのだ。

.NET2.0ならコーディングで再描画させるが、.NET3.0ではXAMLが定義する。
つまりあらかじめ「どのプロパティが変わったらこの描画パターンを実行するか」を決めておくのだ（そのXAMLのエディタがBlend）。
だから、なんとかしてプロパティが変わったことを.NET3.0に知らせなければいけない。
それがプロパティトリガーだ。

このプロパティトリガー
標準のプロパティならドロップダウンで選べるのだが、自作モノは出てこない。
デリゲートでメッセージ発行させても出てこない。
本を紐解いても載ってない（参考書というものは大抵現場のニーズに応えてくれない）。

仕方ないので無理やりXAMLを書き換えて自作プロパティをトリガー化してみた。
エラーが出た。
そりゃそうかとガッカリしたが、よく読むと「DependencyPropertyではありません」と出ているではないか。
そうか。
DependencyPropertyにすればいいんだな！？(-_☆)ｷﾗｰﾝ

グーグルで調べまくってここにたどり着いた。
ここのサンプル通りに書いてうまく行った。
DependencyPropertyで悩んでいる諸君は参考にされたし。

public static readonly DependencyProperty IconColorProperty = DependencyProperty.Register( “IconColor”, typeof(Brush), typeof(PlayButton), new FrameworkPropertyMetadata(Brushes.Black, new PropertyChangedCallback(OnIconColorChanged )));

ご覧のとおり、DependencyPropertyという型を宣言して、実際のプロパティの型は第2引数で指定している（ちなみに第1引数はホンモノのアクセサ）。
なんちゅー無茶苦茶なテクニックだ。型とか超無視じゃん（いや無視してないんだけど）。なんでもありじゃないか。
ゲイツこんなのよく作ったなぁ。

午前中、WPFの本を買うために本屋に行った。

その帰り道のことだ。

会社のビルの前で女性がしゃがんでいるではないか。

何か落としたか荷物整理か･･･
まぁたまに見る光景だ。

年は25。
スーツの着こなしはごく自然。
髪型も後ろで軽く束ねていて全体的に清潔感が漂う。
いかんと思いつつスカートに注目してしまったとしても誰がオレを責められよう？

発見から通り過ぎるまで10秒弱
彼女は立ち上がる気配を見せない。
一体何をしているんだろうと通り過ぎる刹那、
手元を一瞥したらその先にはなんと体長2センチ足らずのなんかの幼虫

！？
なんで？？？(ﾟДﾟ)
その虫持って帰るのか！？

通り過ぎて5歩ほど歩いて気になって振り返ったがまだ立ち上がらない。
仕方ないので声をかけた

「どうしたんですか」もうちょっと気の利いたセリフないんかい
彼女曰く
「こんなところにいたら踏まれちゃうから逃がそうと思ったんですけどうまく拾えなくて･･･」
まじっすか！(ﾟДﾟ)
そんなの普通無視するぜ！？虫だけに
この世知辛い世の中そんな甘いこと行ってたらあんた早死にするぜ！？
正直感動以前にあきれたが
そこはホレ下心があるから紳士的に振舞うわけよ。
指で掴んでその紙に載せたわけよ。クールに。
靴で壁作って紙を差し入れてもらおうかと一瞬思ったがそれじゃイマイチ紳士的じゃないなとジャッジした。
彼女はそれをビル前の植え込みに解放。
めでたしめでたし。
オレは軽く会釈してその場を去ったのだ。

何爽やかに去ってんのオレ！！(ﾟДﾟ)

違うだろ！！
せめて一言なんかあるだろ！！
「これなんていう虫ですか？」と無茶振りするとか！
「なんかあったらまた呼んで下さい」と軽くボケるとか！
「変わった人ですね」と一生懸命ドジｯ子主人公を見守る取引先のイケメンサラリーマン風に謎かけするとか！！
ああああああああ
千載一遇のチャンス逃したあああああ！！！
なんなのこのアドリブのできなさ加減は！！
オレは実は社会不適合者なんだろうか･･･！

あとから考えたら、落ちてる虫助けるなんていい子じゃないか。
スーツは着こなしてたけど、擦れてない。
なんというかキレイじゃないか。


あきらめんぞオレは。
彼女はきっと今ごろ、朝のきれいめサラリーマンを探しているに違いない。
今この瞬間にグーグルツールバーで該当するキーワードを打ち込んでいるに違いない。
そのためにブログを書いたとしても誰がオレを責められようか？
(-_☆)ｷﾗｰﾝ

かつて
ウィンドウズアプリの開発はUIとの戦いだった。

生のCでWin32APIを直に叩くしか無かった頃、
そのコードは100行くらいになった。
窓を出すだけでだ。
そこからマウスだメニューだと人力で組むわけだ。
プログラマーはある日気付く。

オレは窓作るためにプログラム書いてるんじゃねぇ！！

画面のサイズを変えたとき、中身のサイズが変わったとき、スクロールしたとき、
いちいちメッセージ拾って全部手で書いていたのである。


そしてMFCというライブラリがリリースされた。
VC++6を使えばウィザードが自動的に窓を組んでくれるのだ。
ある程度凝った作りもできるし、コントローラーやドキュメントのシリアライズも設けてくれる。
メモ帳程度なら30秒でできるわけだ。

これは感動した。
世のプログラマーはマイクロソフトに涙を流して感謝し、喜んでお布施を納めたのである。
確かに、
何もかも自動でやってしまっては、いざというときカスタムしようにもどこに何があるか分からない。基礎をすっとばすこの仕組みは新人教育に支障をきたす。
そこに不安を覚えるプログラマーもいた。
しかし、ワタシは思った。
ゲイツマンセー！＼(^o^)/

時は経ち、.NET frameworkの時代が来た。
データバインドという技術によってさらに窓操作が楽になった。
しかも型を柔軟に受け止めてくれるので（ｱﾘｶﾞﾀﾔ）、コントローラーの入れ子が気軽にできるのだ。
つまり見た目がキレイなアプリを作りやすくなったのだ。
MFCの4倍は楽だ。
3倍じゃない。4倍だ。
ワタシは思った。
ゲイツマンセー！！＼(^o^)/

.NET framework2.0をいじって2ヶ月。
世はいつのまにか.NET framework3.0に突入していた。
こいつにはWPFというライブラリが含まれている。
UI構築がさらに進化したのだ。
もはやUIのコードは存在しない。
HTML風のマークアップ言語でUIを並べるのだ。
プログラマーはデータ処理ロジックに集中できる。
つまりコントローラーの位置に気を使う必要はないのである。
ついに
プログラマーは「窓のためのコーディング」から解放されたのである。
vistaのアプリがやたら垢抜けてるのはこのテクノロジーの恩恵
ゲイツマンセー！！

と言いたいところだが
コントローラーの動的追加をどうすればいいのかよく分からん。
,NET2.0の時と微妙にプロパティの名前が違ってるし。
コントローラーの種類も変わってる（さんざん世話になったPanelがねぇ）。
で
便利になりすぎたせいか、
ネット文献が超少ないヽ(｀Д´)ノ


うかうかしてると取り残される。
勉強は死ぬまで終わらないだろう。
だがオレはアーバンなプログラマー。
アーバンなプログラマーはクールなUIをさらりと作らなきゃいけないんだぜ。
未だにC++で泥臭いダイアログアプリをひーこら作ってたらギャルにもてないぜ。