3

私が現在保守を担当しているアプリケーションは Application.DoEvents() メソッドに大きく依存しており、突然の不可解なアプリケーション クラッシュのすべてがこのメソッドの使用によって引き起こされているという確実な証拠はありませんが、これまでのところほとんどの私が特定した問題のうちの 1 つは、コードの実行の流れがこのメソッドを中心とする方法に何らかの形で関連しているようです。

コード全体で見たパターンは、多かれ少なかれ次のとおりです。

  1. ユーザーがトリガーしたイベントが発生する

  2. イベント ハンドラー プロシージャの実行

次に、次のいずれかを行います。

  1. 新しいスレッドが生成されます

  2. 生成されたスレッドが実行されなくなるまで UI スレッドと UI をブロックしたり、制御をイベント ハンドラー プロシージャから解放したりするのではなく、生成されたスレッドが実行されたことを示すシグナルを受け取るまで、コードがループし、各パスで Application.DoEvents() を呼び出します。実行されなくなりました。( Application.DoEvents() は、他のイベントが完了するのを待っているときに、生成されたスレッドによって同時に呼び出される場合もあります。)

  3. #2 に見られるパターンは、制御がイベント ハンドラー プロシージャを離れる前に何度も繰り返されます。

また：

  1. フォームが作成され、Show() または ShowDialog() メソッドによって表示されます。

  2. ユーザーがフォームを操作するまで UI スレッドと UI の残りの部分をブロックしたり、イベント ハンドラー プロシージャから制御を放したりするのではなく、コードがループし、Application.DoEvents() を呼び出して各パスを呼び出します。ユーザーがフォームを操作しました。

  3. 次のフォームがユーザーに表示され、多くのフォームの後のコントロールが最終的にイベント ハンドラー プロシージャを離れることを許可されるまで、同じドリルが繰り返されます。

目の前にコードがない場合に問題を診断するのは難しいことはわかっていますが、 Application.DoEvents() の呼び出しがこのアプリケーションの不安定な動作に何らかの形で関連していると仮定すると、最も簡単な方法は何でしょうか?ゼロから再設計せずにこのアプリケーションを修正するには?

イベント ハンドラー プロシージャが新しいスレッドを生成し、制御がイベント ハンドラー プロシージャをすぐに終了できるようにし、Application.DoEvents() を繰り返し呼び出す代わりに、WaitHandle などを使用して、生成されたスレッドをブロックするだけの問題ですか。生成されたスレッドが、別のスレッドがその仕事を完了したか、ユーザーがフォームと対話したという通知を受け取るまで、シグナル伝達メカニズム?

4

2 に答える 2

1

スレッドから DoEvents を削除するための良いヒントに加えて、BackgroundWorker クラスで遊んでみましたか? 単純なスレッド操作とフォームとの通信に適しています。 http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx http://www.dotnetperls.com/backgroundworker

于 2013-03-29T15:35:31.413 に答える
0

継承された設計に複数の大きな問題があります。Hans が提案したように、核兵器を使用せずに (実際には悪い考えではありません)、非 GUI スレッドからの Application.DoEvents() 呼び出しを完全に取り除くことから始めます。

次に、他の肥料の山から始めます。

于 2013-03-29T14:02:20.913 に答える