C++はただの文法でしかありません
C++の入門書を読むだけでなくて、イベントドリブンとかWindowsプログラミングの本を読
まれたほうがいいのではないでしょうか？
winmain(){}
ってのがありますが、そこから追っていくのは・・・きっと無理です

え～いちさん、ありがとうございます。

なるほど、イベントドリブンやWindowsプログラミングの本ですね。
何冊かC++の本を読んだのですが、どこにも知りたいことがないので
何から調べたらよいのか途方にくれていました。

さっそく、調べてみます。

winmain(){}　から始まるというのはわかったのですが、これはVisual Studioで自動的
に作成されているので、そこから追っていったのでは、いつになることやら・・と思っ
ておりました。

ありがとうございました。

MFCの何のプログラムのコードを追うつもりでしょうか？

たとえば、SDIであれば、WinMainは隠蔽されているし、見たところで分からないところ
が
多いので、CXXXApp::InitInstanceあたりから見ていたほうが良いです。

トレースしたいところの関数の先頭にブレイクポイントを張って、
デバッグ実行して、ブレイクしたところからステップ実行するのが普通なんじゃないか
なぁと思います。

Blueさん、ありがとうございます。

CXXXApp::InitInstanceから追って見てみたのですが、
画面が表示されるところまでで終わっています。

実際には、表示された画面のボタンをクリックし、次の処理・・となるので
InitInstanceというのはこういうものなのかな・・とも思ったのですが
それで考え方があっているのかどうかがどうにもわからず、質問をさせていただきまし
た。

デバッグ実行から、ステップ実行ですね。順に追っていってみます。
ありがとうございます。

VCについて、右も左もまったく解らない頃、
「ボタン押したら、エディットに数値表示」って課題で
数値表示しないバグ追跡で、OnClickから延々とステップINして
「これ、どこで数値表示してんだ？」と一日悩んだ記憶が・・・。
なつかしいｗ

駄レスすみません（＿＿）

プロジェクトの全ファイルの全関数に
ブレークポイントを設定するのがよいかも。

>実際には、表示された画面のボタンをクリックし、次の処理・・となるので
リソ－ス編集画面上で実際に知りたい処理のボタンをクリックすると処理内容が
表示される場合があります。

aさん、まさに私の今の状態です・・！
わたしも早く、なつかしいと思えるように
がんばりたいと思います。

たいちうさん、ありがとうございます。

Blueさんのアドバイスのあとに
ところどころブレークポイントを設定してみたところ、
たいちうさんのアドバイスと同じことをしてみようと
思いつきました。
ところどころでは、どこからそこへいったのかが
わからずで・・！

こつこつが大切ですね。
ありがとうございます。

ITOさん

そうなんですか！
ヘルプをF1で表示できることは知っていたのですが、
現状ではヘルプを読んでもどうも理解力が不足しているようで・・

今後、よく見てみます。
ありがとうございます。

書籍などの話も良いのですが、結構皆さんからのアドバイスは闇雲な
ものでしかありません

理由は、開発環境のバージョン情報が提示されていないためです

同じVisual　Studio　でも「２００３」や「２００５」やらそれなりに名称が
あります
それぞれ、統合環境のGUIも違います

バージョン情報がわかれば、具体的書籍名や、画面操作について
もう少し詳しく、アドバイス頂けるのではないでしょうか？

woodさん、そうですね。

使用しているVisual Studioは２００５です。

書籍は何冊か読みましたが、C++入門やVC＋＋入門というようなものです。
（すみません。今、手元になく具体的に書籍名がわかりません）

何かアドバイスなどあれば、よろしくお願いします。

>CXXXApp::InitInstanceから追って見てみたのですが、
>画面が表示されるところまでで終わっています。
この文章から推測するに、
CとC++の違いとか、VCの操作方法といったことよりも、
ウィンドウズアプリケーションの動きがまだ理解されてないだけではないでしょうか。

もし、そうならば・・・ということで以下つづけます。

MFCで開発されたWinアプリを調べるとき
開始から順におっていくという方法にあまり意味がありません。

簡略ですが
①：アプリケーション開始
②：メモリ確保とかUIとかを準備をする
③：OSからの指示（メッセージ）を待ち続ける
④：指示がきたら、それに対応する関数を呼び出す
⑤：対応する関数で処理を行い、その後③に戻る

こんな感じになっています。
たいてい、Winアプリプログラマーが気にするのは②、⑤だけで十分です。
それゆえ、①③④は、隠蔽されていて、
開始から順におっていっても③の隠蔽部分に突入してしまうのです

>画面が表示されるところまでで終わっています。
これは、終わってるというよりも、③のところに進んでいるのです。

こんな動きをするので、他の方のつくったWinアプリの動作をおっかけたい場合は、
A:調べたい動作を一個に絞る。
B:動作のきっかけ（決められた時間になった、ユーザがキーを押したなど）を調べる
C:きっかけに対応する関数に書かれている内容を調べる
という流れになります。

え～いちさんのおっしゃってるような本をよめば、
もっと詳しく正確なことが載ってるはずですし
①～⑤を自作する過程もあるはず。
今後もMFCを使うとしても、全部自作を一回やっておいたほうが絶対にいいです。

＃と、ここまでかいておいて大間違いがあったらどうしよう・・・

ひとつだけ書くとしたら、WindowsのGUIを使ったプログラミングをする場合、
イベントドリブンの考え方は必須になると言う事と、
mainから始まってメインで終わるコンソールのプログラムとは概念の部分が
かなり変わってくるのであまりコンソールのプログラムと対比して考えない方が
良いかなと言う所でしょうか。
むしろ、まったく新しい概念を勉強するつもりの方がすんなり行きそうです。
C言語の知識があるのであれば、Win32APIでWindowsの仕組みを理解しつつ、
イベントドリブンの動きも合わせて勉強した方が良いかもしれません。
MFCにしても結局はWin32APIでやっていた事をクラスライブラリ化しているだけなので。