Well, the premice is simple : in a user event (a key down in my case), I stop a timer, and put back some members to null. From this point, I expect that no more tick events will occur (cause members are null and I don't want to check for that in the handler).
So I was just reflecting on that and was wondering : if the timer elapses WHILE i am processing the key down message, just before the Timer.Stop() is executed, I believe a timer message will be posted in the message queue, waiting to call my handler.
So I was wondering if Timer.Stop() takes care of that case. I was wondering if there is some sort of guaranty that this cannot happen.... And I could'nt find the anwser in Microsoft doc !!
So, I have run into this same problem many times and have never quite understood its cause. It doesn't seem that it is an issue with queued messages, in my case the time never stopped at all after calling the "Stop()" method. So, I disconnect the event handler, call Stop, and then set the timer to null. This did the trick though it is really a hack and I would like to understand the cause if possible.
If you liked my post go ahead and give me an upvote so that my epee.... ahem, reputation will grow.
Well, I don't know if the Timer's behavior can be customized in this particular way, but the problem can be solved using a guard bool field - in conjunction with a guard condition, around the relevant code. Once what needed to be done is done, you change the value of this bool field, and from that point on the guarded code will not be executed even if the Timer does raise another Tick event.