C# と VB.NET の質問掲示板

ASP.NET、C++/CLI、Java 何でもどうぞ

C# と VB.NET の入門サイト

Re[18]: VistaとWaitForSingleObjectについて

(過去ログ 76 を表示中)

[トピック内 25 記事 (1 - 20 表示)]　 << 0 | 1 >>

■44696 / inTopicNo.1)

　VistaとWaitForSingleObjectについて

▼■

□投稿者/ kashi (1回)-(2009/12/16(Wed) 10:44:10)

分類:[C/C++]　

2009/12/16(Wed) 10:45:36 編集(投稿者)

VC++6.0で開発したGUIアプリ（以後、親画面）からCreateProcessを使用し、
VBで作成したEXE（以後、子画面）を起動しています。
起動させた後、親画面ではWaitForSingleObjectを使用して同期させています。
INFINITEを引数にしている為、子画面を閉じるまで親画面はずっと「待ち」の状態になります。

今までWin2000やXPでは親画面が「待ち」の状態で親画面をクリックしても何の反応もなかったり、
ホワイトアウトしたりとある意味固まった状態であったので使用ユーザとしては
特にアプリケーション的には問題はなかったのですが、
Vistaで同じ事をしたところ「**** MFC アプリケーションは応答していません」と
ダイアログが出てきてしまいます。Vistaは私自身あまり詳しくないのですがフリーズ回避の
機能が向上していると聞いた事があり、このダイアログもそのせいで表示されたんだと思いますが、
アプリケーションを終了する事が出来てしまう為、業務アプリケーションとしてはよろしくなく、
このダイアログを表示させたくないのですが可能でしょうか？
または応答していないのではなく子画面を待っているという意味合いにする方法はありますでしょうか？

引用返信 編集キー/

■44698 / inTopicNo.2)

　Re[1]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ 魔界の仮面弁士 (1429回)-(2009/12/16(Wed) 11:02:56)

■No44696 (kashi さん) に返信
> 起動させた後、親画面ではWaitForSingleObjectを使用して同期させています。
下記が参考になるかもしれません。
http://bbs.wankuma.com/index.cgi?mode=al2&namber=16261&KLOG=33

> Vistaで同じ事をしたところ「**** MFC アプリケーションは応答していません」と
待機中であっても、メインスレッドはメッセージに応答できるようにしておく必要があるかと思います。

引用返信 編集キー/

■44701 / inTopicNo.3)

　Re[2]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ kashi (2回)-(2009/12/16(Wed) 12:01:50)

2009/12/16(Wed) 12:08:57 編集(投稿者)

■No44698 (魔界の仮面弁士さん) に返信

>>起動させた後、親画面ではWaitForSingleObjectを使用して同期させています。
> 下記が参考になるかもしれません。
> http://bbs.wankuma.com/index.cgi?mode=al2&namber=16261&KLOG=33

返信ありがとうございます。
リンクを見ました。
方法が３つほどあるようですが、

よく整理して考えたのですが、目的は子画面の２重起動防止にあります。
今のアプリケーションは仮にWaitForSingleObjectをコメントアウトすると親画面
に制御が戻る分、子画面が立ち上がっていてもさらに子画面を起動することができます。
（メニューやボタンが押せる為）
やりたい事は、子画面を起動したら親画面のボタン（メニュー）を無効にして、
子画面が終了したら親画面のボタン（メニュー）を有効にする。
ということです。

これを踏まえるとどれが一番最適なのでしょう？または他の方法でさらに最適な方法があるのでしょうか？

あと「タイマーイベントで～」という方式が一番簡単かつ私の用件に一番合致しそうにみえますが、
「割と楽な実装としては、タイマーで定期的にWaitForSingleObject か GetExitCodeProcess を呼び出すかになりますね。」
は
０．WaitForSingleObjectはコメントアウト。
１．ボタン（メニュー）を無効化にする。
２．CreateProcess実行
３．タイマーイベントで定期的にGetExitCodeProcessを発行し子画面の状態をチェック。
４．終了していたらボタン（メニュー）を有効化にする。
という解釈でよいのですかね。
「タイマーで定期的にWaitForSingleObjectを呼び出す」ってイメージが沸かなかったもので・・・

