問題タブ [invoke]

私はこのようないくつかのクラスを持っています

正しく動作し、「METHOD FROM C」を出力します

しかし

もし私がこのような状況にあったら

「METHOD FROM A」と表示されます。キャストを採用したり、オーバーライドでメソッド宣言を変更したりせずに、最初の例と同じ動作を取得するにはどうすればよいですか?

送信時にタイプが未完了のデリゲートに呼び出しを送信するのに問題があります。詳細を説明します。次のデリゲートタイプを宣言しました。

そして今、私は動的に（つまり、TypeBuilderを使用して）次のクラスを作成しようとしています。

*オープンインスタンスデリゲート。

DirectReadAccessor []タイプのフィールドdirectReadAccessorsを宣言しようとしたとき、またはまだ存在しないMyClassを再び使用するメソッドInitalizeClassを発行したときに、MyClassが存在しないため、これは注意が必要です。私が作成しているもの）。しかし、私はこれをすべて行うことができましたが、スタックにデリゲートを配置した後、デリゲートを呼び出す方法がわからないため、DirectReadメソッドで問題が発生しています。どうやら私が必要としているのは次の放出です：

ここで、invokeMInfoはDirectReadAccessorのInvokeメソッドであり、次のように取得する必要があります。

繰り返しますが、問題はMyClassもDirectReadAccessorもまだ存在しないことです。MyClass用のTypeBuilderと、次のように作成した未完成のDirectReadAccessorタイプがあります。

しかし、上記のようにdirectReadAccessorTypeでGetMethod（ "Invoke"、....）を呼び出そうとすると、未完了の型のメソッドInvokeを取得できないため、NotSupportedExceptionが発生します。タイプを次のように確定した後、同じ呼び出しを行うことによって、この仮定をテストしました。

そして確かに、その場合は例外はありません。ただし、InitializeClassのコードを出力している間、型を確定する前にInvokeメソッドのMethodInfoを取得できる必要があります。

これは奇妙な状況です。必要なときにデリゲートを用意しますが、それを呼び出すためのコードを作成できません。誰かが助けを提供できますか？

どうもありがとう、そして長い投稿をお詫びします。

私はWPFアプリケーションを構築しています。サーバー側と非同期通信を行っており、クライアントの Prism でイベント集約を使用しています。これらの両方により、UI スレッドではない新しいスレッドが生成されます。これらのコールバックおよびイベント ハンドラー スレッドで "WPF 操作" を実行しようとすると、世界がバラバラになります。

最初に、サーバーからのコールバックでいくつかの WPF オブジェクトを作成しようとして問題に遭遇しました。スレッドは STA モードで実行する必要があると言われました。今、Prism イベント ハンドラーでいくつかの UI データを更新しようとしていますが、次のように言われました。

別のスレッドがこのスレッドを所有しているため、呼び出し元はこのスレッドにアクセスできません。

そう; WPF で物事を正しく行うための鍵は何ですか? この MSDN の投稿で WPF Dispatcher について調べました。私はそれを理解し始めていますが、私はまだ魔法使いではありません.

1. UIスレッドで呼び出されるかどうかわからない何かを実行する必要がある場合、常に Dispatcher.Invoke を使用することが重要ですか?
2. それが実際に UI スレッドで呼び出されたかどうかは重要ですか? とにかく Dispatcher.Invoke を実行しますか?
3. Dispatcher.Invoke = 同期的に。Dispathcher.BeginInvoke = 非同期?
4. Dispatcher.Invoke は UI スレッドを要求し、停止して待機しますか? それは悪い習慣であり、反応の悪いプログラムのリスクですか?
5. とにかくディスパッチャーを取得するにはどうすればよいですか？Dispatcher.CurrentDispatcher は常に UI スレッドを表すディスパッチャを提供しますか?
6. 複数の Dispatcher が存在しますか、それとも "Dispatcher" は基本的にアプリケーションの UI スレッドと同じですか?
7. そして、BackgroundWorker との取引は何ですか? 代わりにいつこれを使用しますか? これは常に非同期だと思いますか？
8. UI スレッドで (Invoked によって) 実行されるものはすべて STA アパートメント モードで実行されますか? つまり、STA モードで実行する必要がある場合、Dispatcher.Invoke で十分でしょうか?

私のために物事を明確にしたい人はいますか？関連する推奨事項などはありますか？ありがとう！

私のWPFアプリケーションでは、サーバーと非同期で通信します。したがって、コールバックはUIスレッドで実行されません。そこで、いくつかのWPF処理（InkPresenterオブジェクトの作成）を行う必要があるため、UIスレッドで実行する必要があります。実際の要件は、STAアパートメントモードのスレッドで実行することです。STAモードで新しいスレッドを作成しようとしましたが、「別のスレッドが所有している」ため、UIスレッドがInkPresenterにアクセスできませんでした。

コールバックで実行したいのは、ディスパッチャーを使用して、STAを必要とする関数を呼び出すことです。これは正しいアプローチのように聞こえますか？私は今これをします、しかしそれはまだ失敗します。コールバック関数で次の関数をトリガーします。これにより、アドレス指定された関数がUIスレッドで実行されるようになります。

サンプルからわかるように、CheckAccess（）を使用して、UIスレッドでまだ実行されていない場合にのみ関数を呼び出すようにします。私のコールバックがこの関数を呼び出すとき、CheckAccess（）は常にtrueですが、Dispatcher.CurrentDispatcher.Thread.ApartmentStateMTAです。なんで？CheckAccess（）を削除して常にInvokeを実行しようとしましたが、ApartmentStateはMTAのままであり、InkPresenterの作成は失敗します。

