WndProc override is not consistently catching messages C#

Question

So I am encountering a very weird bug/timing issue, so I simplified the below code to show exactly what's happening. It works perfectly in debug stepping through it, but does something weird running without breakpoints.

in my MainForm I'm catching taskbar clicks

    const int WM_ACTIVATEAPP = 0x1C; 
    int count = 0;
    protected override void WndProc(ref Message m)
    {
     if (m.Msg == WM_ACTIVATEAPP)
        {
         if (m.LParam.ToInt32() == 2504)
            {
               using (StreamWriter writer = new StreamWriter("C:\\log.txt", true))
                {
                    count++;
                    writer.WriteLine(count);
                }
            }
        }
     }

m.LParam.ToInt32() == 2504 means the program was clicked in the task bar.

if I put a breakpoint on "using (StreamWriter...", run debug and single click 10 times (having to f5 in compiler after each), I will have 1-10 appear in the log.

If I take off the break point and single click once every few seconds 10 times total (same as above), I've ended up with 1-2, 1-4, but never any more.

With no breakpoint and 10 quick double clicks it will log 1-20, every time.

Answer 1

m.LParam.ToInt32() == 2504 means the program was clicked in the task bar.

I have no idea why you think that, or where you got the magic number 2504.

What MSDN actually says is

If the wParam parameter is TRUE, lParam is the identifier of the thread that owns the window being deactivated. If wParam is FALSE, lParam is the identifier of the thread that owns the window being activated.

Thread identifiers can change every time you run the program, so it isn't surprising at all that you don't see this number consistently.

---

If you are asking how there can be more messages than clicks, it is because WM_ACTIVATEAPP is sent both coming and going. You're ignoring wParam which allows you to tell the difference.

If you are wondering why breakpoints change the behavior, it is because lParam depends on "the other window". Breakpoints cause the debugger window to be activated, so the sequence of windows receiving focus changes.