たとえば、私はこのコンパイラ警告を受け取ります、
イベント「Company.SomeControl.SearchClick」は使用されません。
しかし、コメントアウトすると、このイベントを使用しようとしているXAMLページの20の新しい警告のようにスローされるので、それが使用されていることはわかっています。
何ができますか?この警告を取り除くトリックはありますか?
回答:
これは警告67のようであり、次のようにして抑制できます。
#pragma warning disable 67
(イベント宣言の後)できるだけ早くそれを復元することを忘れないでください:
#pragma warning restore 67
ただし、もう一度チェックして、イベントをサブスクライブするだけでなく、どこかでイベントを発生させていることを確認します。コンパイラは20回の吐き出すという事実の警告ではなく20 エラーをあなたがイベントをコメントアウトするときにも疑わしいです...
この警告についての興味深い記事もあり、具体的にはそれがインターフェイスにどのように適用されるかを示しています。「未使用」のイベントを処理する方法についての良い提案があります。重要な部分は次のとおりです。
正しい答えは、イベントに何を期待するかを明確にすることです。この場合は何も起こりません。
public event EventHandler Unimportant { add { } remove { } }
これにより、警告だけでなく、コンパイラが生成した通常のイベントの追加の実装も完全に抑制されます。もう1つの追加の利点として、この何もしない実装が本当に最良の実装であるかどうかを考えるように促します。たとえば、イベントがサポートされていないほど重要ではない場合、その機能に依存するクライアントはイベントがなければ失敗する可能性が高いため、サポートの欠如を明示的に示し、例外:
public event EventHandler Unsupported { add { throw new NotSupportedException(); } remove { } }
もちろん、その機能の一部がなくても便利に実装できるインターフェースは、インターフェースが最適にまとまりがなく、個別のインターフェースに分割する必要があることを示す場合があります。
インターフェースからイベントを実装する必要がある場合は、実装に必要がないため、次のようにして警告を回避できます。
public event EventHandler CanExecuteChanged { add{} remove{} }
if(OnCompleteOpenEvent != null) OnCompleteOpenEvent();
「OnCompleteEventは現在のコンテキストに存在しません」と表示されます。
2番目の最良の方法は、誰かがイベントをサブスクライブしようとした場合に例外をスローすることにより、イベントがサポートされていないことを明確に示すことです。
public event RoutedEventHandler SearchClick
{
add { throw new NotSupportedException(); }
remove { throw new NotSupportedException(); }
}
これのバリエーションとして、add
およびremove
メソッドを空のままにして、イベントのサブスクリプションを暗黙的に無視することもできます。
最善の解決策は、コードをリファクタリングすることです。可能であれば、イベントの宣言を実装者にプルすることもできます。
最後の手段として、このように警告を無効にすることもできます
#pragma warning disable 67
public event RoutedEventHandler SearchClick;
#pragma warning restore 67
コンパイラーは、XAMLコードで使用されていることを明らかに認識していません。イベント定義で警告を抑制してみてください。
また、イベントを実際にどこかで発生させていることを確認してください。
または<NoWarn>67</NoWarn>
、プロジェクトに追加できます
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
...
<NoWarn>67</NoWarn>
</PropertyGroup>