By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
448,958 Members | 1,165 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 448,958 IT Pros & Developers. It's quick & easy.

Cross-thread operation not valid: Control '' accessed from a thread other than the thread it was created on

P: n/a
Joe
I've been getting this message at all different times since a few days ago.
I understand the message but not why I get it. I don't have any other
threads.

This happens when closing dialog boxes, doing a drag and drop and a few
other things which I don't remember right now.
It only happens while I'm running within the IDE and only seems to be on my
computer. We've tested the same thing on other machines running VS.2005 and
there is no problem.

Any ideas? I'm thinking I need to reinstall VS.

Thanks,
Joe
Mar 3 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Hello joe.

Reinstalling VS wont solve the problem.
The problem you are facing is because microsoft finally decided to
enforce strict restriction on cross thread acces of control..(i.e you
cannot acces the control from other threads than on which it was
created on)
There are two solutions for this..
1The lengthy and the better solution ..
Using the InvokeRequired property of the control.
Eg.
private void Form1_Load(object sender, EventArgs e)
{
if(InvokeRequired)
{
this.Invoke(new EventHandler(Form1_Load), new object[]
{sender, e});
return;
}
//Your code here...
}

2>
Just set the Control.CheckForIllegalCrossThreadCalls property to
false.
This willstop the exception being thrown but wont solve the problem.
I would recommend the first way.
Mar 3 '07 #2

P: n/a
Hi Joe ,

Amar has provided the detailed correct reply to you.

Note: Microsoft enforces this restriction to help us to detect the invalid
operation: accessing the UI control methods/properties from another thread.
This is the GUI threading rule, which is introduced by history reason(.Net
Winform controls encapsulates Win32 controls which are COM STA threading
model. This threading model requires the accessing to the controls can only
be allowed from the creating thread).

So the first solution is highly recommended and second way is turning off
the Microsoft's help.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Mar 5 '07 #3

P: n/a
Joe
Hi Amar,

I do not have any other threads in this application which could cause the
problem. We don't use BeginInvoke, ThreadPool or new Thread.

Like I said this just happened out of no where.

-Joe

"Amar" <am**************@gmail.comwrote in message
news:11*********************@j27g2000cwj.googlegro ups.com...
Hello joe.

Reinstalling VS wont solve the problem.
The problem you are facing is because microsoft finally decided to
enforce strict restriction on cross thread acces of control..(i.e you
cannot acces the control from other threads than on which it was
created on)
There are two solutions for this..
1The lengthy and the better solution ..
Using the InvokeRequired property of the control.
Eg.
private void Form1_Load(object sender, EventArgs e)
{
if(InvokeRequired)
{
this.Invoke(new EventHandler(Form1_Load), new object[]
{sender, e});
return;
}
//Your code here...
}

2>
Just set the Control.CheckForIllegalCrossThreadCalls property to
false.
This willstop the exception being thrown but wont solve the problem.
I would recommend the first way.


Mar 5 '07 #4

P: n/a
"Joe" <jb*******@noemail.noemailwrote in message
news:eO**************@TK2MSFTNGP02.phx.gbl...
Hi Amar,

I do not have any other threads in this application which could cause the problem. We
don't use BeginInvoke, ThreadPool or new Thread.

Like I said this just happened out of no where.
This message only shows up when running a debug version!
Are you sure your Main entry is marked [STAThread]?

Willy.

Mar 5 '07 #5

P: n/a
Hi Joe,

Sorry, it seems that we missed your "I don't have any other threads"
statement in the first post.

After giving a detailed reading to your post, I see you stated "It only
happens while I'm running within the IDE and only seems to be on my
computer".

Does this mean this error only displays while you are debugging it with
VS2005 or just press Ctrl+F5 to launch it from IDE? Do you use "Debug" or
"Release" configuration?

Do you mean if you moved this project to another machine, the problem will
not arise?

In this situation, while the exception is generated under VS2005 debugg, it
would be informative to examine the following 2 places:
1. Open "Threads" window to examine how many threads are there during the
exception and which thread is throwing this exception.
2. Open "Call Stack" window to determine the stack trace of this exception.

Note: to get the accurate stack trace, you may need to set the symbol path
correctly. To set the symbol server path in VS2005, you should input
"srv*c:\LocalSymbols*http://msdl.microsoft.com/download/symbols;" in the
Tools | Options | Debugging | Symbols as the directory. This will tell the
VS2005 debugger to lookup symbol from the Microsoft symbol server
"http://msdl.microsoft.com/download/symbols" and cache the downloaded
symbol in "c:\LocalSymbols" folder.

Additionally, there is a new feature named "Just My Code" which is enabled
by default in VS2005. This means that VS2005 will not load symbol for
non-user code assemblies, such as all .Net BCL assemblies. So you should
disable this "Just My Code" feature from Tools | Options | Debugging, and
uncheck "Enable Just My Code" check box.(the VS2005 IDE maybe need
close&re-open to enable the setting)

Below link contains more information regarding JMC feature:
"Is 'Just my Code' for you?"
http://blogs.msdn.com/greggm/archive...29/201315.aspx

To verify if the above 2 settings take effect, you may open "Module" window
after launching the application under debugger.

Note: symbol loading may require some time after you pressed F5, you may
check the "Output" window to verify the symbol loading process for each
modules.

Please paste above 2 windows information here so that we can give it an
analysis. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Mar 6 '07 #6

P: n/a
Hi Joe,

How about this issue now?

Have you reviewed my last reply to you? Have you managed to collect the
stack trace information regarding this error? If you still need any help or
have any concern, please feel free to tell me, thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Mar 12 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.