HALP with events



  • Okay, so, I know a lot about C#, and I'm totally fine with events normally. But there's this awful thing I made, and I don't know what to do about it.

    protected void Subscribe(TypeFromPlace1 place1Field, TypeFromPlace2 place2Field, string propertyName)
    {
      bool changing = false;
      place1Field.ValueChanged += (sender, args) =>
      {
        if (changing)
          return;
    
        changing = true;
        place2Field.Value = place1Field.Value;
        RaisePropertyChanged(propertyName);
        changing = false;
      }
      place2Field.ValueChanged += (sender, args) =>
      {
        if (changing)
          return;
    
        changing = true;
        place1Field.Value = place2Field.Value;
        changing = false;
      }
      place2Field.Value = place1Field.Value;
    }
    

    As you can probably tell, I'm using a closure to lock the changes and prevent a stackoverflow. But I need to be able to unsubscribe from the event... Is my only option a static bool? Afaik, this works as a static bool for each property pair currently.



  • I mean, I could possibly make a dictionary with the properties as keys, and assign the delegates to that so I can unsubscribe later... That at least wouldn't be static, but it still feels awful.



  • Don't use delegates and then you can ubsubscribe easily.



  • @coldandtired said:

    Don't use delegates and then you can ubsubscribe easily.

    Yes, I know, but I benefit from the locking mechanism provided by the closure.



  • @coldandtired said:

    Don't use delegates

    Lambdas, shirley?

    AFAIR, you can assign lambda to a delegate and then use that. You'd still need to keep track of them, though.



  • Yeah, I definitely like that idea better than anything else I've managed to come up with. I don't like it much even then, but it's better than nothing.



  • Indeed. That's what happens when I construct sentences while hoovering 😄



  • I see a stack overflow from "Echos"...if that is what you are dealing with, just check the values first...that should be sufficient.... Of course, you may be attempting to do something else...



  • I basically have two separate libraries that have objects that notify something when they change, and I need to make each of them update the other when one changes, but not update the first again - which would overflow the stack.



  • [code]
    if (target2.Value != target1.Value) target2.Value = target1.Value;
    [/code]
    This should actually be inside the library code, if it was well written, and was intended to create notifications when something CHANGED. If you are having stack problems, it is likely that the events are being fired just because a property was written to (even if it does not trigger an actual change in state).

    Of course, real code that repro's the situation would be getter than guessing....



  • Make another closure for unsubscribing at the end of Subscribe and return it.



  • It's all weird, and you're right that that would probably work, but I'm not risking a probably.



  • @Magus said:

    you're right that that would probably work, but I'm not risking a probably.

    Write a proper set of tests. Then (nearly) zero risk - there is some risk in everything, even breathing.


Log in to reply