>>Vistaで同じ事をしたところ「**** MFC アプリケーションは応答していません」と
> 待機中であっても、メインスレッドはメッセージに応答できるようにしておく必要があるかと思います。

という事は元々のプログラムに問題があるという事ですね・・・私が作ったわけではないのですが。
ちなみにCreateProcessやWaitForSingleObjectをcallしている部分はアプリの共通DLLでCのソースで書かれています。

引用返信 編集キー/

■44702 / inTopicNo.4)

　Re[3]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ aetos (206回)-(2009/12/16(Wed) 12:45:35)

■No44701 (kashi さん) に返信
> 「タイマーで定期的にWaitForSingleObjectを呼び出す」ってイメージが沸かなかったもので・・・

WaitForSingleObject の使い方の応用ですが、タイムアウト時間に 0 を指定することで、対象プロセスが実行中か否かを即座に調べることができます。
WAIT_TIMEOUT_0 が返れば実行中です。
GetExitCodeProcess よりきれいな方法だと思います。

引用返信 編集キー/

■44703 / inTopicNo.5)

　Re[4]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ aetos (207回)-(2009/12/16(Wed) 12:51:39)

■No44702 (aetos さん) に返信
> ■No44701 (kashi さん) に返信
>>「タイマーで定期的にWaitForSingleObjectを呼び出す」ってイメージが沸かなかったもので・・・
>
> WaitForSingleObject の使い方の応用ですが、タイムアウト時間に 0 を指定することで、対象プロセスが実行中か否かを即座に調べることができます。
> WAIT_TIMEOUT_0 が返れば実行中です。
> GetExitCodeProcess よりきれいな方法だと思います。

あるいは、MsgWaitForMultipleObjectsEx を使った方がいいのかも。

引用返信 編集キー/

■44705 / inTopicNo.6)

　Re[3]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ はつね (1142回)-(2009/12/16(Wed) 13:18:04)

■No44701 (kashi さん) に返信
> よく整理して考えたのですが、目的は子画面の２重起動防止にあります。

子画面って別EXEなんですよね？
親画面で制御するんじゃなくて子画面のEXEに二重起動防止を組み込まないとだめなんじゃ？

> 今のアプリケーションは仮にWaitForSingleObjectをコメントアウトすると親画面
> に制御が戻る分、子画面が立ち上がっていてもさらに子画面を起動することができます。

WaitForSingleObjectを親画面で使うときは、二重起動ではなくて子画面EXEが終了する
まで親画面を動かしたくないときに使います。目的と実現方法にギャップがあるのでは？

引用返信 編集キー/

■44706 / inTopicNo.7)

　Re[4]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ 774RR (442回)-(2009/12/16(Wed) 13:42:29)

ボタンのハンドラの中で WaitFor... するとそこで処理がブロックするから
結果的に同一ボタンを押す処理が２回走らない＝二重起動防止になっている
っつーことだけですよね。

ボタンを EnableWindow(FALSE) することで無効にすれば、
やはり同一ボタンを押す処理が２回走らない＝二重起動防止になっている
わけで。

真に二重起動防止が必要なら子画面 EXE のほうに機能が必要には御意。

引用返信 編集キー/

■44708 / inTopicNo.8)

　Re[5]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ kashi (3回)-(2009/12/16(Wed) 13:48:46)

■No44703 (aetos さん) に返信
> ■No44702 (aetos さん) に返信
>>■No44701 (kashi さん) に返信
> >>「タイマーで定期的にWaitForSingleObjectを呼び出す」ってイメージが沸かなかったもので・・・
>>
>>WaitForSingleObject の使い方の応用ですが、タイムアウト時間に 0 を指定することで、対象プロセスが実行中か否かを即座に調べることができます。
>>WAIT_TIMEOUT_0 が返れば実行中です。
>>GetExitCodeProcess よりきれいな方法だと思います。
>
> あるいは、MsgWaitForMultipleObjectsEx を使った方がいいのかも。

なるほど・・・なんとなくイメージが掴めました。

引用返信 編集キー/

■44709 / inTopicNo.9)

　Re[4]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ kashi (4回)-(2009/12/16(Wed) 13:56:54)

