掲示板システム
ホーム
アクセス解析
カテゴリ
ログアウト
BackgroundWorkerでRunWorkerCompletedが発生しない (ID:147386)
名前
ホームページ(ブログ、Twitterなど)のURL (省略可)
本文
> コントロールの数が多い、フォームの大きさに合わせて調整されるコントロールなどがあるという点からフォームの用意(フォームの大きさに合わせるという点からLOADとは異なります)に時間がかかります。 > フォームの用意から表示は一連になります。 その調整,本当に要りますか。 Anchor, Dock, TableLayoutPanelなどで実は済みませんか。 さらに,Resizeイベントで処理する方が適当だったりしませんか。 > 「Button1_Clickから制御を戻さない限り,RunWorkerCompletedイベントは発生しない」という点が最も気になります。 > であれば並行処理が結構制限されると言うことになりますから。 DoWorkが実行の本体,RunWorkerCompletedは実行結果をUIに反映させるためのものです。 UIに反映させるためには,UIスレッドで実行する必要があります。 故に,RunWorkerCompletedイベントはUIスレッドの制御がシステムに戻っているタイミングで実行されます。 # ちなみに,ProgressChangedイベントは途中の状況をUIに反映させるためのものです。 > 調べてみたのですが、BackGroundWorkerでは処理分岐後に合流するという手順は難しそうですね。 あくまで重い処理をUI側から簡単にワーカースレッドで処理させるために使うのがBackgroundWorkerです。 並列処理したければPLINQなんかがありますし,並行でもTask使ってしまえばよいです。 ただ,どちらにしてもUIをブロックしないために最初にBackgroundWorkerなりTaskなりでワーカースレッドに委譲する必要がありますが。 > 合流が必要ならThreading.Threadを使用するしかなさそうな。 今回の場合だと,RunWorkerCompletedイベントを適切に処理するだけで十分だと思います。 UIスレッドはイベントハンドラが呼ばれた後可能な限り素早くシステムに返すのが基本なので, UIスレッドで待つような必要が生じたなら,基本的に処理を見直す必要があります。 Threadクラスが必要になるのはCOMのアパートメントモデルを指定する必要がある時くらいしか思いつきません。 スレッドプールを使わないので,大体の場合は効率が落ちますしメモリも食いますし……。
←解決時は質問者本人がここをチェックしてください。
戻る
掲示板システム
Copyright 2020 Takeshi Okamoto All Rights Reserved.