問題タブ [invokerequired]

現在、コンポーネントの一部を UI スレッドで実行するコンポーネントを作成しようとしています (説明が長すぎます)。したがって、最も簡単な方法は、コントロールをそれに渡し、InvokeRequired/Invoke を使用することです。しかし、コントロール参照を「データ/背景」コンポーネントに渡すのは良い設計だとは思わないので、コントロールを使用可能にする必要なしに UI スレッドでコードを実行する方法を探しています。 . WPF の Application.Dispatcher.Invoke のようなもの...

任意のアイデア、thx マーティン

ここで説明されているように、GUI コントロールへのクロススレッド アクセスの一般的なセットアップを見てきました 。

私が見つけたすべての Web ヒットは、同様のことを説明しています。

しかし、なぜ InvokeRequired を確認する必要があるのでしょうか。Invoke を直接呼び出すことはできませんか?

答えはノーだと思いますので、私の本当の質問は「なぜ」ですか?

ActiveMQ への移行中に遭遇した問題を解決する方法について誰かがアイデアを持っているかどうかを確認するためにあなたのところに来ました。このプロジェクト内で (C# で) 通知を送信するために ActiveMQ を使用しています。実装を終了した後、スレッドの問題に関するいくつかのエラーが見つかりました。（その例外の解決策は「if this.InvokeRequired ....など」を使用することですが、私の質問は次のとおりです。

この呼び出しを必要とするすべてのメソッドを見つける方法はありますか?

もちろん、通知でトリガーされたすべてのイベントを段階的に確認できましたが、時間がかかりすぎるという事実を除けば、将来のプログラミングエラーを解決することはできません.

これを理解するためのより良い方法があると思いますが、今は思いつきません。以前にこの問題に遭遇したことがありますか?

ご助力ありがとうございます

Windowsフォームが機能しているときにデリゲートクラスを使用して呼び出しを行う場合は、常にInvokeRequiredを使用する必要があります。大丈夫です。しかし、動作中にInvokeReuqiredプロパティを変更したのは誰ですか。この画像を確認してください：

プロジェクトはC＃です。

そのため、ライブラリとして実行するように設計されたマルチスレッドコードがたくさんあります。UIとは別のプロジェクトにあります。

私のライブラリには、イベントを発生させるものを作成する前に作成する必要がある中央オブジェクトがあります。

このマスターオブジェクトを一部のオブジェクトに渡して、メインUIスレッドに戻るためにイベントをいつ呼び出す必要があるかをイベントが把握できるようにすることは可能ですか？

彼のイベントハンドラーはほとんどの場合、ランダムなバックグラウンドスレッドから呼び出されるため、UIが大量の呼び出しを行う必要がないようにしたいと思います。

.Net2.0で非ビジュアルコンポーネントを構築しています。このコンポーネントは、非同期ソケット（BeginReceive、EndReceiveなど）を使用します。非同期コールバックは、ランタイムによって作成されたワーカースレッドのコンテキストで呼び出されます。コンポーネントユーザーはマルチスレッドについて心配する必要はありません（これが主な目標であり、私が望むものです）

コンポーネントユーザーは、任意のスレッドで非ビジュアルコンポーネントを作成できます（UIスレッドは、単純なアプリケーションの一般的なスレッドです。より深刻なアプリケーションでは、任意のワーカースレッド内にコンポーネントを作成できます）。コンポーネントは、「SessionConnected」や「DataAvailable」などのイベントをトリガーします。

問題：非同期コールバックとそこで発生するイベントのために、イベントハンドラーはワーカースレッドコンテキストで実行されます。最初にコンポーネントを作成したスレッドのコンテキストでイベントハンドラーを強制的に実行する中間レイヤーを使用したいと思います。

サンプルコード（例外処理などから削除...）

非同期ソケットの性質上、コンポーネントを使用するすべてのアプリケーションには「If（this.InvokeRequired）{...」が散らばっています。必要なのは、ユーザーがコンポーネントをドロップのようなものとして安心して使用できるようにすることだけです。 -の。

では、ユーザーがInvokeRequiredをチェックする必要なしに、イベントを発生させるにはどうすればよいでしょうか（言い換えると、最初にイベントを開始したスレッドと同じスレッドで発生したイベントを強制するにはどうすればよいですか）。

AsyncOperation、BackgroundWorkers、SynchronizingObjects、AsyncCallbacks、その他たくさんのことを読んだことがありますが、それはすべて私の頭を回転させます。

私はこれを思いついた、確かに不器用な「解決策」ですが、状況によっては失敗するようです（たとえば、静的クラスを介してWinFormsプロジェクトからコンポーネントが呼び出された場合）

どんな助けでもいただければ幸いです。前もって感謝します！

編集：このスレッドによると、私の最善の策はSyncrhonizationContext.Postを使用することですが、それを自分の状況に適用する方法がわかりません。

イベント ドリブンの GUI コードで次のコード パターンを記述する必要がある頻度を痛感するようになりました。

になります：

これは、覚えるにも入力するにも、C# では厄介なパターンです。これをある程度自動化する何らかのショートカットや構造を思いついた人はいますか? object1.InvokeIfNecessary.visible = true型のショートカットのように、この余分な作業をすべて行う必要なく、このチェックを行う関数をオブジェクトにアタッチする方法があれば素晴らしいと思います。

以前の回答では、毎回 Invoke() を呼び出すだけでは非現実的であると説明されていましたが、それでもInvoke() 構文は非効率的で扱いにくいものです。

それで、誰かがショートカットを見つけましたか？

たとえば、ビジネス オブジェクトがありますPerson。

そして、このクラスのオブジェクトにデータ バインドされた Winforms UI コントロールがいくつかあります。

現在、変更を行っていますが、実装somePersonしたおかげでINotifyPropertyChanged、それらの変更が UI に反映されています。ここまでは順調ですね。

ここで私の問題:ワーカー スレッド (つまり、UI スレッドではない) に変更を加えるとsomePerson、たとえばバックグラウンド操作として DB からデータをロードしているために、データ バインディングが更新を試みるため、例外が発生する可能性があります。コントロールは、UI スレッドでのみ発生することが許可されています。

これは、UI 要素を呼び出して、ビジネス オブジェクトを更新できるかどうかを確認する必要があることを意味します。これは、アプリケーションの論理階層化に違反しInvokeRequiredているように思えます。

理想的には、ビジネス オブジェクトが UI にデータ バインドされているかどうかを気にせずに、ビジネス オブジェクトを変更できるようにしたいと考えています。これは、Winforms のデータ バインディングで何らかの形で可能ですか?

PictureBox の呼び出しで別の質問があり、3 種類のエラーが発生しました。特にConrad Frixからいくつかの素晴らしい回答がありました。そのため、問題がどこにあるのかを突き止めることができましたが、今はそれを修正するために 100% 確実ではありません。

基本的に、いくつかのイベントが真であることをチェックするWindowsフォームタイマーがあります。そうであれば、そのイベント（値）がしきい値を超えてから2秒後にデータを送信するようにシステムに指示します。

私が持っているすべてのタイマーは、画像を取得するためにいくつかの場所で使用する PictureBox で厄介な競合状態を作成していると思います。

等...

タイマーの間隔は少なくとも 50 である必要があることをどこかで読みました。それを 33 から設定します。picCapture.InvokeRequired を実行して、基本的に死ぬかどうかを確認できることがわかりました。私はデリゲートを使用する必要があることを知っていますが、何かを設定するためにのみ使用しました...画像を取得するためではありません....それを設定する方法がわかりません...実際に何が原因であるかはわかっています、それはこれですコードの組み合わせ:

以前の質問によると、timer1_tick イベントでメモリの問題やその他のエラーが発生しないようです... (メモリ不足エラーは 1 つでした)。

最大の問題は、画像データが必要なときに picCapture.InvokeRequired をどのように処理できるかだと思いますか? timer1_click内のスレッドタイマー呼び出しがこれを引き起こしていると確信しています....