Unsubscribing / Subscribing Events dangerous?

Question

Initially this question brought me here: Disable firing TextChanged event

I wondered if jtmach's answer is "clean":

   private void mytextbox_LostFocus(object sender, RoutedEventArgs e)
    {
      this.mytextbox.TextChanged -= this.myTextBox_TextChanged;

      if(textbox.Text.ToString().Contains('.'))
      {
             textbox.Foreground = new SolidColorBrush(Colors.Gray);
             textbox.Background = new SolidColorBrush(Colors.White);
      }

      this.mytextbox.TextChanged += this.myTextBox_TextChanged;    
    }

Is it OK to unsubscribe TextChanged-events in another event like this?

Or is it prone to errors because during the LostFocus the TextChanged event could be called (either by the user or by the program)?

That's just me, but I'd use a flag (ie: `if(IsProcessing) return;`), a lock or a sort of throttler of some sort (akin to the one in the Reactive Library). — Simon Belanger, Jun 26 '13 at 16:33
I personally would use something like the accepted answer for that question. I only remove handlers when I am disposing of dynamic controls that I assigned handlers to. — Mark Hall, Jun 26 '13 at 16:34
This is ok. And no the textchanged can't be called from lost focus... or at least I don't see how — Rémi, Jun 26 '13 at 16:34
@SimonBelanger Me too, that's why I wondered if this could fail ;) — Fabian Bigler, Jun 26 '13 at 16:34
@MarkHall How would you reason that? Unsubscribing events is not that expensive and it's readable too. — Fabian Bigler, Jun 26 '13 at 16:35
Also, and please correct me if I'm wrong I haven't used Winform for a while, but would it be possible that two event are fired at the same time that would essentialy remove the handler twice and then add it twice? — Simon Belanger, Jun 26 '13 at 16:36
@FabianBigler, in my mind there is no need to assign/reassign. it is just one more thing to keep track of. I don't think it will be problem though if you did, there will be no error if the method isn't there. — Mark Hall, Jun 26 '13 at 16:38
@SimonBelanger AFAIK that is not possible (If it's a single-threaded application) — Fabian Bigler, Jun 26 '13 at 16:41
Good point. I keep forgetting about single-threaded environment. — Simon Belanger, Jun 26 '13 at 16:44
There's an accepted answer on that question. It deserved the votes and the answer mark. — Hans Passant, Jun 26 '13 at 16:59
@HansPassant The benefit from unsubscribing and subscribing events is that it also works for multiple textboxes, instead of having to manage a List / Dictionary for this task. — Fabian Bigler, Jun 26 '13 at 17:33
@HansPassant Also, the other answers were added after the PO edited his question (For handling multiple Textboxes). And IMHO it's always better to reflect things rather than just accept them. — Fabian Bigler, Jun 26 '13 at 17:36

score 2 · Answer 1 · answered Jun 26 '13 at 16:41

If this were in a multi-threaded context then it would be a problem. It would be possible for the TextChanged event to be currently running when you unsubscribed, thus preventing you from making the assumption that it's running while this code is also running.

That said, in this case both methods will always be running in the UI thread, so while this code won't really be "broken" (you couldn't be running the text changed event simultaneously because the UI thread can only be running one of the two events at one time anyway) but it also doesn't serve a purpose and can just be removed (because the event can't be fired while this event handler is running because it's blocking the UI thread).

Unsubscribing / Subscribing Events dangerous?

1 Answers1