■No44705 (はつねさん) に返信
> ■No44701 (kashi さん) に返信
>>よく整理して考えたのですが、目的は子画面の２重起動防止にあります。
>
> 子画面って別EXEなんですよね？
> 親画面で制御するんじゃなくて子画面のEXEに二重起動防止を組み込まないとだめなんじゃ？

そうです。VBで出来てる別EXEです。
確かに起動される側に入れるのは私も承知しています。
ただ親画面はメニューのみでメニューから呼ばれる画面が100画面以上あった場合
そのうち1画面でも子画面を起動したら他は画面起動しなくていいんです。
だからメニューを無効化する方が100画面に手を加える工数よりは少ないと思ったのですが。

>>今のアプリケーションは仮にWaitForSingleObjectをコメントアウトすると親画面
>>に制御が戻る分、子画面が立ち上がっていてもさらに子画面を起動することができます。
>
> WaitForSingleObjectを親画面で使うときは、二重起動ではなくて子画面EXEが終了する
> まで親画面を動かしたくないときに使います。目的と実現方法にギャップがあるのでは？

親画面を動かせない＝子画面が起動できない　で２重起動防止になっていませか？

引用返信 編集キー/

■44710 / inTopicNo.10)

　Re[5]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ kashi (5回)-(2009/12/16(Wed) 14:00:52)

2009/12/16(Wed) 14:06:45 編集(投稿者)

■No44706 (774RR さん) に返信
> ボタンのハンドラの中で WaitFor... するとそこで処理がブロックするから
> 結果的に同一ボタンを押す処理が２回走らない＝二重起動防止になっている
> っつーことだけですよね。

そうです。

> ボタンを EnableWindow(FALSE) することで無効にすれば、
> やはり同一ボタンを押す処理が２回走らない＝二重起動防止になっている
> わけで。
>
> 真に二重起動防止が必要なら子画面 EXE のほうに機能が必要には御意。

親1:子100の修正でどちらを工数採用するかは目に見えてしまっているわけで・・・
しかもすでに稼動しているアプリのVista対応なので今回の対応から入った私は
どうすることもできず・・・です。

別に応答なしになってたって別に今までもWin2000やXPで利用者がそれでいいって
言ってたからいいんですけどVistaになって「応答していません」ダイアログが
出てきちゃうのが問題でしかもそこからプログラム終了できちゃうのが
システム的に問題があるんです。
Vistaの設定かなんかで出ないようにできればそれだけで終わりなんですけどね・・・

引用返信 編集キー/

■44712 / inTopicNo.11)

　Re[5]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ はつね (1143回)-(2009/12/16(Wed) 14:25:24)

■No44709 (kashi さん) に返信
>>WaitForSingleObjectを親画面で使うときは、二重起動ではなくて子画面EXEが終了する
>>まで親画面を動かしたくないときに使います。目的と実現方法にギャップがあるのでは？
>
> 親画面を動かせない＝子画面が起動できない　で２重起動防止になっていませか？

子画面EXEを事前に直接起動されちゃっていたり、親画面から呼ばれているのにEXEを直接起動
したりできるので二重起動防止という意味では破綻しているかと。

しかも、子画面EXE側での二重起動判定なんて、VB(VB6ですよね？)でつくっているなら
App.PrevInstance の判定だけでできるのにね。

引用返信 編集キー/

■44713 / inTopicNo.12)

　Re[6]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ とっちゃん (440回)-(2009/12/16(Wed) 14:44:47)

■No44708 (kashi さん) に返信
> >>WaitForSingleObject の使い方の応用ですが、タイムアウト時間に 0 を指定することで、対象プロセスが実行中か否かを即座に調べることができます。
> >>WAIT_TIMEOUT_0 が返れば実行中です。
> >>GetExitCodeProcess よりきれいな方法だと思います。
>>
>>あるいは、MsgWaitForMultipleObjectsEx を使った方がいいのかも。
>
> なるほど・・・なんとなくイメージが掴めました。
>
ここにぶら下げておくかな。二重起動についてはとりあえず除外...

どのパターンでやる場合でも...
ボタンハンドラの最初で
親画面EXEのメインウィンドウを無効化する(AfxGetMainWnd()->EnableWindow(FALSE)など)*1
子画面EXEを起動する(CreateProcessなど)*2

