MSDN's canonical technique for using Control.Invoke is lame
While I'm on the subject of using the Control.Invoke method, I'd like to mention a pet peeve of mine. That is, the technique that everywhere on MSDN is proposed for dealing with using that method.
In particular, according to Microsoft, the preferred technique is to write one method that does two completely different things, depending on the value returned by the Control.InvokeRequired property. If the property is true, then Invoke is called using the same method as the target, and if it's false, then whatever code was really desired to execute is in fact executed. It looks like this:
void DoSomethingMethod()
{
if (InvokeRequired)
{
Invoke((MethodInvoker)DoSomethingMethod);
}
else
{
// actually do the "something"
}
}
Now, I'm not a big fan of methods that do more than one thing in any case. It's my opinion that a method should do one thing and do it well. There are exceptions to every rule of course, but they are few and far between. More importantly, the above pattern does not rise to the requirements of being such an exception.
To understand why, consider what happens if you call Invoke when InvokeRequired returns false. The designers of .NET could have implemented it to throw an exception if you try to call Invoke when not necessary. But there's no obvious reason that they should have, nor did they. In fact, the Invoke method will "do the right thing" in that case, and simply invoke the target delegate directly rather than trying to marshall it onto the thread that owns the Control instance.
Note that the Invoke method can't just always do the marshaling. It has to know whether doing so is necessary, because if it tried to marshall the invocation when it wasn't necessary, it would wind up stuck waiting on the marshaled invocation to happen, which it never would because it's waiting using the same thread that's needed for the invocation.
So Invoke simply invokes the target directly, and to decide to do this it checks the same state your own code would be checking when it looks at the InvokeRequired property.
In other words, by using the MSDN-prescribed pattern, you're duplicating the exact same effort that already is made by the .NET Framework.
My opinion is that it's better to not have the redundant code, and to take advantage of the fact that .NET is already doing what MSDN proposes you do: just always call Invoke and let .NET sort it out. Now, you may be thinking "but if I always call Invoke using my own method as the target, won't that cause an infinite recursion?" Yes, it would, so don't do that. 
Instead, take advantage of C#'s anonymous methods, wrapping all of your invoked logic inside one and invoke that:
void DoSomethingMethod()
{
Invoke((MethodInvoker)delegate
{
// actually do the "something"
});
}
Note: I prefer anonymous methods for this situation, but some may prefer a lambda expression instead, and especially if what you're invoking actually returns some value, it might even be more expressive to use that. A lambda expression is a fine alternative to an anonymous method, and winds up compiled to basically the same thing.
One final thought: don't judge Microsoft too harshly for promoting their inefficient approach so broadly. It's unfortunate that new examples continue to be created, and that the newer versions of the documentation haven't been changed to replace the older examples. But prior to C#/.NET 2.0, using an anonymous method in the invocation just wasn't an option.
I wasn't using .NET in those early days, and even then I would not have used the "one method, two behaviors" technique. Instead, I would have broken the functionality into two different methods, one that invokes the other. But the MSDN-promoted technique is less inappropriate in that context; in fact, it was as close as they could come to the benefit that anonymous methods offer of keeping all the functionality in a single method. Since I value that feature of anonymous methods so highly, I can hardly fault them for striving for that goal even when they didn't have anonymous methods to use.