Write-only property




  • public bool InvokePropertyChangedEvent
    {
    set
    {
    OnPropertyChanged(new PropertyChangedEventArgs("InvokePropertyChangedEvent"));
    }
    }

    This is called like so: x.InvokePropertyChangedEvent = true;.

    Basically, they couldn't figure out how to simulate a PropertyChangedEvent without changing a property, and this is what happened.



  • @configurator said:

            public bool InvokePropertyChangedEvent
    {
    set
    {
    OnPropertyChanged(new PropertyChangedEventArgs("InvokePropertyChangedEvent"));
    }
    }

    This is called like so: x.InvokePropertyChangedEvent = true;.

    Basically, they couldn't figure out how to simulate a PropertyChangedEvent without changing a property, and this is what happened.

    Now if the property type was PropertyChangedEventArgs or even the constructor argument for same...it would be interesting...


  • sockdevs

    @configurator said:

            public bool InvokePropertyChangedEvent
    {
    set
    {
    OnPropertyChanged(new PropertyChangedEventArgs("InvokePropertyChangedEvent"));
    }
    }

    This is called like so: x.InvokePropertyChangedEvent = true;.

    Basically, they couldn't figure out how to simulate a PropertyChangedEvent without changing a property, and this is what happened.

     

    Is OnPropertyChanged visible outside the class? I know a lot of these methods are often declared <font face="courier new,courier">protected override</font> or <font face="courier new,courier">protected virtual</font>.

     



  • This reminds me of write only registers on custom hardware.



  • @RaceProUK said:

    Is OnPropertyChanged visible outside the class?

    Does that matter? InvokePropertyChangedEvent should be a method, not a setter.


  • sockdevs

    @configurator said:

    @RaceProUK said:
    Is OnPropertyChanged visible outside the class?

    Does that matter? InvokePropertyChangedEvent should be a method, not a setter.
     

    Yes, it does matter.



  • @RaceProUK said:

    @configurator said:
    @RaceProUK said:
    Is OnPropertyChanged visible outside the class?
    Does that matter? InvokePropertyChangedEvent should be a method, not a setter.
    Yes, it does matter.
    If they're using the same MSDN sample code for handing PropertyChangedEvents that's been around since 2002, then no, it's protected. But either way, a) why is InvokePropertyChangedEvent a property when a method fits better with both the action and the name? b) Why don't they raise the visibility of OnPropertyChanged to public? It's in the source code... c) Why are they sending PropertyChangedEvents that say that no property they actually store a value for is changed?


  • sockdevs

    @TwelveBaud said:

    @RaceProUK said:
    @configurator said:
    @RaceProUK said:
    Is OnPropertyChanged visible outside the class?
    Does that matter? InvokePropertyChangedEvent should be a method, not a setter.
    Yes, it does matter.
    If they're using the same MSDN sample code for handing PropertyChangedEvents that's been around since 2002, then no, it's protected. But either way, a) why is InvokePropertyChangedEvent a property when a method fits better with both the action and the name? b) Why don't they raise the visibility of OnPropertyChanged to public? It's in the source code... c) Why are they sending PropertyChangedEvents that say that no property they actually store a value for is changed?
     

    a) The handler being tested is OnPropertyChanged, so why not?
    b) Because they'd have to remember to change it back again
    c) Because they're testing the handler without wanting to change object state



  • @RaceProUK said:

    a) The handler being tested is OnPropertyChanged, so why not?
    b) Because they'd have to remember to change it back again
    c) Because they're testing the handler without wanting to change object state
    Why are you so quick to assume that they're testing?


  • sockdevs

    @TwelveBaud said:

    @RaceProUK said:
    a) The handler being tested is OnPropertyChanged, so why not?
    b) Because they'd have to remember to change it back again
    c) Because they're testing the handler without wanting to change object state
    Why are you so quick to assume that they're testing?
    Who says they aren't?



  • @RaceProUK said:

    Who says they aren't?

    They aren't :-(


  • sockdevs

    @configurator said:

    @RaceProUK said:
    Who says they aren't?

    They aren't :-(

     

    In that case they are fools of the greatest impertinence, and must be vanquished forthwith.



  • @RaceProUK said:

    In that case they are fools of the greatest impertinence, and must be vanquished forthwith.
     

    Their approach to testing suggests that Darwinism will soon sort that.

     



  • @Cassidy said:

    Filed under: Lick these battery terminals

    Get them to try it with a car battery, though if their tongue can bridge the terminals on one of those, then they can probably make a lot more money in a different career...



  • Only if they can breathe through their ears...


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.