| 著作一覧 |
宣伝というよりは、解説だけど、おもしろい。
ちなみに、あの意味不明瞭な説明の問題点は「は」と「が」もそうなんだけど、それの使い方がどこにも出ていない点につきます。というのは嘘だな。確かに、必要最低限にすべて説明していますね。しかもサンプルが出ているからどう使うかはわかる。呼び出しているメソッドのITemplate#InstantiateInについても出ている。でも、その呼び出しによって何ができるかの説明があまりよいとは思えない。（というか、Visual Web Developementを順に読んでいけば良いのかも。MSDNをAPIセントリックに読むとわかりにくいというだけで）
いずれにしても、コントロール全体のコード＋解説があるということの重要さを身をもってわかったのも良い経験でした。ありがとうございます。
#内部構造ってのは良い書き方じゃなかったけど、自分でIDispatch#Invoke内でswitch (dispid) とかして処理せずに、TypeLibをIDLから生成して、ITypeInfo::Invokeへ委譲する（その結果、結局自分のメソッドが呼ばれる）のに似てるな、と思ったということですね。テンプレートHTML＝TypeLib（from IDL）という感じ。もちろん、テンプレートHTMLの中身は知らないのに対してIDLは自分で記述してるわけだけど。でも、IDispatch#Invokeの実装はITypeInfo::Invokeへの委譲で汎用化できる（=汎用化されたIDispatchの実装にとってはTypeLibの中身がどう定義されているかはブラックボックス）ので、そのレベルではやはり相似形といってもそれほどは外していないと思う。というか、それがフレームワークということだし。
ジェズイットを見習え |
でもITemplateはTypeInfoの呼ぶだけの一方通行に対してDataBinder.Eval越しに呼び返される、というのがあるのや、コントロールのユーザーが定義する、という点で、内部構造とは結構違う性質があるとおもいます。<br>（でもまあ実装者からすれば、IDLを外で書いて、作られたTypeInfoを使う、という構造が似ている事自体には特に付け足す事は無いのだけれども）
うん、内部構造というのは「良い書き方じゃない」どころか間違ってますね。逆に外部から提供されるヘルパーとか言えば良かったんだな。<br>でも呼び返しという意味では、IDispath::Invoke(dispid=Foo)->ITypeInfo::Invoke->IDispatch(Dual-に限定する必要は無いんだっけ？)::Fooにまで回るので、呼び出しパラメータで指定されたものから自分の中のどこを呼び出すのかを外部のインターフェイスに委譲するという点に着目すると、ITypeInfoという明らかに外部にあるインターフェイスが実行時にTypeLibの内容からよろしくやってくれる動作というのは、コンポーネント開発者から見ると、外付けのインターフェイスというよりもむしろフレームワークの内部のブラックボックス部に見える（というのは、IDispatchの個々のメソッドを自分で書くような人はあまりいなくて、ATLの実装とかに任せてしまうので、へたすると委譲していることすら気づかない）ってことです。<br>いずれにしても、的を射てなかった（特にユーザー定義のユーザーが開発者ではなく利用者という点）ですね。