>②③の追求・解決は、何度も言いますが、無理です。
無理だと思ってはいけないと思います。
個人のフリーソフトに時間的制限はないのでいくらでも出来るはずですね。

> 成功です！
> これでフリーソフトを作り直します。
Ｌｈａｃａ、秀丸で行っていますが、別系統のソフトにしてバ－ジョンアップ
したほうがいいですね。
「よかったら換えて使ってみてください」
てなかんじでどうですか。
今までのは残しておいたほうがいいですね。
ユーザーがびっくりします。

> ですが、このソフトは趣味で作っていますので、FormViewの切り替えの方
> がスマートだと思った今、これで作りたくてしょうがありません。(^o^)
趣味だという考え方はまずいですね。いくらフリ－でも配布してかつユーザーが使って
いるのですからただスマートだからだけの意味での改版はまずいです。

なんでこんなに質問者を追い詰めてんだろうか？

ネットの向こう側の環境でしか再現できない状況に対し
これ以上の「原因追求」の方法を教えてあげればいいのに・・・

ryo さん、応援有り難うございます。

ここの返答数が現在32件。
移動する前の「Programming Library 」での書き込み数が35+6=41件。
合計73件。
ギネスブックに載らないかナ (^_^)
楽しんでいます。

今回の場合は、個人がその個人の責任範囲でやっていることなので
ご本人の判断で良いと思いますよ。
何処まで責任を持つかまで含めてが開発ですし。

で、色んな意見はあって良いと思いますし、
ITOさんの考え方もほんちゃんさんの考え方もあってよいのでは？
その人のそのソフトに対するスタンスですから最後に決めるのは
御本人ですからね。

で、
> なんでこんなに質問者を追い詰めてんだろうか？
と取るかどうかもまた御本人しだいでしょう。
意見として書き込む分には問題ないと思いますよ。
ITOさんの意見にしてもそうしろとは書いていないです。
そう思うと書いてあるとは思いますけれど。

>>②③の追求・解決は、何度も言いますが、無理です。
>無理だと思ってはいけないと思います。
>個人のフリーソフトに時間的制限はないのでいくらでも出来るはずですね。
ほんちゃんさんの時間的制約はないとしても
②の問題はユーザーさんに協力をしてもらい続けないといけないので
「いくらでも出来るはず」は違うと思います

PATIOさん有難うございます。

>なんでこんなに質問者を追い詰めてんだろうか？
なんか、「フリーソフトだからいいじゃん。」ってかんじがしたもので
つい意見してしまいました。
作るほうも使うほうも楽しんでもらわないと作っているかいがないと
思います。
いつまでも作ってよかったと思ってほしいです。

ほんちゃん さんへ。
アプリケーションを終了してもプロセス・タブから消えない状態が
再現できました。下の方法なら必ずプロセス・タブに残ります。
※こちらの環境は Windows XP Home SP2、VC2003 SDK(非MFC)です。

プロシージャを次のようにするとプロセス・タブに残ります。
LRESULT CALLBACK mainWindowProc( HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM
lParam )
{
switch ( uMsg ){
case WM_CREATE:
/* 何かの処理 */
break;
case WM_DESTROY:
/* 何かの処理 */
break;
default:return DefWindowProc( hWnd, uMsg, wParam, lParam );
}
return 0;
}

通常 WM_DESTROY メッセージで PostQuitMessage( 0 );を記述します。
でも PostQuitMessage( 0 ); を記述しないとアプリケーション・タブからは
消え(ウインドウも消える)、プロセス・タブには確実に残ります。

MFCには詳しくありませんが、同様な理由でプロセス・タブから消えない状態が
出来上がっているのかもしれません。もう一度ソースを調べてみて下さい。

あと興味がある方は一度テストしてみて下さい。
たまたま僕の環境だけで再現できているかどうか
それともすべての環境で再現できるのか。
僕は興味があったので書き込んでみました。

ウィンドウが消えるのとプログラムが終了するのはイコールじゃないからね。

>>金魚ちゃん さん

これは見当違いでしょ

> ウィンドウが消えるのとプログラムが終了するのはイコールじゃないからね。
イコールとは言っていないんですけど。
ウインドウは消えるけどプログラムがプロセス・タブに残ります。
だからプログラムが終了しなかった現象を再現できた。
と書き込んだのですが…。

> これは見当違いでしょ
こちらも僕の書き方が悪いせいか伝わらなかったようです。
プログラムはメモリ上(プロセス・タブ)に残っています。
もちろんウインドウは消えているので終了したように見えますが…。

僕の環境だけでしょうか？
wclrp ( 'o') さん、Tさんの環境ではどうですか？

もう少し分かりやすく書きます。

LRESULT CALLBACK mainWindowProc( HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM
lParam )
{
switch ( uMsg ){
case WM_CREATE:

break;
case WM_DESTROY:

break;
default:return DefWindowProc( hWnd, uMsg, wParam, lParam );
}
return 0;
}
この単純なプロシージャでプロセス・タブに残る現象が再現できました。

> これは見当違いでしょ
本当に見当違いでしょうか？
こちらの環境ではタスクマネージャのアプリケーション・タブからは消え、
プロセス・タブにはプログラムがまだ残っています。
何度も確認しました。

別に間違っているって指摘したわけじゃないけど。

関係あるかどうかは私にはわかりません。

MFCではプログラマがPostQuitMessageを記述しなくても
自分がメインウィンドウのときPostQuitMessageを呼び出す処理がすでにあったはず。
//面倒なのでそのソースは探しません。

さっき思ったんだけどPostQuitMessageを呼び出さないと全ての環境で
プロセス・タブにプログラムが残っちゃうよね。多分？

似たような動作を再現できたと思ったけど見当違いだったようです。
失礼しました。

　よくある話が、通信やファイルＩ/Ｏを同期モードで処理しているとき
タイムアウトの設定を誤って処理が残ってしまうことですね。
　ぼくは、このごろ通信は非同期モードでフラグでWaitForSingleObjectのループから
抜け出すようにしてますね。

> さっき思ったんだけどPostQuitMessageを呼び出さないと全ての環境で
> プロセス・タブにプログラムが残っちゃうよね。

「WM_CLOSE」や「WM_DESTROY」（特にWM_DESTROY」）で上の同期モードから
抜けるのを待っていると金魚ちゃん さんのいっている現象が当たるか知れないですね。
どうしても同期モードで行いたいならタイムアウトの設定を厳密に行うのと、
同期モードの処理をスレッドで行い、指定時間に復帰しなければ「TerminateThread」等
で強制終了させるか（マイクロソフトはあまり推奨していない。）を行うかですね。

　タイマールーチン等で同期モード等の無限ループに入ってしまった場合は、
例外が発生しますね。