1.タイマーピークする場合
SetTimer でタイマーを発動する(0.2秒～0.5秒くらいの間隔で呼び出す)＜ウィンドウは何でもよい
タイマーハンドラでは
GetExitCodeProcess で戻り値を取得する(STILL_ACTIVEなら実行中)*2のプロセスハンドルを対象とする
処理が終わっていたら、タイマーを終了し、親画面のメインウィンドウ(*1)をEnableWindow(TRUE)する
戻り値は一切必要ないのであれば　WaitForSingleObject(...,0) == WAIT_TIMEOUT でも問題ありません。

2.MsgWaitForMultipleObjects の場合
MsgWaitForMutipleObjects( 1, &(*2のハンドル), FALSE, INFINITE, QS_ALLEVENTS );を行う。
WAIT_OBJECT_0+1 なら、何かメッセージが来たとして
メッセージが来た場合は、メッセージが空になるまでメッセージポンプを回す(MFCなら、while(PeekMessage(...,PM_NOREMOVE)){ theApp.PumpMessage()})
戻り値が、WAIT_OBJECT_0 なら、子画面終了なので、ループを抜けクローズ処理をする(1と段取り的にはほぼ同じ)
EXEが終了してなければ、MsgWaitFor... に戻る

と、こんな感じです。
１の場合、今までの処理とは異なり複数のメッセージに分断されるためちょっと面倒かもしれません。
２の場合は、現在 WaitForSingleObject になっている部分を MsgWaitForMultipleObjects のループに変える形になります(関数に切り出してもいいです)。
処理的には２のほうが変更箇所の範囲も波及エリアも少ないです。
が、ここに書いてある情報＋MSDNライブラリでコーディングできないようなら１で作成することをお勧めします。

どちらの場合も、重要なポイントは、親画面のメインウィンドウ(モーダルダイアログから呼ばれているのならそのモーダルダイアログのウィンドウ)を EnableWindow( FALSE )として、無効化しておくことです。
これを行うことにより、メニューや終了コマンドなど一切受け付けなくなります(ダイアログ内の全部の子コントロール類も含む)。

引用返信 編集キー/

■44720 / inTopicNo.13)

　Re[6]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ kashi (6回)-(2009/12/16(Wed) 16:11:55)

■No44712 (はつねさん) に返信
> ■No44709 (kashi さん) に返信
> >>WaitForSingleObjectを親画面で使うときは、二重起動ではなくて子画面EXEが終了する
> >>まで親画面を動かしたくないときに使います。目的と実現方法にギャップがあるのでは？
>>
>>親画面を動かせない＝子画面が起動できない　で２重起動防止になっていませか？
>
> 子画面EXEを事前に直接起動されちゃっていたり、親画面から呼ばれているのにEXEを直接起動
> したりできるので二重起動防止という意味では破綻しているかと。
>
> しかも、子画面EXE側での二重起動判定なんて、VB(VB6ですよね？)でつくっているなら
> App.PrevInstance の判定だけでできるのにね。

上記のケースは環境＆システム的に規制がかかっている為大丈夫なんですよ。
だからこそ今までWaitForSingleObjectで親画面に制御が戻ってこなければ親画面は
何も出来ないからそれでよかったと・・・
ただ１００ある子画面（EXE）のどれか１つでも立ち上がっていたなら他は一切起動できないって
用件であるのでそれでよかったかと。PrevInstanceってあくまで自分自身だけですよね。

引用返信 編集キー/

■44722 / inTopicNo.14)

　Re[7]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ kashi (7回)-(2009/12/16(Wed) 16:21:24)

