I'm currently debugging a wired problem in our .NET application. We are dynamically plugin together Forms and Controls as a reaction to certain server events. Communication with the server is done in threads of course. All UI elements are manipulated via Control's Invoke Mechanism.
I still get cross thread exceptions though. In some child controls the InvokeRequired property is true, although their parent's InvokeRequired property is false. So these children must have been created outside the main thread. I'm currently looking for threads that may lead to this erroneous Control creation. As you can see in the screenshot of Visual Studio's thread view there are lots of worker threads called "mainX" (these are just some of them) and I have no idea where they came from.
Is this some kind of standard naming pattern for "old" main threads? Maybe due to - I don't know - multiple calls of Application.Run or something like that?
Any advice is welcome!
Edit (To sum things up)
I have a root Control with InvokeRequired == false and some child controls with InvokeRequired == true. How is that even possible? root.Controls.Add(child) should have already thrown an exception.
Is anybody aware of a reason that leads to the naming pattern for threads as shown in the screenshot?
Answer
I think what might be happening is that you are somehow checking a Control's InvokeRequired property before the control has created its handle. If you do that, InvokeRequired will return false, even if it's a separate thread.
You can check this by inspecting Control.IsHandleCreated, so you can at least find out if this is what's happening. Fixing it if that is indeed what is happening is something else, though...
No comments:
Post a Comment