アプリＡからアプリＢはどのようにして表示させていますか？

あ～もしかして、Ａを閉じてもＢを表示しておきたいということでしょうか？
おそらくできないので、Ｂを表示するときに非表示にするぐらいしかないでしょう。

類似スレ(C#だけど)
http://bbs.wankuma.com/index.cgi?mode=al2&namber=1322

>アプリＡからアプリＢはどのようにして表示させていますか？

System.Diagnostics.Process を使用してアプリＢを起動させています。

>あ～もしかして、Ａを閉じてもＢを表示しておきたいということでしょうか？
>おそらくできないので、Ｂを表示するときに非表示にするぐらいしかないでしょう。

そのとおりです。Ｂは表示したままにしておきたいのです。
大方はうまく動作しているのですが、希にＡが実行中のままになるので
フォームクローズのメッセージ処理がうまくいってないのかなと思ったのですが・・・。

Blueさんが示してくれたスレとは少しちがいます。

私の説明があいまいでした。
アプリとは別プログラムのことです。
同プログラム内の別フォームではありません。

プロセスがアイドル状態になるまで待機してから終了するのはどうでしょうか？

System::Diagnostics::Process^ p = System::Diagnostics::Process::Start(XXXX);
p->WaitForInputIdle();

p->Close();
delete p;

// 一応タイマーもとめたほうがよさそう
this->Timer1->Stop();

this->Close();

要するに別アプリを起動して自分は終了としたいわけですよね。

通常の起動では全く起きないのでしょうか？
起きるのであれば、デバッガで追いかける事も可能かなと。

「スタートアップに設定している」場合にしか起きないのであれば、
デバッガで追いかけるのは難しいので動作状態をログファイルに書き出すようにして
何処まで動作しているか確認するくらいでしょうか。
残っているウインドウはまだ反応しますか？
単純に画面の更新がうまくいっていないとかそういう事ではなくて
プロセスが残っていると言う事は確認済みでしょうか。

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

検証してみましたが、何せ希に出る現象なものでこれでOKかどうかはまだわかりません。
引き続き検証してみます。

で、もしこれでうまくいったという仮定の上での質問なんですが、
プロセスがアイドル状態でない状態でフォームクローズした場合、
メッセージキューにたまったまま処理されない現象がおきる場合がある・・・
ということですかねぇ。
Application::DoEvents()でメッセージを実行させてしまうという手はどうなのでしょうか。

ＰＡＴＩＯさん、ありがとうございます。

>要するに別アプリを起動して自分は終了としたいわけですよね。

>通常の起動では全く起きないのでしょうか？
>起きるのであれば、デバッガで追いかける事も可能かなと。

今までで、通常の起動では同様の現象は確認されていません。

>残っているウインドウはまだ反応しますか？
>単純に画面の更新がうまくいっていないとかそういう事ではなくて
>プロセスが残っていると言う事は確認済みでしょうか。

反応していません。プロセスも残っています。

> で、もしこれでうまくいったという仮定の上での質問なんですが、
> プロセスがアイドル状態でない状態でフォームクローズした場合、
> メッセージキューにたまったまま処理されない現象がおきる場合がある・・・
> ということですかねぇ。

スタートアップ時にしか起こらないと言う話なので
他の常駐プログラムとかサービス等の起動と重なった時に
起こっているんでしょうかねぇ。
システムが長時間ビジーになるような状況を作って
その状態で起動してみると再現するかもしれませんね。
何処まで動いて止まっているのかが良く分からないので
何とも言えない気もしますけれど。

>システムが長時間ビジーになるような状況を作って
>その状態で起動してみると再現するかもしれませんね。

試してみましたが、これまでの検証では再現しませんでした。
どうにかこうにかスレッドの合間を縫って処理しているみたいです。

ここで疑問なのですが、スタートアップでアプリを起動するとき、
.NetFrameWorkが作動する環境(CLRでしたかね。)は整っている状態なのでしょうか。

私は.NET Frameworkもライブラリの一種と認識しているので
基本的に必要になれば、ロードされる物だと思っています。
Windows XPの場合、.NET Frameworkを必要とするソフトが
事前に動いていない限りはロードされていない状態なので
ららんさんのアプリが起動後初めて.NET Frameworkを使用するソフトだとすると
その時点で初めてメモリ上にロードされるのでは無いかと思います。
Vistaの場合は、OSそのものが.NET Frameworkを前提に動いていると
思いますので多分、起動した時点でロードされているのではないでしょうか。

少なくとも.NET Frameworkを必要とするソフトが必要なソフトが起動されれば、
そのための準備を整えてから実際のソフトは動き出すと思います。
ただ、スタートアップ中に.NET Frameworkが正常に起動する事が保障できるのか
と言う話になるとMSDNできっちり調べてみるか、Microsoftに問い合わせるか
しないとわからないのではないかなと思います。

条件を合わせるのであれば、XP上で.NET Frameworkを一回も
動かしていない状態で.NET Frameworkを使用しないソフトで
高負荷の状態を作り出してみると言うのもありかもしれません。

ＰＡＴＩＯさん、ありがとうございます。

>私は.NET Frameworkもライブラリの一種と認識しているので
>基本的に必要になれば、ロードされる物だと思っています。

調べてみましたら、そのとおりでした。
今更ながら自分の勉強不足を嘆くばかりです。

で、解決しましたのでご報告します。
結局はスタートアップ時のリソース不足のようです。
一番基本的なことでしたが、たどり着くのに時間がかかりました。

皆様のご協力に深く感謝いたします。ありがとう。