3

.NETでは、イベントを含むインターフェイスを実装しているが、そのイベントがオブジェクトにとって意味をなさない場合（たとえば、変更イベントであり、不変のオブジェクトを記述している場合）add、remove--nullの実装。これにより、使用しないデリゲートフィールドにストレージを割り当てることが回避され、「イベントは使用されない」というコンパイラの警告も回避されるため、あらゆる面でメリットがあります。

public event EventHandler Changed {
    add {}
    remove {}
}

WinRTクラス（FrameworkElementから派生）で同じことを試みると、addアクセサーでコンパイラエラーが発生します：「すべてのコードパスが値を返すわけではありません」。

addアクセサから値を返すにはどうすればよいですか？何が返ってくるの？

更新：明らかに、この問題はWinRTイベントにのみ適用されます（たとえば、イベントを含むWinRTインターフェイスを実装している場合）。昔ながらのCLRイベントを作成している場合は、上記の構文が機能します。

4

2 に答える 2

6

この記事はWindowsDevCenterで見つかりました。addおよびremoveアクセサ機能がMetroで実際に変更されたようです。

Windowsランタイムの.NETFrameworkサポートにより、Windowsランタイムイベントパターンと.NET Frameworkイベントパターンの違いを隠すことにより、Windowsランタイムコンポーネントでイベントを簡単に宣言できます。ただし、Windowsランタイムコンポーネントでカスタムイベントアクセサーを宣言する場合は、Windowsランタイムパターンに従う必要があります。

Windowsランタイムでイベントを処理するために登録すると、addアクセサーはトークンを返します。登録を解除するには、このトークンを削除アクセサーに渡します。これは、Windowsランタイムイベントのアクセサーの追加と削除には、以前のアクセサーとは異なる署名があることを意味します。

幸い、Visual BasicおよびC＃コンパイラは、このプロセスを簡素化します。Windowsランタイムコンポーネントでカスタムアクセサを使用してイベントを宣言すると、コンパイラは自動的にWindowsランタイムパターンを使用します。たとえば、addアクセサーがトークンを返さない場合、コンパイラエラーが発生します。

.NET Frameworkは、実装をサポートするために2つのタイプを提供します。

  • EventRegistrationToken構造体は、トークンを表します。
  • EventRegistrationTokenTable <T>クラスはトークンを作成し、トークンとイベントハンドラーの間のマッピングを維持します。ジェネリック型引数は、イベント引数型です。イベントハンドラーがそのイベントに初めて登録されるときに、イベントごとにこのクラスのインスタンスを作成します。
于 2012-06-19T11:24:10.660 に答える
4

したがって、Andersが投稿したリンクに基づくと、addアクセサはを返す必要があるようEventRegistrationTokenです。EventRegistrationTokenは単なる構造体であり、明らかにフィールドがなく、デフォルトを超えるコンストラクターがないため、無害に1つ上げることができるように見えます。new特に、それを消費するコードはmyだけなので、remove気にしません。

したがって、nullイベントに相当するWinRTは次のようになります。

public event EventHandler Changed {
    add { return new EventRegistrationToken(); }
    remove {}
}
于 2012-06-19T11:42:12.717 に答える