109

For example, I get this compiler warning,

The event 'Company.SomeControl.SearchClick' is never used.

But I know that it's used because commenting it out throws me like 20 new warnings of XAML pages that are trying to use this event!

What gives? Is there a trick to get rid of this warning?

poke
  • 369,085
  • 72
  • 557
  • 602
jedmao
  • 10,224
  • 11
  • 59
  • 65

7 Answers7

175

This appears to be warning 67 and can thus be suppressed with:

#pragma warning disable 67

Don't forget to restore it as soon as possible (after the event declaration) with:

#pragma warning restore 67

However, I'd check again and make sure you're raising the event somewhere, not just subscribing to it. The fact that the compiler spits out 20 warnings and not 20 errors when you comment out the event is also suspicious...

There's also an interesting article about this warning and specifically how it applies to interfaces; there's a good suggestion on how to deal with "unused" events. The important parts are:

The right answer is to be explicit about what you expect from the event, which in this case, is nothing:

public event EventHandler Unimportant
{
    add { }
    remove { }
}

This will cleanly suppress the warning, as well as the extra compiler-generated implementation of a normal event. And as another added benefit, it prompts one to think about whether this do-nothing implementation is really the best implementation. For instance, if the event isn't so much unimportant as it is unsupported, such that clients that do rely on the functionality are likely to fail without it, it might be better to explicitly indicate the lack of support and fail fast by throwing an exception:

public event EventHandler Unsupported
{
    add { throw new NotSupportedException(); }
    remove { }
}

Of course, an interface that can be usefully implemented without some parts of its functionality is sometimes an indication that the interface is not optimally cohesive and should be split into separate interfaces.

Pang
  • 9,564
  • 146
  • 81
  • 122
lc.
  • 113,939
  • 20
  • 158
  • 187
  • That's exactly what I need! Thank you! The only difference is that I added my own comment beside the 67 so I knew what it was in the future. Here's "exactly" what I typed... #pragma warning disable 67 // event never used public event RoutedEventHandler SearchClick; #pragma warning restore 67 – jedmao Jul 07 '09 at 16:38
  • This is useful; not going to keep in place, but just something to get current idea running... – dudeNumber4 Dec 01 '16 at 15:25
91

If you are forced to implement an event from an interface, that your implementation doesn't need you can do the following to avoid the warning.

public event EventHandler CanExecuteChanged { add{} remove{} }
vidstige
  • 12,492
  • 9
  • 66
  • 110
Adam Mills
  • 7,719
  • 3
  • 31
  • 47
  • If I do this, it says later in the file where I do `if(OnCompleteOpenEvent != null) OnCompleteOpenEvent();` that "OnCompleteEvent does not exist in the current context". – Almo Apr 04 '14 at 18:58
  • 2
    @Almo, that is correct. However, you are describing the case where you ARE using the event and so the warning would not show up so you would not use the fix for the warning. Right? Typically you have an interface specifying the event and two subclasses. One does not use the event and uses this solution. The other does use the event and never threw the warning to begin with. – Dirk Bester Aug 21 '14 at 03:31
  • It's been too long, but we were getting this error even though it was being used. Had something to do with it being defined in a way the fooled the compiler into thinking it wasn't used. – Almo Aug 21 '14 at 12:26
  • Thank you very much for this easy solution to a very maddening situation! – M463 Oct 26 '17 at 16:37
18

The second best way is imho to clearly state that the event is not supported by throwing an exception if someone tries to subscribe to it.

public event RoutedEventHandler SearchClick
{
    add { throw new NotSupportedException(); }
    remove { throw new NotSupportedException(); }
}

As a variant on this, you can also just leave the add and remove methods empty to silently ignore subscriptions on the event.

The best solution is to refactor the code, perhaps pull the declaration of the event to the implementor if possible.

As a last resort, you can also disable the warning like so

#pragma warning disable 67
public event RoutedEventHandler SearchClick;
#pragma warning restore 67
Martin
  • 5,165
  • 1
  • 37
  • 50
vidstige
  • 12,492
  • 9
  • 66
  • 110
5

You can also do the following:

public event EventHandler MyEvent = delegate {}
GrantA
  • 490
  • 5
  • 13
1

The compiler is apparently not aware that it's being used in XAML code. Try suppressing the warning in your event definition.

Also, make sure you're actually raising the event somewhere.

SLaks
  • 868,454
  • 176
  • 1,908
  • 1,964
  • That's what I thought too, so I moved the XAML code to the code behind and it showed the same warning! And yes, I'm 100% sure the event is being raised somewhere. I'm looking right at it. It's wired to a button. – jedmao Jul 07 '09 at 16:44
1

You can supress individual warnings.

\Program.cs(13,20): warning CS0219: The variable 'foo' is assigned but its value is never used

In this case, CS0219 is the warning regarding variables being assigned but not used. You can either use the /nowarn:0219 flag, or add the error number in the properties pane for the project (under "Build", remember to remove the leading CS). Keep in mind the supresses all warnings of this class.

Svend
  • 7,916
  • 3
  • 30
  • 45
0

Or you can add <NoWarn>67</NoWarn> to your project

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
  ...
  <NoWarn>67</NoWarn>
</PropertyGroup>
Simon
  • 33,714
  • 21
  • 133
  • 202
  • 10
    this will disable the warning in the entire project potentially hiding real issues with unused events. – vidstige Dec 05 '13 at 07:02