locked
How do I prevent CS0414 warning (field assigned but value is never used) in Xaml RRS feed

  • Question

  • User55069 posted

    I have a view in which I reference another control via Xaml by x:Reference.

    <StackLayout x:Name="listOptions" IsVisible="{Binding IsListOptionsVisible}" />
    <StackLayout Orientation="Horizontal" IsVisible="{Binding IsListOptionsVisible}">
        <Entry x:Name="optionName" Placeholder="Option" />
        <Button Text="Add Option" Command="{Binding AddOption}" CommandParameter="{Binding Path=Text, Source={x:Reference optionName}}" />
    </StackLayout>
    

    This is causing a compiler warning in the automatically generated partial class code at private Entry optionName;.

    Warning CS0414: The private field `AddQuestionPage.optionName' is assigned but its value is never used (CS0414) (MyProject)

    This is a very simple UI in which I dynamically add to a StackLayout using the value that is in the optionName Entry control.

    Is there a better way to do this? Or is there a way to suppress the CS0414 error?

    Friday, June 12, 2015 2:38 PM

Answers

  • User63097 posted

    You may have your own reasons not to do it this way, but, personally I wouldn't pass the Entry.Text in to the command that way. Instead I would bind the Text property of the entry to a property in the ViewModel and have the command execute delegate read that property directly - that way you don't need the CommandParameter attribute in your Button, and you don't need to give the Entry a name (removing the compiler warning).

    Thanks, Paul.

    • Marked as answer by Anonymous Thursday, June 3, 2021 12:00 AM
    Friday, June 12, 2015 4:05 PM
  • User181 posted

    It should be perfectly valid to bind controls to values of other controls though.

    It is valid (though I also strongly endorse Paul's suggestion), but the compiler has no way of knowing what you're doing to avoid the warning with the approach you're currently using. What's happening is that the x:Name attribute is used at build time to add a field to the class, but the bindings are evaluated dynamically at runtime using reflection. So the compiler sees a private field that is assigned to but never used in any code it can see. It's going to warn you about that, and the only fix would be to write some code that uses that field.

    Again, I think the approach suggested by Paul is a much better way to go.

    • Marked as answer by Anonymous Thursday, June 3, 2021 12:00 AM
    Friday, June 12, 2015 6:59 PM

All replies

  • User66293 posted

    If you are using VisualStudio, you can use the SuppressMessage attribute MSDN: https://msdn.microsoft.com/en-us/library/ms244717.aspx

    Friday, June 12, 2015 2:47 PM
  • User55069 posted

    @NicolasHotterbeekx I'm using Xamarin Studio on a Mac at the moment. If I were using Visual Studio, though, it may still pose a problem as the partial class code file should be generated dynamically. I wouldn't want to globally suppress the warning either since it is useful when tracking down dead code.

    I'd be happy to put a suppression message in if it would work in Xaml, but I don't believe that it does. The only thing I can think of right now is to artificially use the field in the xaml.cs file.

    Friday, June 12, 2015 2:54 PM
  • User63097 posted

    You may have your own reasons not to do it this way, but, personally I wouldn't pass the Entry.Text in to the command that way. Instead I would bind the Text property of the entry to a property in the ViewModel and have the command execute delegate read that property directly - that way you don't need the CommandParameter attribute in your Button, and you don't need to give the Entry a name (removing the compiler warning).

    Thanks, Paul.

    • Marked as answer by Anonymous Thursday, June 3, 2021 12:00 AM
    Friday, June 12, 2015 4:05 PM
  • User55069 posted

    Thanks, I may go that route to get rid of the warning. It should be perfectly valid to bind controls to values of other controls though.

    Friday, June 12, 2015 4:14 PM
  • User181 posted

    It should be perfectly valid to bind controls to values of other controls though.

    It is valid (though I also strongly endorse Paul's suggestion), but the compiler has no way of knowing what you're doing to avoid the warning with the approach you're currently using. What's happening is that the x:Name attribute is used at build time to add a field to the class, but the bindings are evaluated dynamically at runtime using reflection. So the compiler sees a private field that is assigned to but never used in any code it can see. It's going to warn you about that, and the only fix would be to write some code that uses that field.

    Again, I think the approach suggested by Paul is a much better way to go.

    • Marked as answer by Anonymous Thursday, June 3, 2021 12:00 AM
    Friday, June 12, 2015 6:59 PM
  • User55069 posted

    Adam, I'll probably change the code just to get rid of the warning. Thanks for the suggestion guys!

    Friday, June 12, 2015 7:40 PM