ここで私が間違っていることを誰かに説明してもらえますか？間違ったディスパッチャーか何かを持っていますか？これは、UIスレッドで何かが実行されるようにするための正しいアプローチですか？

全て、

誰かが開発したCOMサーバーコンポーネント（.Dll）があります。そのCOMサーバーで関数を（invoke（）を使用して）呼び出すと、エラー0x800706BE-リモートプロシージャコールが失敗しました。興味深いことに、このエラーは数回しかスローされません!!。それ以外の時間は問題なく動作します!!。

この問題は、Windows2k864ビットOSおよびWin732ビットで報告されています。

1. 何が問題になるのか考えてみてください。
2. COMサーバーまたはCOMクライアントの問題でしょうか？
3. 犯人を知るために絞り込む方法はありますか？

ありがとう、バイト

シリアルポートを介してデータを送信するハードウェアデバイスから読み取り値を取得するシステムを作成しています。「パケット」がシリアルポートから出てくるたびに、更新された情報を反映するためにいくつかのGUIコンポーネントを更新して再描画します。シリアルポートイベントは別のスレッドから発生するため、いくつかのコンポーネントでInvoke（Invalidate）を呼び出して再描画する必要があります。これにより、GUIがシリアルポートデータの背後に移動する可能性があります。これは、GUIが大量のコンポーネントをキューに入れるためです。 Invoke（）は、ハードウェアデバイスが1秒間に500パケットの送信を開始するかどうかを要求します。

GUIコンポーネントにすでにInvoke（Invalidate）リクエストがあるかどうかを確認する方法はありますか？コードがこれらの束をキューに入れるのを防ぐことができますか、それともGUIコンポーネントを更新するために完全に別のアプローチを取る必要がありますか？

オプションのパラメーターを指定してC＃4.0を使用すると、別の問題が発生しました。

ConstructorInfoパラメーターを必要としないことがわかっている関数（またはコンストラクター、オブジェクトがあります）を呼び出すにはどうすればよいですか？

これが私が今使っているコードです：

（私は別の方法で試しましたBindingFlags）。

GetParameterlessConstructorのために書いたカスタム拡張メソッドですType。

delphi 6にはバグがあり、tlbをインポートすると、イベント呼び出しのパラメーターの順序が逆になるための参照をオンラインで見つけることができます。インポートされたヘッダーで1回、TServerEventDIspatch.Invokeで1回反転されます。

詳細については、http： //cc.embarcadero.com/Item/16496をご覧 ください。

この問題にいくらか関連して、TServerEventDispatch.InvokeにVar_ArrayタイプのVariantのパラメーターを使用してメモリリークが発生しているようです（おそらく他のパラメーターですが、これは私が見ることができるより明白なものです）。呼び出しコードは、argsをVarArrayにコピーしてイベントハンドラーに渡し、呼び出し後にVarArrayをargsにコピーして戻します。関連するコードを以下に貼り付けます。

私の場合、いくつかの明らかな回避策があります。VarArrayパラメータの場合にコピーバックをスキップすると、リークが修正されます。機能を変更しないために、バリアントではなく配列内のデータをparamsにコピーして戻す必要があると思いましたが、他のバリアントを保持できるため複雑になる可能性があり、再帰的に実行する必要があるようです。

OleServerの変更は波及効果があるので、ここでの変更が厳密に正しいことを確認したいと思います。

誰かがここでメモリがリークされている理由を正確に明らかにすることができますか？TServerEventDIspatch.Invokeよりも低いコールスタックを検索できないようです（なぜですか？）

VarArrayを保持しているVariantをパラメータリストにコピーするプロセスで、配列への参照が追加されたため、通常どおりにリリースできなかったと思いますが、これは大まかな推測であり、コードを追跡することはできません。それをバックアップします。

たぶん、これらすべてをよりよく理解している誰かがいくつかの光を当てることができますか？

私は次のコードを持っています：

問題は、別のスレッドから「SetStatusBarText」サブを呼び出すと、InvokeRequired が True (本来あるべき状態) であるにもかかわらず、スレッドが Me.Invoke ステートメントで停止することです。何でも呼び出します。

スレッドが Invoke を恐れているように見える理由について何か考えはありますか?

これを達成するための最良の方法は何ですか: メイン スレッド (スレッド A) は、他の 2 つのスレッド (スレッド B とスレッド C) を作成します。スレッド B と C は大量のディスク I/O を実行し、最終的に作成したリソースをスレッド A に渡して外部 DLL ファイルのメソッドを呼び出す必要があります。このメソッドでは、スレッドを作成したスレッドが正しく呼び出される必要があるため、スレッド A だけが呼び出すことができます。 .

これまでにスレッドを使用したのは Windows フォーム アプリケーションだけであり、invoke メソッドはまさに私が必要としていたものでした。このプログラムは Windows フォームを使用しないため、使用する Control.Invoke メソッドはありません。

私のテストでは、変数がスレッド A で作成された場合、スレッド B/C から問題なくアクセスして変更できることがわかりました。これは私には非常に間違っているようです。Winforms では、他のスレッドで作成されたものにアクセスしようとすると、エラーがスローされると確信していました。複数のスレッドから変更するのは安全ではないことはわかっていますが、安全なコーディングを保証するために、.NET がそれを完全に禁止することを本当に望んでいました。.NET はこれを行いますか?私は船に乗り遅れているだけですか?それとも WinForm アプリでのみ行うのでしょうか?

一見これを許可しているように見えるので、OS のようにフラグを作成し、スレッド A から監視して、変更があるかどうかを確認します。存在する場合は、メソッドを呼び出します。イベント ハンドラーは本質的にこれを行うわけではないので、メイン スレッドで呼び出されたイベントを何らかの方法で使用できますか?