Peter Duniho's C# blog - All Comments

re: MSDN's canonical technique for using Control.Invoke is lame

Bill — Thu, 18 Apr 2013 21:31:24 GMT

thanks

I understand a little more now, but absolutely definitely my code works without crashing!!!

re: MSDN's canonical technique for using Control.Invoke is lame

Peter — Tue, 27 Apr 2010 16:37:05 GMT

I have not seen the behavior you describe. It's possible that the Control.Invoke() method had a bug that was fixed between .NET 2.0 (the version in which you say that happens) and .NET 3.5 SP1 (the version in which I checked).

And to be clear: such behavior would in fact be a bug. Control.Invoke() should not fail silently. It either should invoke the delegate, or it should throw an exception. Failing to invoke the delegate but not throwing an exception would be unacceptable behavior.

Note that the situation described in the Form.Close() method docs is when the MDI child has already been hidden and you call Close(). So I suppose it's possible that the bug was intentional in a previous version of .NET. But in the versions I'm testing with, even closing the MDI child when it's been hidden first doesn't change the behavior: the form is still disposed, and attempting to invoke a delegate after the form has been disposed causes an exception to be thrown.

If you have a concise code example that demonstrates the behavior you're describing, especially if you can confirm that the behavior still exists in .NET 3.5 SP1 or later, please feel free to post it here.

re: MSDN's canonical technique for using Control.Invoke is lame

A J — Tue, 27 Apr 2010 13:56:15 GMT

Sorry, I wrote that comment off in a hurry late last night. I will try to be clearer with stating my observations.

However, at a basic level, we seem to be in agreement that there is more going on than a direct call to the delegate method when Invoke() is called from the UI thread that owns the control.

I would also like to add that my observations were made with the .NET 2.0 framework.

MDI child windows don't behave the same way as normal forms when it comes to closing them (for the purpose of this discussion, I am not considering dialog windows, i.e. ShowDialog()). As can be seen from the documentation here (msdn.microsoft.com/.../system.windows.forms.form.close.aspx) closing a normal form ends up disposing it as well, whereas closing an MDI child form does not dispose it directly always.

When I call Invoke() from a background thread and the target is an MDI child window (i.e. Invoke() is called over an MDI child form) and the MDI child window has not been closed yet, the delegate call is marshaled into the UI thread of the MDI child window (as should be).

If the MDI child form is already closed by the time Invoke() is called from the background thread, the invocation fails with InvalidOperationException (as should be).

When Invoke() is called from the UI thread of the MDI child form itself (i.e. in a situation where Invoke() is not required), the invocation behaves like a direct call to the delegate (again, as should be).

However, when Invoke() is called from the UI thread of the MDI child form and the MDI child form has already been closed, the delegate method does NOT fire and an InvalidOperationException is NOT thrown. This is a result that I was not expecting - I was thinking (fairly reasonable thought, I think) that Invoke() would directly call the delegate method in this case. This is what made me conclude that there is more going on with Invoke() than just a direct call to the delegate method when Invoke() is not required.

Hope that states my observations more clearly.

Any thoughts on this?

re: MSDN's canonical technique for using Control.Invoke is lame

Peter — Tue, 27 Apr 2010 08:58:30 GMT

I am not sure what you're trying to say.

MDI child forms behave the same way that regular forms do: if not shown with the ShowDialog() method, then when the form is closed, first the FormClosed event is raised, during which the form has not yet been disposed and calls to Invoke() work normally, and then the Disposed event is raised, as the form is actually disposed, after which time calls to Invoke() would fail as would most other attempts to access the members of the form instance.

It is not correct that closing an MDI child form does not dispose it, nor is it correct that if you call Invoke() before the form is disposed (in a handler of the FormClosed event, for example) that the invoked delegate is not executed.

To confirm this, I tested using both .NET 3.5 and 4.0.

Taken at it's simplest, it is true that "there is more going on than directly calling the method when Invoke() is not required", but only in the sense that the Invoke() method does do more than just call the method (a lot more, some of which is the equivalent of checking InvokeRequired).

I am not aware of any scenario in which one could successfully execute code by checking InvokeRequired and skipping the call to Invoke() when the property returns false, but not by calling Invoke() directly. In particular, if calling Invoke() would fail, it's because the form has been disposed and the call would throw an exception, in which case whatever code might have ever needed the call to Invoke() in any situation would also throw an exception (because the things in a form that require Invoke() are also the things that don't work if the form has been disposed).

If such a scenario does exist, closing an MDI child isn't it. Calling Invoke() before the form is actually disposed works fine (e.g. in the FormClosed event handler), and attempting to call it after simply fails as one would expect (an InvalidOperationException is thrown).

re: MSDN's canonical technique for using Control.Invoke is lame

A J — Tue, 27 Apr 2010 04:47:43 GMT

Not sure calling Invoke() when it is not required directly calls the method.

For example, after closing an MDI child form (closing an MDI child form does not dispose it) if you call Invoke() over the form, the delegate method is not called (a breakpoint set there does not get hit). If Invoke() were called before the MDI child form was closed, the delegate method does get called (breakpoint would get hit).

There is more going on than directly calling the method when Invoke() is not required.

re: MSDN's canonical technique for using Control.Invoke is lame

Peter — Thu, 01 Apr 2010 03:47:25 GMT

That's true. But not really relevant to the article.

re: MSDN's canonical technique for using Control.Invoke is lame

James H. Hansen — Fri, 15 Jan 2010 16:31:19 GMT

The Invoke method cannot be called until the window handle is created. Hence it will fail when initializing the text in a control before displaying the window.