■No44713 (とっちゃんさん) に返信
> ■No44708 (kashi さん) に返信
>>>>WaitForSingleObject の使い方の応用ですが、タイムアウト時間に 0 を指定することで、対象プロセスが実行中か否かを即座に調べることができます。
>>>>WAIT_TIMEOUT_0 が返れば実行中です。
>>>>GetExitCodeProcess よりきれいな方法だと思います。
> >>
> >>あるいは、MsgWaitForMultipleObjectsEx を使った方がいいのかも。
>>
>>なるほど・・・なんとなくイメージが掴めました。
>>
> ここにぶら下げておくかな。二重起動についてはとりあえず除外...
>
> どのパターンでやる場合でも...
> ボタンハンドラの最初で
> 親画面EXEのメインウィンドウを無効化する(AfxGetMainWnd()->EnableWindow(FALSE)など)*1
> 子画面EXEを起動する(CreateProcessなど)*2
>
> 1.タイマーピークする場合
> SetTimer でタイマーを発動する(0.2秒～0.5秒くらいの間隔で呼び出す)＜ウィンドウは何でもよい
> タイマーハンドラでは
> GetExitCodeProcess で戻り値を取得する(STILL_ACTIVEなら実行中)*2のプロセスハンドルを対象とする
> 処理が終わっていたら、タイマーを終了し、親画面のメインウィンドウ(*1)をEnableWindow(TRUE)する
> 戻り値は一切必要ないのであれば　WaitForSingleObject(...,0) == WAIT_TIMEOUT でも問題ありません。
>
> 2.MsgWaitForMultipleObjects の場合
> MsgWaitForMutipleObjects( 1, &(*2のハンドル), FALSE, INFINITE, QS_ALLEVENTS );を行う。
> WAIT_OBJECT_0+1 なら、何かメッセージが来たとして
> メッセージが来た場合は、メッセージが空になるまでメッセージポンプを回す(MFCなら、while(PeekMessage(...,PM_NOREMOVE)){ theApp.PumpMessage()})
> 戻り値が、WAIT_OBJECT_0 なら、子画面終了なので、ループを抜けクローズ処理をする(1と段取り的にはほぼ同じ)
> EXEが終了してなければ、MsgWaitFor... に戻る
>
> と、こんな感じです。
> １の場合、今までの処理とは異なり複数のメッセージに分断されるためちょっと面倒かもしれません。
> ２の場合は、現在 WaitForSingleObject になっている部分を MsgWaitForMultipleObjects のループに変える形になります(関数に切り出してもいいです)。
> 処理的には２のほうが変更箇所の範囲も波及エリアも少ないです。
> が、ここに書いてある情報＋MSDNライブラリでコーディングできないようなら１で作成することをお勧めします。
>
> どちらの場合も、重要なポイントは、親画面のメインウィンドウ(モーダルダイアログから呼ばれているのならそのモーダルダイアログのウィンドウ)を EnableWindow( FALSE )として、無効化しておくことです。
> これを行うことにより、メニューや終了コマンドなど一切受け付けなくなります(ダイアログ内の全部の子コントロール類も含む)。

長い説明ありがとうございます。
EnableWindow( FALSE )はすでにコーディング済みです。
１．も２．も理解は出来るのですが、仮に実装できた場合、親画面でマウスでクリックしまくっても
アプリケーションが応答しない旨のダイアログが表示されなくなりますか？
どうも別スレッドで今までのように同期させていた方がいいような気がしてきました・・・

引用返信 編集キー/

■44726 / inTopicNo.15)

　Re[8]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ とっちゃん (441回)-(2009/12/16(Wed) 17:54:11)

■No44722 (kashi さん) に返信

> 長い説明ありがとうございます。
> EnableWindow( FALSE )はすでにコーディング済みです。
> １．も２．も理解は出来るのですが、仮に実装できた場合、親画面でマウスでクリックしまくっても
> アプリケーションが応答しない旨のダイアログが表示されなくなりますか？
> どうも別スレッドで今までのように同期させていた方がいいような気がしてきました・・・
>
せめて試してみるくらいはしてほしいなぁ。。。と思うのですがね。

ボタンを押すと、ダイアログ自体をEnableWindow(FALSE)をするだけのテスト用のダイアログアプリを作成して
実際に動かしてみるということをするだけだと思うんですけど...

必要があればデバッガなども動かせばいいと思いますが、どういう状態になるかよくわかると思います。
終了も、タスクマネージャからやったらどうなるか?などいろいろ試してみるといいと思いますよ。

引用返信 編集キー/

■44734 / inTopicNo.16)

　Re[9]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ kashi (8回)-(2009/12/16(Wed) 20:01:27)

