none
次に身に付けるべき知識 RRS feed

  • 全般的な情報交換

  • 場違いだったらすみません。

    visual studio 2008 VC++ (MFCダイアログベース)をやっています。仕事の都合で、生まれて初めてやったwindowsプログラミングがこれで、これ以外のwiondowsプログラミングの経験はありません。VC++について、知識の幅を広げたいと思っています。

    ウィザードを使わず(create文などで)コントロールを追加したり、それぞれに変数割り当ててそれを操作したりと、一通りコントロールの使い方は覚えたかな、というレベルです。このあと、どういう方向へ手を付けていくのが良いのでしょうか?1,2のうちのどちらか、そして文中にある「何か」を具体的に何にすべきか、それともまったく別の第3の選択肢(=その他)があるか、どなたかよろしければアドバイスください。

      1.ダイアログベースプログラミングの範囲の「何か」を深く突っ込む

      2.ダイアログベース以外の「何か」に手を広げる。

      3.その他

     

    よろしくお願いします。

    2011年3月2日 12:06

すべての返信

  • 難しい質問ですね。
    ご自身の目標或いはGoalはどこにあるのでしょうか?
    現状ご自身のSkillと仕事で要求されるSkillとすりあわせ、足りないものはなにか分析済みなのでしょうか?

    その辺をもう少し掘り下げてから質問されたほうが、回答し易いです。

    MFCをMasterしたいのでしょうか?
    そうなると、Windows API + C(C++) > MFCの流れが、確実な手段の一つだと思います。
    やはり、基礎がしっかりしていないと先に進んでも厳しいと思います。
    特に不具合等の問題に直面したとき、原因の調査・修正方法の検討を、影響範囲を捉えながら作業することになると思いますが、それをこなすには基礎知識が必須になります。
    遠回りのように見えますが、一番近道だったりします。
    最初のうちはそれがなかなか実感できずに、嫌になることもあるかもしれませんが、非常に有効なご自身への投資です。

    MFCを継続的に使用したいのであれば、何かApplicationをDialog Baseで作ってみては如何ですか?
    あまり、手を広げると収拾がつかなくなることもありますから。
    どのようなApplicationが良いかは、状況が推察できませんから、なんとも言えません。

    2011年3月2日 13:52
  • visual studio 2008 VC++ (MFCダイアログベース)をやっています。仕事の都合で、生まれて初めてやったwindowsプログラミングがこれで、これ以外のwiondowsプログラミングの経験はありません。VC++について、知識の幅を広げたいと思っています。

    何か目的、狙いを定めていませんか?
    それを明確にして、どういったところを伸ばしたいとか考えてみませんか?

    幅を広げたいと思われるのはすばらしいことだと思いますが、正直アドバイスが難しいと思っています。
    がむしゃらにやるのではなく、目的・狙いを定めて、それに近づける小さな目標を立ててこなしていくべきなのかなと感じています。

    たとえば、有名な○○というソフトウェアのクローンを作ってみるとか、こういった日頃手間だと思ってる事柄を地味に解消するためのツールを作ってみるとか。その過程にある必要な技術を調査し、習得し、実装していくことで身についていくかもしれないとも思っていますが、この路線が果たして万人に最適化は何とも言いかねます。


    質問スレッドで解決した場合は、解決の参考になった投稿に対して「回答としてマーク」のボタンを押すことで、同じ問題に遭遇した別のユーザが役立つ投稿を見つけやすくなります。
    2011年3月2日 13:58
    モデレータ
  • kozzさん、ありがとうございます。

    >ご自身の目標或いはGoalはどこにあるのでしょうか?
    >現状ご自身のSkillと仕事で要求されるSkillとすりあわせ、足りないものはなにか分析済みなのでしょうか?

    実は、この投稿をした理由は、おっしゃるとおりのことが発端というか原因なのです。目下、仕事上、VC++から離れることになり、続けるとしたら、「日曜大工」ならぬ、「日曜VC++」ということになってしまいそうです。もともと、MFCはどちらかというと下火になっていきそう(無くならないにせよ)な雰囲気もありますので、これに深入りすることにどこまで価値があるのかも悩みどころです。

    ですので、目標といえば、

    ・今回覚えたMFCのダイアログベースのうわずみを忘れないこと

    ・どうせなら、なんか覚えたい

    というような感じです。

    >どのようなApplicationが良いかは、状況が推察できませんから、なんとも言えません。

    変なこと聞いてすみません。

     

    2011年3月2日 14:22
  • Azuleanさん、ありがとうございます。

    >何か目的、狙いを定めていませんか?
    >それを明確にして、どういったところを伸ばしたいとか考えてみませんか?

    kozzさんへの返信にも書いたのですが、「日曜VC++」になってしまいそうで、目標がなくなっていることが一番の問題といえます。

    なんか目標になりそうなものを探してみます。

    答えようがない質問を投稿してすみません。

    2011年3月2日 14:26
  • >MFCはどちらかというと下火になっていきそう・・・価値があるのかも悩みどころです。
    C# + .NET Frameworkが賑わいを見せている中、気持ちはわかります。
    その価値はどこで見出す(見い出せる)かも考えたほうが良いでしょう。
    今後仕事で利用する可能性があるから、など何かしら動機付けがあれば良いですね。
    それがないのであれば、MFCに拘る理由もあまりないと思います。

    >「日曜VC++」ということになってしまいそうです。
    良いではないですか。
    納期も仕様も費用も自由に決められますから、納得いくまで腰を据えて挑めます。(考え方次第ですね)

    >今回覚えたMFCのダイアログベースのうわずみを忘れないこと
    これを目標とせず目標を立てる際の条件として、もう少し中長期的な視点で目標を立ててみては如何でしょうか。
    それを元に手段に落とし込んでいくと良いでしょうね。
    この段階で相談されると回答し易いかと思います。

    特に大義名分もなく個人の範囲であれば、それこそC# + .NET Frameworkの方が良いような気もしますが、やはりご自身の状況がわからないので、おすすめしかねる次第です。

    周りの人に相談してみては如何でしょうか。

     

    画像を読み込んで表示し、ある程度加工でき印刷できるApplicationなんて面白そうですね。
    USBに接続したCameraやSmart Phone等のDeviceから画像一覧を読み込んで、表示する機能を後から付けたり、拡張するのも良いですね。
    それができたら、画像だけでなく動画も表示できるようにするなど、広がりもありますね。
    これならMFCの方が細かい融通が効きますので、MFCを選択された方が良いでしょう。

    2011年3月2日 15:41
  • いわゆる趣味でプログラミングをやっていて、自分の興味とかそういう物を大事に出来る状況なのか、
    それともプログラミングを仕事にするくらいの勢いなのかでもアプローチは変わりそうです。

    プログラミング環境にお金を掛けられる場合はMFCと言う選択肢も有りだと思いますし、
    それこそ趣味でやるならやってみたい方向に思い切り突っ走ってもOKなんじゃないかと思います。
    お金かけたく無いとなるとMFCの場合は開発環境をそろえるのにそれなりの金額が必要になります。
    VC#だとGUIの開発に関してもタダで手に入るExpressEditionでプログラミング可能です。
    これに対してVC++でMFCだとタダで手に入る環境では無理ですね。
    C++/CLIを使った.NET Frameworkでのプログラミングなら可能ですけれど、
    純粋にVC++で組み上げるのとはやり方が違うのでC++でやりたいのであれば、
    目的に合いません。(C++/CLI と C++ は、別の言語です。)

    ダイアログベースのプログラミングである程度慣れたのであれば、
    私も他の方が書かれているようにWin32APIを使ったMFCのフレームワークに頼らない
    Windowsプログラミングを勉強して見られる事をお勧めします。
    これによってMFCのフレームワークにどれだけ助けられているかを実感できるでしょう。
    MFCを使っておられると言う事でリソースを編集できる環境はお持ちだと思いますので
    色々試して見られると良いかなと思います。


    解決した時は、参考になったレスポンスの所にある[回答としてマーク]ボタンをクリックしてスレッドを締めましょう。
    2011年3月3日 1:11
  • 他のみなさんが仰るとおり、ゴールをどこに置くかで方向性も全く変わってくると思います。
    エンジニアとして今後の方向性を模索しておられるなら、時間があるならぜひ以下の本を読んでみることをお勧めします。

    My Job Went To India オフショア時代のソフトウェア開発者サバイバルガイド

    ページ数はさほど多くはありませんが、非常に考えさせられる内容になってます。
    私もこの本に影響され、フォーラムで積極的に回答したり、各種勉強会にも頻繁に顔を出すようになりました。
    でも残念ながら絶版になったのか、Amazon では中古しか手に入らないようですね。


    ひらぽん http://d.hatena.ne.jp/hilapon/
    2011年3月3日 1:40
  • こんにちは、AnalogTerebi さん。

    MSDN フォーラムのご利用ありがとうございます。オペレーターの山本です。

    ご質問の内容がアプリケーション開発上での問題というより、[全般的な情報交換] が適切かと思いましたので、スレッドの種類を変更させていただきますね。
    よろしくお願いいたします。
                                                                     
    日本マイクロソフト株式会社 フォーラム オペレーター 山本 春海

    2011年3月3日 7:38
  • kozzさん、ありがとうございます。 

    >「日曜VC++」ということになってしまいそうです。
    良いではないですか。
    納期も仕様も費用も自由に決められますから、納得いくまで腰を据えて挑めます。(考え方次第ですね)

     それもそうですね。

    画像を読み込んで表示し、ある程度加工でき印刷できるApplicationなんて面白そうですね。
    USBに接続したCameraやSmart Phone等のDeviceから画像一覧を読み込んで、表示する機能を後から付けたり、拡張するのも良いですね。
    それができたら、画像だけでなく動画も表示できるようにするなど、広がりもありますね。
    これならMFCの方が細かい融通が効きますので、MFCを選択された方が良いでしょう。

     

    いわれてみれば、こういうたぐいのことなら仕事にも生かせるかもしれません。私の主たる仕事は組み込みソフトですが、対象の機器をパソコンをUSBでつないで・・・・なんていうことをやっていますので、市販のカメラやSmart Phoneをつなぐ前にこっちに手を付けたほうがよさそうです。とりあえずUSBを使って何かする方法を覚えておけば、いろいろ使えそうです。

    2011年3月3日 12:01
  • PAITOさん、ありがとうございます。

    いわゆる趣味でプログラミングをやっていて、自分の興味とかそういう物を大事に出来る状況なのか、
    それともプログラミングを仕事にするくらいの勢いなのかでもアプローチは変わりそうです。

      どちらかというと趣味の範疇だと思います。職場で使うものなので仕事で使うことに違いはないのですが、私の場合は組み込みソフトが主たる仕事です。組み込み機器の動作検証など、解析したりするときにパソコンとつないで作業をするときにパソコンのソフトを作れたらいいなと思っています。場合のよっては人(=不特定多数ではなく、社内の関係者)に渡せるような使い勝手の良いソフトを作れたらいいなという思いはあります。そういう意味では、パソコンにつないだ外部との通信データのやり取りはわりとよく使います。 

    ダイアログベースのプログラミングである程度慣れたのであれば、
    私も他の方が書かれているようにWin32APIを使ったMFCのフレームワークに頼らない
    Windowsプログラミングを勉強して見られる事をお勧めします。
    これによってMFCのフレームワークにどれだけ助けられているかを実感できるでしょう。
    MFCを使っておられると言う事でリソースを編集できる環境はお持ちだと思いますので
    色々試して見られると良いかなと思います。

    どうやら、APIのほうに手を広げたほうがよさそうです。

    2011年3月3日 12:07
  • ひらぽんさんありがとうございます。

    他のみなさんが仰るとおり、ゴールをどこに置くかで方向性も全く変わってくると思います。
    エンジニアとして今後の方向性を模索しておられるなら、時間があるならぜひ以下の本を読んでみることをお勧めします。

    これが定められていないのが一番の問題かも知れません。どちらかというと、windowsソフトでバリバリに飯を食うのではなく、組み込みソフトを作っていくうえでその動作検証などの補助的な道具として付き合っていきたいと思っています。

    ご紹介いただいた本も探してみます。

    2011年3月3日 12:09
  • 山本様、こんにちは。

    わかりました。よろしくお願いします。

    2011年3月3日 12:10
  • 例えば質問を書き込んだこのフォーラム、MFCではなくWebページであり、HTMLですよね? C#の話も出てきていますが、プログラムはそこらじゅうにあります。VC++ 2008のMFCを極めたいのかどうか、それとも世の中のトレンドについていきたいのかどうか、だと思います。

    C++だっていつまでも変わらないわけではありません。VC++ 2010ではラムダ式とか新しいものがどんどん入ってきています。

    2011年3月3日 13:02
  • 佐祐理さん、ありがとうございます。 

    例えば質問を書き込んだこのフォーラム、MFCではなくWebページであり、HTMLですよね? C#の話も出てきていますが、プログラムはそこらじゅうにあります。VC++ 2008のMFCを極めたいのかどうか、それとも世の中のトレンドについていきたいのかどうか、だと思います。

    手を広げるよりにMFCや今知っていることを深めたほうがよいのかなという気がしてきました。ただ、極めるといっても私の本業は、あくまで組み込みなので、windowsのプロレベルで言う極める」を目指さなくても良いのですが・・・。 

    C++だっていつまでも変わらないわけではありません。VC++ 2010ではラムダ式とか新しいものがどんどん入ってきています。

    こんなのもあったんですね。2010はまだ使ったことがないので見てませんでした。

    諸行無常というか、風の前の塵、なんというか・・・

    2011年3月4日 13:49
  • まあ、プログラム言語も日進月歩で変化していますし、基本的には機能が拡張される方向での変化なので
    それはそれで歓迎すべき事かと思っています。
    ラムダ式とか最近導入されてきた新しい物は今までC++の不都合を解決しようとしているものですが、
    直近で必要ない機能なら使わなくてもプログラミングはできますし、それを採用するかしないかは
    状況次第で良いと思うのでStep by Stepで進めて行けば良いのではないかと思います。

    取り合えず勉強する範囲として目の前の環境を対象と定めて動くのは発散しない為には必要だと
    思います。その上で定めた環境下である程度の知識を得た後で更に手を広げるかどうかはご自身で
    決めて良い話です。特に趣味の範疇で勉強しようと思っているならそういうスタンスで良いと思います。

    APIで一度組んでおくとWindowsの仕組みが見えてくると思います。
    そうするとMFCを使おうが、.NET Frameworkを使おうが、基本的な仕組みを
    抑えた状態になるので応用が利くと思います。
    そういう意味でWin32APIをお勧めしています。
    Windowsの動作の仕組みを理解できれば、プログラミング言語は道具にすぎませんから。

     


    解決した時は、参考になったレスポンスの所にある[回答としてマーク]ボタンをクリックしてスレッドを締めましょう。
    2011年3月7日 2:22
  • >「日曜VC++」ということになってしまいそうです。
    とありますが、「手軽にちょっとしたアプリを作成したい」というのであれば、MFCや.NETのようなものを活用されると、手軽にいろいろ作れると思いますが、アプリケーションの細かい部分(WinProcだメッセージループだ)といったようなことから、Windows アプリケーションを深く知りたい!というのであればWindows SDKを使った開発を学ばれるのもよいと思います。

    みなさんのおっしゃっていることと重なってしまいますが、結局は「何をしたいか?」だと思います。
    「最新の言語を学びたい」「DirectXでゲームを作りたい」「市販されているXXというソフトのようなものを作りたい」などなど…

    私なんかは、面倒ですが力技でゴリゴリやるのが好きなので、専らWindows SDKでの開発をしています。
    最初にプログラムを始めたきっかけが、友人とのゲームプログラムだったので、当時重くてゲームでは…という理由から、MFCは使わなかった、という経緯もありますが、今はそれでよかったと思っています。

    「VC++を勉強をする」という目的だったとしても、何か完成させる目標を作って、それに対してプログラムを勉強していくと、意欲も上がりますし、よいと思います。

    あまり参考にならないかもしれませんが…^^;

    2011年3月8日 4:21
  •  PATIOさんありがとうございます。 

    返事が遅くなりすみません。

    まあ、プログラム語も日進月歩で変化していますし、基本的には機能が拡張される方向での変化なのでそれはそれで歓迎すべき事かと思っています。

    どうも、その「拡張されるところ」に面喰っている気がします。組み込みソフトは、マイコンCPUの使い方で覚えなければならないことはありますが、言語的にはC言語だけでなんとかなるようなこともあり、別にC言語の文法自体が何か劇的に進化するなんてことはないので、、、

    APIで一度組んでおくとWindowsの仕組みが見えてくると思います。
    そうするとMFCを使おうが、.NET Frameworkを使おうが、基本的な仕組みを
    抑えた状態になるので応用が利くと思います。
    そういう意味でWin32APIをお勧めしています。
    Windowsの動作の仕組みを理解できれば、プログラミング言語は道具にすぎませんから。

    やっぱりそういう方向を向いたほうがよいのかもしれませんね。「visualなんとか」よりも、APIのほうが先かもしれません。時間稼ぎ?すれば「日進月歩」のおかげでAPIなんて知らなくても何とかなる方向に開発環境や言語が発展して行くのかと思ったこともありますが、どうもすぐにはそうなりそうもないですし。。。

     

    2011年3月8日 12:14
  • どらちんさん、ありがとうございます。

    返事が遅くなりすみません。  

    みなさんのおっしゃっていることと重なってしまいますが、結局は「何をしたいか?」だと思います。
    「最新の言語を学びたい」「DirectXでゲームを作りたい」「市販されているXXというソフトのようなものを作りたい」などなど…

     外的要因(外的とはいっても社内ですが)により、突然windowsに引き込まれたかと思ったら、今度は突然、放出され、なんか中途半端だなと思っており、こういう質問を投げてみました。これは逆に言うと、また何時、何を言われる変わらないようなところがあり、仕事に役立つ領域が何なのか、が予想がつかないところが一番の問題です・・・

    私なんかは、面倒ですが力技でゴリゴリやるのが好きなので、専らWindows SDKでの開発をしています。
    最初にプログラムを始めたきっかけが、友人とのゲームプログラムだったので、当時重くてゲームでは…という理由から、MFCは使わなかった、という経緯もありますが、今はそれでよかったと思っています。

    「VC++を勉強をする」という目的だったとしても、何か完成させる目標を作って、それに対してプログラムを勉強していくと、意欲も上がりますし、よいと思います。

     私もどちらかというと「力技でゴリゴリ」が好きなタチです。つい最近まで、マイコン組み込みのC言語(アセンブラ込)ソフトしかやっておらず、これはこれで楽しんでやっていましたので、wiondowsはあまり関心がなかったのが正直なところです。

    2011年3月8日 12:22
  •  やっぱりそういう方向を向いたほうがよいのかもしれませんね。「visualなんとか」よりも、APIのほうが先かもしれません。時間稼ぎ?すれば「日進月歩」のおかげでAPIなんて知らなくても何とかなる方向に開発環境や言語が発展して行くのかと思ったこともありますが、どうもすぐにはそうなりそうもないですし。。。

    現在の開発環境でも凝った事をしないのであれば、与えられたクラスライブラリの組合せレベルでプログラミングする事は可能だと思いますよ。
    Windows標準のコントロールを使い、標準のオペレーションのみに対応していれば良いというアプリなら作成する事自体は可能だと思います。
    内部的な処理の部分に関しては、処理の内容次第なのでどうなるかわかりませんけれど。
    表示を凝ったり、標準には無い便利ではないかと思われるオペレーションを取り入れたりと言った突っ込んだ事をしたいのであれば、
    Windowsの仕組みを知らないと難しいと思います。

    MFC等が提供しているフレームワークの中に踏み込む時にWindowsの仕組みを知っているかどうかは大きく影響します。
    フレームワークを理解した上で諸々の追加ロジックを入れて行く必要がありますから。
    なので、仕組みを知らないで組める深さと言うのがあって、その深さを越えた事をしようとしたら、結局、基本的な知識が必要になると言う事だと思います。
    そのためにはWin32APIで組んで見た方が実感できるし、理解しやすいと私は思っています。


    解決した時は、参考になったレスポンスの所にある[回答としてマーク]ボタンをクリックしてスレッドを締めましょう。
    2011年3月9日 1:18
  • いつもお世話になっております。

    横から失礼します。

    これからは、MFCの内部を知る場合はDirect2Dを知る必要があるのでしょうか?

    (以降、勘違いの可能性ありです)

    と言いますのも、「MFCがDirect2Dに対応」したという記事をどこかで読んだ覚えがあります。

    この「対応」とは、MFCでの描画はDirect2DおよびDirectWriteが用いられるということではないのでしょうか?

    そのため、内部を知るには、Direct2Dに関する知識が必要ではないかという質問です。

     

    2011年3月9日 1:31
  • >「MFCがDirect2Dに対応」したという記事をどこかで読んだ
    [MFC Additions for Visual Studio 2010 SP1]
      http://msdn.microsoft.com/en-us/library/gg482719.aspx

    対応しましたね。

    >この「対応」とは、MFCでの描画はDirect2DおよびDirectWriteが用いられるということではないのでしょうか?
    用いる選択肢もある、ということです。
    従って、従来のHDCベースでの描画も引き続き利用できます。

    >内部を知るには、Direct2Dに関する知識が必要ではないか
    無論Direct2Dを利用するなら知識が必要ですが、Direct2Dを利用しないなら必要ありません。

    2011年3月9日 11:08
  • PATIOさん、ありがとうございます。

    現在の開発環境でも凝った事をしないのであれば、与えられたクラスライブラリの組合せレベルでプログラミングする事は可能だと思いますよ。
    Windows標準のコントロールを使い、標準のオペレーションのみに対応していれば良いというアプリなら作成する事自体は可能だと思います。
    内部的な処理の部分に関しては、処理の内容次第なのでどうなるかわかりませんけれど。
    表示を凝ったり、標準には無い便利ではないかと思われるオペレーションを取り入れたりと言った突っ込んだ事をしたいのであれば、
    Windowsの仕組みを知らないと難しいと思います。

    そうかもしれません。私のレベルでも、ダイアログだけではなんか不便だなぁという思いは無きにしもあらず、、、で、次にどうしようかという思いもあります。で、APIに手を付けたほうがよいかなと思い始めています。  

    MFC等が提供しているフレームワークの中に踏み込む時にWindowsの仕組みを知っているかどうかは大きく影響します。
    フレームワークを理解した上で諸々の追加ロジックを入れて行く必要がありますから。
    なので、仕組みを知らないで組める深さと言うのがあって、その深さを越えた事をしようとしたら、結局、基本的な知識が必要になると言う事だと思います。
    そのためにはWin32APIで組んで見た方が実感できるし、理解しやすいと私は思っています。

     そういえば、ネットでの情報収集をしているとき、APIの情報とMFCの情報が入り乱れて区別がつかず混乱していたことがありました。というか、今でもそういうことがあります。

    msdnのライブラリが、もう少し区別がつきやすい書き方をしてほしい。。。。という個人的希望は差し置いて、プログラミングの実作業以前にライブラリを読むだけでも、「基本的な知識が必要になる」ような気がします。MFCとAPIの別がなく入り乱れている本やホームページも多く、読むのが大変な思いをすることがあります。

    2011年3月9日 11:58
  • Win32APIとMFCを完全に分離できないケースがあるからでしょうね。

    例えばですが、Win32APIを使ってC言語の範疇でGUIのプログラムを組む事は可能です。
    ところがMFCを使ってC++言語でGUIのプログラムを作成する場合、フレームワークの範疇で
    プログラミングする分にはWin32APIのお世話になる事はありませんが、フレームワークでは
    実装されていない部分に踏み込んでしまうと当然の事ながらWin32APIを使わざる得ないケースが
    あります。なので、MFCとWin32APIを完全に分離して考える事はできません。

    あとはそのHPのスタイルと言うか、Win32APIでなれている部分はそちらを使い、
    面倒な部分はMFCで済ませると言うような事をしていれば、入り乱れていると言うような
    状況もありえると思います。実際の話、個人のHPの場合は書いている本人のポリシーも
    あると思いますのでそこで得られた情報にしてもある程度は取捨選択が必要なわけで
    そのためにも基礎的な知識と言うのは必要なんですよね。
    そんなこんなで私個人としては初学者にWebを使った学習は勧めない事にしています。
    少なくとも情報の取捨選択が可能になるまでは入門書等の書籍で勉強した方が無難です。

    Webの情報は体系付けられていないケースも有るので初学者が活用するのは難しいと思います。

    ちなみにですが、
    Win32APIに関してなら、割と有名な「猫でもわかるプログラミング」を参考にされると良いと思いますよ。
    良く整理されているのでわかりやすいと思います。
    必要なら書籍も出ているのでそちらを使う手もあると思います。

     


    解決した時は、参考になったレスポンスの所にある[回答としてマーク]ボタンをクリックしてスレッドを締めましょう。
    2011年3月10日 0:11
  • kozzさん、返信ありがとうございます。

    MFCを利用する場合は、内部を知っておく必要があるようですし、Direct2Dの普及にはもう少し時間がかかるようですね。

    関係ない話ですが、私自身は、Direct2DとWinAPIを使用しております。

    Direct2Dに足りないのは、テキストエディタのウィンドウ?システム?クラスだけじゃないかと思っております(GDIでなく)。Windows XP環境では使えないのが残念ですが。(CreateWindowExW(0, L"" ← この部分)

    といっても、Direct2Dは描画コンポーネントですので期待するものではない気もしていますが。

    2011年3月10日 1:56