Refactoring vs. Procedural Code: Would you refactor this?

When my application starts, it sets in motion a process by which an event is received back at the main form. It's an event that's common enough (let's say, "Maximize Window") but the first time I receive it, I have to process it in a special manner. So, I have code like this:

 class MyMainForm{  ... big long complex code ...  bool firstTimeThroughEventHandler = true;  void MyEventHandler(object o, EventArgs e){   lock(this){     if(firstTimeThroughEventHandler == true)     {      firstTimeThroughEventHandler = false;      ... one time code ...     }    }  }  ... lots more code ... }

So this is just begging for refactoring, right? You have one-time behavior, an instance variable used as a flag, a (slight) performance hit that is not needed 99.9% of the time, etc.

But the thing is, I can't shake the feeling that anything I do to refactor it will make the code less clear. Of course I can refactor a new class to hold the event handler, and attach and detach it to the event, and, y'know, yeah, fine. But, geez, adding a class to a project introduces a mental burden, too, one that seems to me at least as great as "oh, that variable's a flag that's used by that event handler. It doesn't mean anything anywhere else."

Also, note that I don't have any other behavior in the event handler. If it were "if firstTimeThrought { code }else{ other code}" the decision to refactor would be easy. But this is trivial cyclomatic complexity: 1 entry point, 1 decision, 1 exit point.

What do you think?