問題タブ [weakeventmanager]

ここで説明されているように弱いイベントを使用する場合http://wekempf.spaces.live.com/blog/cns!D18C3EC06EA971CF!373.entryWindows.FormsアプリケーションでWeakEventManagerがWeakReferenceオブジェクトをリークします。これは、WPFメッセージループがないと、ScheduleCleanupがWeakEventManager.ProtectedAddListenerで呼び出されても、CleanupOperationが実行されないためだと思います。

回避策として、次のようなクリーンアップ関数を実装しました。

たとえば、への16回目の呼び出しごとにこれを呼び出しますProtectedAddListener。

これは機能しますが、明らかに私はこの（乱用された）反射の使用を避けたいと思っています。

だから私の質問は：

1. パブリック/保護されたメンバーを使用してクリーンアップ機能を実装する方法はありますか？WeakEventManager.Purgeは便利かもしれませんが、使い方がわかりません。
2. Windows.FormsベースのアプリケーションでWPFメッセージループを実行する簡単な方法はありますか？

.NETのWeakEventManagerを使用した弱いイベントの実装例はありますか？

ドキュメントの「継承者への注意」に従って実装しようとしていますが、あいまいです。たとえば、カスタムマネージャーProtectedAddListenerの静的関数から呼び出す方法がわかりません。AddListener

WPFアプリの弱いイベントマネージャーを使用して、XXXEventManager.AddListener（source、this）;を使用して、イベントのソースをターゲットに接続しています。電話。ただし、コードが同じソースとターゲットを複数回接続することがあることに気付きました。これにより、実質的に同じ（つまり、フックアップごとに1つ）の複数のイベントが発生/処理されるように見えます。WeakEventManagerに問い合わせる（またはそれに機能を追加する）ことによって、ターゲットがすでにイベントソースに接続されているかどうかを判断することは可能ですか、それともターゲットに独自のリストを実装する必要がありますか？

また、ソースの存続期間中にイベントフックアップが存在する必要がある場合に、RemoveListenerを呼び出すために受け入れられるメソッドは何ですか？ファイナライザーを使用するとガベージコレクションに問題が発生するため、ファイナライザーを使用することはお勧めできません。これは正確ですか？

DependencyPropertiesへの変更をリッスンするWeakEventManagerの実装のフレームワークを探していました。私が見つけた唯一の弱いプロパティ変更イベントリスナーであるPropertyChangedEventManagerは、INotifyPropertyChangedを実装する型で使用するように設計されているという事実に少し混乱しています。

これは、DependencyPropertyで変更をリッスンする場合を意味しますか？

イベント登録によって存続しているインスタンスのリークについて心配する必要はありませんか？

Michael Dudley のサンプル コードを、弱いイベント マネージャーの独自の実装に適合させようとしています。

.NET の WeakEventManager を使用した弱いイベントの実装例

自分のハンドラーのユーザー コードをどこに配置すればよいのだろうか? 私はこれを見る：

その式の内容を独自のカスタム コードに置き換えますか?

ありがとうございました、

ケビン

DependencyPropertyChangedEventArgs を提供するイベントと一緒に WeakEventManager (4.5 で問題ありません) を使用する最良の方法は何だろうかと考えています。これらは (パフォーマンス上の理由から) EventArgs から派生しないため、WeakEventManager はそのままでは機能しません。

ガイド、リンク、またはヒントをいただければ幸いです。

私はメモリ リークを避けるために WeakEventManager を使用してきましたが、使いすぎてしまいました。たとえば、次のような INotifyPropertyChanged の拡張メソッドを作成しました。

今、私はこれがうまくいかないことにすぐに気づきました。実際、弱いイベント処理に匿名メソッドを実際に使用することはできません。（私が正しく理解していれば、コンパイラは（参照された値を保持するために）そのための「クロージャークラス」を作成します。これにはハンドラーがありますが、クロージャークラスはどこにも参照されていないため、GCはそれをクリアし、イベントハンドラー呼ばれません）

質問 #1: それは正しいですか? つまり、弱いイベント ハンドラーに匿名メソッド (またはラムダ) を使用する場合、その間に GC が実行されなかった場合にのみハンドラーが呼び出されます (たとえば、非決定論的です)。

まあ、そう思ったので、ユニットテストを行って、それが正しいことを確認しました。次の単体テストを実行するまでは問題ないようでした。

質問 #2: このテストが失敗する理由を説明できる人はいますか?

期待: ここでは、クロージャーはありません (何が起こっているかを確認するためにそれらを取り出しました)。WeakEventManager でイベントにサブスクライブするオブジェクト (クロージャー) があり、それへの参照をドロップします (閉鎖 = null;)。

古いクロージャー クラスをクリーンアップするために 2 つの GC.Collect() 呼び出しを期待していたので、WeakEventManager はサブスクライバーを削除し、ハンドラーを実行しませんが、テストは失敗します。何か案は？

編集:申し訳ありませんが、一般的な引数は表示されませんでしたが、現在は表示されています

巨大な設定ファイルを渡すという考えが気に入らなかったので、使用していた静的クラスがありますが、インスタンスが静的クラスの静的イベントにサブスクライブできるようにしたいと考えました。

PropertyChangedEventManager の AddListener メソッドの使用を検討していましたが、追加するにはインスタンスが必要です。

これは可能ですか？問題がある場合に備えて、私は.net 4.0を使用しています。

コードでPropertyObserverクラスを使用して、PropertyChangedイベント処理での 文字列比較を回避し、nullまたはstring.Emptyその引数としての処理を除外しています (これは、オブジェクトのすべてのプロパティが変更されたことを示します)。

このクラスはPropertyChangedEventManager、ターゲット オブジェクトにコールバックを登録するために使用し、ソース オブジェクトでイベントが呼び出されるIWeakEventListenerたびに応答するように実装します。PropertyChanged

しかし、単体テストの作成中にIWeakEventListener.ReceiveWeakEvent()、登録されたコールバックの数として N を使用して、 が N 回呼び出されることがわかりました。これは、PropertyChanged イベントで有効なプロパティ名が指定された場合ではなく、null または string.Empty が指定された場合にのみ発生します。

なぜこれが起こっているのか、それを修正する方法を知っている人はいますか? 私の目標は、null が指定されたときに登録済みハンドラーの foreach を 1 回実行することです。これにより、ソース オブジェクトのすべてのプロパティを取得してターゲット オブジェクトを更新できます。しかし、ReceiveWeakEvent()が N 回呼び出されると、foreach は N 回繰り返されます!

それを説明するために、以下は PropertyObserver クラスとソース クラスの簡略化されたバージョンです (実装には MVVM Light を使用しています) ObservableObject。INotifyPropertyChanged

コンソール アプリの Main では、次のように呼び出すことができます。