2

IProgress<T>.Report();すべて、 UI を更新し、関連するデータを選択するために呼び出すメソッドがあります。その後、バックグラウンド スレッドは、それと連携するインターフェイスを介して (UI 上の) 現在の選択を取得します。IProgress<T>.Report();したがって、 UI の更新が行われるまで呼び出しが戻りをブロックすることが重要です。MSDNは、メソッドのこの側面に関する情報を提供していませんReport();...

デリゲートが終了するまで、Report();メソッドはバックグラウンド スレッドへの復帰をブロックしますか?Report();

御時間ありがとうございます。

4

2 に答える 2

6

いいえ、そうではありません。送信する代わりに、同期コンテキストに投稿します。投稿は非同期です。

これは実装の詳細であることに注意してください。私はコードを読んでそれを学びましたが、これに関する公式文書は知りません。

さらに、SynchronizationContext.Post非同期であると想定されていますが、そうであるとは限りません。たとえば、ASP.NET ではデリゲートを直接、つまり同期的に呼び出すことができます。参照: 図 4 を参照してください

于 2013-01-31T12:09:45.293 に答える
5

これは、使用しているの実装に完全に依存しIProgress<T>ます。組み込みの を使用する場合はProgress<T>Report()デリゲート/イベント ハンドラーが完了するのを待ちません。

必要なことを行う独自の実装を作成IProgress<T>し (これは を呼び出す可能性が最も高いSynchronizationContext.Send())、それを使用できます。

しかし、これが良い設計であるかどうかはわかりません。ワーカー コードは、GUI スレッドで行わなければならない計算に依存すべきではないと思います。デザインの変更を検討したい場合があります。

于 2013-01-31T13:33:50.043 に答える