（後日記）VC++2008からMFCは再び進化を始め、C++のネイティブコードの重要性を再認識し始めたマイクロソフト戦略の一部なのか、TR1やらMFCの新機能、FeaturePackの配布など、いろいろされているようなので、以下のMFCを過去の遺物と割り切ったような語り方はちょっとふさわしくないところがある。また、今回の進化を受けずとも、MFCはまだまだ捨てたものではないとする意見もネット上にはたくさんある。下記のように実際私にしても結局今でもMFCを使っているし、実際それしか使おうと思っていないわけでもある。
今更MFCというのも何だが、作ったものを人に配ったりするのには、再配布パッケージのみをインストールしてもらえばよいという意味で、.NET Frameworkが必要なCLRを使うよりはMFCでやった方が話が早いので今回の仕事ではMFCを使っているのだが、、。（Win32APIのみで行け？それはもっと不毛な話だよ。。）
個人的にはMFCというものは1996年から付き合ってきているが、マイクロソフトのわかりにくいドキュメントを半日徘徊しまくって、ぐったり疲れただけで何も進展・解決しない、という印象が濃い。というかそういう思い出しかない。（あくまで個人的な話だ。）
そしてトピックによってはそれは今でも全く変わっていない。
CFormView というクラスがある。Viewのくせにダイアログのようにボタンやらいろいろ貼り付けができるとても便利なものだ。使いたい。ぜひ使いたい。ところが、プログラムからこいつのウィンドウサイズを変更するやり方一つ、ままならないのである。いろんな人がいろんな掲示板でこのことを質問している。しかし、たいていは回答者の方が質問の意図がよくわかっていなかったり、結局誰も解決策を知らなかったりして、最後まで解決せずに終わっていたりするのである。何をするにも何かが問題となる。他のウィンドウクラスとは違うのだ。CFormViewは、いろんな機能が、通常のViewとかとは違う感じで実装されているので、いちいちつまずき、利用者である開発者は人生の時間をまた不毛な調査に費やすことになるのだ。
階層構造とか、オブジェクト指向とかがわかって、じゃMFCというものが常に期待通りに動くなんてことを期待してはいけない。MFCには例外的な決め事がたくさんあり、それらの一つ一つをゲームの裏技を攻略するかのごときマニアックさで解決していかなくてはならないのだ。MFCとはそういうライブラリであり、昔からそういうものだったし、今でもそういうものなのである。。
もっと有効に使えたであろう時間をそういうことに費やすのは心身にもとても悪い気がする。
でもいまだに配布するにはもってこいのMFCの手軽さときてる。。困ったものである。悪い時代は全然終わってない。
CFormViewよ、世界中の開発者の人生の時間を返せ。簡単にはできないのなら最初から期待させないでくれ。いいよ別の方法考えるから全然いいよ、始めからそんなものなかった方が時間無駄にしなかったさ。