■No44726 (とっちゃんさん) に返信
> ■No44722 (kashi さん) に返信
>
>>長い説明ありがとうございます。
>>EnableWindow( FALSE )はすでにコーディング済みです。
>>１．も２．も理解は出来るのですが、仮に実装できた場合、親画面でマウスでクリックしまくっても
>>アプリケーションが応答しない旨のダイアログが表示されなくなりますか？
>>どうも別スレッドで今までのように同期させていた方がいいような気がしてきました・・・
>>
> せめて試してみるくらいはしてほしいなぁ。。。と思うのですがね。
>
> ボタンを押すと、ダイアログ自体をEnableWindow(FALSE)をするだけのテスト用のダイアログアプリを作成して
> 実際に動かしてみるということをするだけだと思うんですけど...
>
> 必要があればデバッガなども動かせばいいと思いますが、どういう状態になるかよくわかると思います。
> 終了も、タスクマネージャからやったらどうなるか?などいろいろ試してみるといいと思いますよ。
>

どちらも試してみました。結果NGです。
というのも、処理的にはどちらもうまくいっています。
実は子画面を呼ばず、メニューやボタンクリックのイベント内で

EnableWindow(FALSE)
Sleep(10000)
EnableWindow(TRUE)

として親画面の無効化⇒10秒Wait⇒親画面の有効化
だけのステップにし、親画面のボタンやメニュー辺りを
マウスで連打すると「～アプリケーションは応答していません」のダイアログが
出てきてしまいます。
→解決策を確認してプログラムを終了します
→プログラムを終了します
→プログラムの応答を待ちます
の3択のダイアログです。
そもそもVistaが無効化した画面に対し上記マウスの操作をすると応答なしを
判断してダイアログが出るのが問題のように思えます。
処理は書き込んでいただいた方のを参考に対応したと思いますが
このVistaだけダイアログが出てきてしまうのがどうにも解決できません・・・（涙）

引用返信 編集キー/

■44735 / inTopicNo.17)

　Re[10]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ とっちゃん (442回)-(2009/12/16(Wed) 20:34:32)

■No44734 (kashi さん) に返信
> どちらも試してみました。結果NGです。
> というのも、処理的にはどちらもうまくいっています。
> 実は子画面を呼ばず、メニューやボタンクリックのイベント内で
>
> EnableWindow(FALSE)
> Sleep(10000)
> EnableWindow(TRUE)
>
これじゃ、テストになってません。
Sleep(10000)
を呼び出した時点でどうやってもアプリケーションが１０秒間応答しないことがOSにより保証されます。

ですので、そのタイミングで反応を促すようなことをやれば、反応なしと帰ってくるのは当たり前です。

私が提示したのは、EnableWindow(FALSE)「だけ」をやるようにして試してみてくださいです。

強制的に終わらせるには、タスクマネージャでプロセスを強制終了させるか
あらかじめデバッガで起動しておき、デバッガ側でプロセスを落とすようにすれば
終了できます。

> そもそもVistaが無効化した画面に対し上記マウスの操作をすると応答なしを
> 判断してダイアログが出るのが問題のように思えます。
これが問題かどうかではなく、現時点でそのように動作する仕様となっているので
それをどうやれば回避できるかを検討しているのではないのですか？

それとも、Vista側でこのメッセージを出さないようにする仕組みがあるかを質問したいのですか?

もし、後者であれば申し訳ないですが、私はそのようなことができるかどうかすら知らないのでお手伝いできません。

> このVistaだけダイアログが出てきてしまうのがどうにも解決できません・・・（涙）
>
メッセージを適切に処理すれば問題は解決します。
少なくとも WindowsOS が「現行の延長線上にある限り」未来永劫問題になることはありません。

引用返信 編集キー/

■44738 / inTopicNo.18)

　Re[11]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ kashi (9回)-(2009/12/16(Wed) 21:54:06)

