none
"Cross-thread operation not valid" Exception, but it's not cross threaded... RRS feed

  • Question

  • Hi all,

    I'm currently getting an exception that reads "Cross-thread operation not valid: Control 'KSTextBox' accessed from a thread other than the thread it was created on.". I'm well aware of using delegates and Invoke or BeginInvoke to access a control from the correct thread when it is created on a different thread, however this particular occurrence has me stumped.

    I'm working on a few controls that implement in-place editing. When you click on an item to edit in a control, it instantiates another control with which to edit the item. The editing control contains a RichTextBox control that it instantiates in its own contructor.

    When I click on the main control, the MouseUp event triggers the editing, and the edit control is created along with its textbox control. The edit control is then added to the main control's "Controls" collection, which triggers the edit control's OnCreateControl event. In this event I set the Bounds of the textbox, which throws the exception. It doesn't seem to happen the first time through the process either, only after I've done in place editing at least once (even though the editing control and children are disposed of and nulled after each edit).

    The InvokeRequired property of the editing control is false, but is true for the textbox, even though the textbox is instantiated in the editing control's constructor. I set the current thread's name when creating the textbox and it is the same as the current thread when the exception is thrown. How could I possibly be getting an illegal cross thread operation exception?

    I tried invoking before changing the textbox bounds, but the edit control accesses its textbox in a lot of places and it's simply not practical to have a separate method that can be referenced by a delegate for every textbox property and method accessed.

    Thanks.
    Friday, February 15, 2008 2:09 AM

Answers

  • Do you have the STAThread attribute applied to your main method?  Some controls, like the rich text box are actually OLE controls and therefore do not necessarily work like regular controls when it comes to threading.

     

    Michael Taylor - 2/15/08

    http://p3net.mvps.org

     

    Friday, February 15, 2008 2:49 PM
    Moderator
  •  

    The link still works for me. Try a different browser? If you have the same issue then in summary InvokeRequired has a bug that causes it to "lie" and you need a work around. Off the top of my head you can just put "IntPtr myHandle = this.Handle;" at the top of your forms in the constructor. Yes it really fixes it by just setting a variable reference. Crazy stuff.

     

    Cheers

    Tuesday, May 20, 2008 3:49 AM

All replies

  • Do you have the STAThread attribute applied to your main method?  Some controls, like the rich text box are actually OLE controls and therefore do not necessarily work like regular controls when it comes to threading.

     

    Michael Taylor - 2/15/08

    http://p3net.mvps.org

     

    Friday, February 15, 2008 2:49 PM
    Moderator
  • Thanks for your reply Michael.

    I do have the STAThread attribute applied to my main method. Should this solve the problem or could it cause it? More importantly, since I'm building a control library, I can't expect to have control over attributes on main methods. Is there any solution other than dumping the rich text box?

    Thanks again.
    Monday, February 18, 2008 11:54 PM
  • To troubleshoot this issue, we really need the source code and the detailed repro steps to reproduce the problem, so that we can investigate the issue in house. It is not necessary that you send out the complete source of your project. We just need a simplest sample to reproduce the problem. You can remove any confidential information or business logic from it.


    You can send a sample project and repro steps in details to may email address which can be found in my personal profile page.

    Tuesday, February 19, 2008 4:42 AM
  • OK, I'll get it to you as soon as I can. Thankyou.

    In the meantime, here's some food for thought... I was using my controls for in-place editing in the DataGridView control, and under certain conditions they simply wouldn't appear after the first edit. I guess this exception was causing the issue, except I couldn't figure it out as the datagrid was eating the exception.
    Tuesday, February 19, 2008 5:08 AM
  • Pickle, I'll bet this is a similar issue to what I was experiencing. It basically comes down to InvokeRequired lying.

     

    http://ikriv.com:8765/en/prog/info/dotnet/MysteriousHang.html

     

     

    Thursday, May 15, 2008 8:06 PM
  • Hi tsoft, I'm having issues viewing your link. Is it still alive?

    Thanks.
    Tuesday, May 20, 2008 2:03 AM
  •  

    The link still works for me. Try a different browser? If you have the same issue then in summary InvokeRequired has a bug that causes it to "lie" and you need a work around. Off the top of my head you can just put "IntPtr myHandle = this.Handle;" at the top of your forms in the constructor. Yes it really fixes it by just setting a variable reference. Crazy stuff.

     

    Cheers

    Tuesday, May 20, 2008 3:49 AM
  • When you call a delegate synchronously, the Invoke method calls the target method directly on the current thread.
    If the BeginInvoke method is called, the common language runtime will queue the request and return immediately to the caller. The target method will be called on a thread from the thread pool. The original thread, which submitted the request, is free to continue executing in parallel to the target method, which is running on a thread pool thread.

    http://msdn.microsoft.com/en-us/library/22t547yb(VS.71).aspx

    Ali
    Tuesday, May 20, 2008 6:43 AM
  • Thanks tsoft. No wonder I couldn't track down the problem.

    Thanks for your reply Ali, but I understand how Invoke and BeginInvoke work. This problem was a little bit deeper (as tsoft said, crazy stuff).
    Tuesday, May 20, 2008 6:48 AM