■No44735 (とっちゃんさん) に返信
> ■No44734 (kashi さん) に返信
>>どちらも試してみました。結果NGです。
>>というのも、処理的にはどちらもうまくいっています。
>>実は子画面を呼ばず、メニューやボタンクリックのイベント内で
>>
>>EnableWindow(FALSE)
>>Sleep(10000)
>>EnableWindow(TRUE)
>>
> これじゃ、テストになってません。
> Sleep(10000)
> を呼び出した時点でどうやってもアプリケーションが１０秒間応答しないことがOSにより保証されます。
>
> ですので、そのタイミングで反応を促すようなことをやれば、反応なしと帰ってくるのは当たり前です。
>
> 私が提示したのは、EnableWindow(FALSE)「だけ」をやるようにして試してみてくださいです。
> 強制的に終わらせるには、タスクマネージャでプロセスを強制終了させるか
> あらかじめデバッガで起動しておき、デバッガ側でプロセスを落とすようにすれば
> 終了できます。

EnableWindow(FALSE)「だけ」をやる事は試しています。関数の内容通りアプリケーション自体はボタンも
メニューも×ボタンなども一切反応しません。タスクマネージャで強制終了させました。
ただ、無効化というのであれば私の認識ではXPの場合などダイアログの左上に（応答なし）、Vistaは
強制終了も可能なダイアログが出るとは想定していなかったのです。
EnableWindow(FALSE)をしたアプリケーションは一切反応しないと思っていたのです。
HungAppTimeoutのレジストリ設定値でXPは標準で5秒、Vistaは設定がない為おそらく即応答なしと反応
するのだと思います。現にそのようにOS上は応答なしの反応はします。

>>そもそもVistaが無効化した画面に対し上記マウスの操作をすると応答なしを
>>判断してダイアログが出るのが問題のように思えます。
> これが問題かどうかではなく、現時点でそのように動作する仕様となっているので
> それをどうやれば回避できるかを検討しているのではないのですか？
>
> それとも、Vista側でこのメッセージを出さないようにする仕組みがあるかを質問したいのですか?
>
> もし、後者であれば申し訳ないですが、私はそのようなことができるかどうかすら知らないのでお手伝いできません。

こちらも色々ソースをいじり現象を１つ１つ確認しました。
結果的に後者の方なのではないか？と思っています。
EnableWindow(FALSE)の私の認識が上に書いてあるようではないのならば
私の知識不足だったのは申し訳ないと思っています。

>>このVistaだけダイアログが出てきてしまうのがどうにも解決できません・・・（涙）
>>
> メッセージを適切に処理すれば問題は解決します。
> 少なくとも WindowsOS が「現行の延長線上にある限り」未来永劫問題になることはありません。

このメッセージとはEnableWindow(FALSE)した後のアプリケーションにWindowsから何かしらの
メッセージが送られてきているものを無視するようなイメージでアプリケーションで対応するという事ですか？
その場合どこでブレークさせ、どのイベントで拾うのか私の技術では今時点では見当もつきません・・・
申し訳ないです・・・

引用返信 編集キー/

■44744 / inTopicNo.19)

　Re[12]: VistaとWaitForSingleObjectについて

▲▼■

□投稿者/ Atata!! (6回)-(2009/12/16(Wed) 22:49:21)

Atata!!です。

WaitForSingleObject の代わりに CoWaitForMultipleHandles を使えば、Vistaの強制終了については対応できると思います。
ただし、親画面のメッセージキューにはマウスのメッセージが溜まったままになるので、
待機完了後にそれらを破棄する必要が出てきますが。
これ以外にも副作用はありますが、おそらく今までの話であれば問題になることは無いはずです。

ただ、親画面が固まったままで良いのであれば、そもそも親画面を非表示にすれば良いのではないでしょうか？

引用返信 編集キー/

■44747 / inTopicNo.20)

　Re[13]: VistaとWaitForSingleObjectについて

▲　■

□投稿者/ なちゃ (344回)-(2009/12/17(Thu) 01:56:40)

＞EnableWindow(FALSE)「だけ」をやる事は試しています。関数の内容通りアプリケーション自体はボタンも
＞メニューも×ボタンなども一切反応しません。タスクマネージャで強制終了させました。

子アプリが終了した時点でTRUEに戻せばそれでやりたいことは実現できているんではないんでしょうか？
Vista上でも強制終了ダイアログは出てこないですよね？

引用返信 編集キー/

次の20件＞
トピック内ページ移動 / << 0 | 1 >>

- Child Tree -