(VS 2005 Beta)Illegal cross-thread operation

[Guest]

What I should do to return back the permissin I had in VS2003 , that allowd
me to access public methode of one Class from other Thread.

I have Class A(FORM) which create new thread (new class B), the new class
thread get as parameter reference to his father( CLASS who mad it (classA)),
The new thread need to call methodes from his father like myfathe.methode(),
This worked in VS 2003 but now in VS 2005 Beta throw an exception :

An unhandled exception of type 'System.InvalidOperationException' occurred
in System.Windows.Forms.dll

Additional information: Illegal cross-thread operation: Control
'Green_pictureBox1' accessed from a thread other than the thread it was
created on.
Stack trace where the illegal operation occurred was:

at System.Windows.Forms.Control.get_Handle()
at System.Windows.Forms.Control.SetVisibleCore(Boolean)
at System.Windows.Forms.Control.set_Visible(Boolean)
at Mynamespace.Test_Board_Main_Form.Green_originalimageI_Light(Boolean)
at Mynamespace.ExecuteThread.FirmwareUpdateDll()

 

[Jon Skeet [C# MVP]]

What I should do to return back the permissin I had in VS2003 , that allowd
me to access public methode of one Class from other Thread.

It's not that it's a class, it's that it's a UI class. Although
changing properties on UI elements from another thread would
*sometimes* work with .NET 1.1, it was still a *very bad idea*.

See http://www.pobox.com/~skeet/csharp/threads/winforms.shtml

I'm glad to see it's now being caught early rather than allowing broken
code to work sometimes.

 

[Richard Blewett [DevelopMentor]]

In VS2003 you were doing something Very Bad (tm). You we're updating the UI from the wrong thread which is not supported by the underlying windowing system. VS2005 now catches this to prevent you from shooting yourself in the foot.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

What I should do to return back the permissin I had in VS2003 , that allowd
me to access public methode of one Class from other Thread.

I have Class A(FORM) which create new thread (new class B), the new class
thread get as parameter reference to his father( CLASS who mad it (classA)),
The new thread need to call methodes from his father like myfathe.methode(),
This worked in VS 2003 but now in VS 2005 Beta throw an exception :

An unhandled exception of type 'System.InvalidOperationException' occurred
in System.Windows.Forms.dll

Additional information: Illegal cross-thread operation: Control
'Green_pictureBox1' accessed from a thread other than the thread it was
created on.
Stack trace where the illegal operation occurred was:

at System.Windows.Forms.Control.get_Handle()
at System.Windows.Forms.Control.SetVisibleCore(Boolean)
at System.Windows.Forms.Control.set_Visible(Boolean)
at Mynamespace.Test_Board_Main_Form.Green_originalimageI_Light(Boolean)
at Mynamespace.ExecuteThread.FirmwareUpdateDll()

 

[Willy Denoyette [MVP]]

Jon,

Note that it's only caught when running in the debugger, nothing has changed
in non debug mode.

Willy.

 

[Jon Skeet [C# MVP]]

Note that it's only caught when running in the debugger, nothing has changed
in non debug mode.

Interesting. I suppose that's reasonable on performance grounds. Let's
just hope people do actually run things at least once in debug mode

 

[Guest]

Since Microsoft Allowd such a bad thing, there are product doing this bad
think , It's is so bad that Microsoft don't alowd this any more , if this
true, Microsoft must inform all those companies about this , so they can
decide if to buy the new VS2005 or not, (if to continue use the bad usage or
to make new release with the fix..)
I think they should add an option to allowd this or not (my in security
option list).

 

[Richard Blewett [DevelopMentor]]

Well its *always* been a restriction in the WIndows UI and its been documented hundreds of times in different ways both nby Microsoft and others that you must not (repeast must not) interact with UI components from any thread other than the one on which they were created.

Of course this hasn't stopped people either not realising or ignoring this information. With .NET 1.x they decided to help people get it right by creating the InvokeRequired and BeginInvoke methods on all UI components. BeginInvoke marshalled a method call on to the correct UI thread. However, this didn't stop people not realising what they were there for or ignoring their existence.

So now they have decided to be more blunt and cause the UI elements to refuse to work in debug mode if people use them incorrectly - they are still allowing it in release builds (but thats just a performance optimization). If your code is failing in debug builds with this error then you have a nasty insideous bug in your code which you should fix. Your users will not thank you for giving them an application that crashes in non-reproducible ways for no apparent reason.

I think its a good thing when the tools show up a bug in your code - for example, would you prefer it if the compiler didn't tell you when you put = instead of ==? When people migrate to 2005 they will not be forced immediately to rebuild the app and deploy it for .NET version 2. They will have to make changes because of other API differences anyway - or at least go through a regression test cycle. So this is the opportunity to fix these bugs.

Regards

Richard Blewett - DevelopMentor
http://www.dotnetconsult.co.uk/weblog
http://www.dotnetconsult.co.uk

Since Microsoft Allowd such a bad thing, there are product doing this bad
think , It's is so bad that Microsoft don't alowd this any more , if this
true, Microsoft must inform all those companies about this , so they can
decide if to buy the new VS2005 or not, (if to continue use the bad usage or
to make new release with the fix..)
I think they should add an option to allowd this or not (my in security
option list).

 

[Jon Skeet [C# MVP]]

Since Microsoft Allowd such a bad thing, there are product doing this bad
think , It's is so bad that Microsoft don't alowd this any more , if this
true, Microsoft must inform all those companies about this , so they can
decide if to buy the new VS2005 or not, (if to continue use the bad usage or
to make new release with the fix..)
I think they should add an option to allowd this or not (my in security
option list).

No. It's not something that they've just disallowed - it's *always*
been dangerous, and it's always been talked about all over the place.
It's not like it's not documented. It's just that now in debug mode the
mistakes can be found more clearly.

Your code was broken under VS.NET 2003 - it just wasn't as *obviously*
broken.

 

[Willy Denoyette [MVP]]

Yes, I guess they didn't want to burn some CPU cycles for this in a release
built, the problem is that you shouldn't need to run in the debugger for
this to show up. I'm pretty sure most of us will only unit-test when moving
existing applications to v2.0 and 'problems' like this will simply pass the
test runs.
I just finished a code review for a large number of windows forms
applications, you would be surprised of the number of applications failing
to obey this UI threading rule. The reactions (some) of the (professional)
developers goes like this: "Oh, it's probably the debugger" or "normal, this
thing is still in beta, right" or "MSFT broke my code" or "Never heard about
this and it's not documented" etc.

Willy.

 

[Jon Skeet [C# MVP]]

Yes, I guess they didn't want to burn some CPU cycles for this in a release
built, the problem is that you shouldn't need to run in the debugger for
this to show up.
True.

I'm pretty sure most of us will only unit-test when moving
existing applications to v2.0 and 'problems' like this will simply pass the
test runs.

I guess that's a good reason to run unit tests in the debugger as well
as not. At least once

I just finished a code review for a large number of windows forms
applications, you would be surprised of the number of applications failing
to obey this UI threading rule. The reactions (some) of the (professional)
developers goes like this: "Oh, it's probably the debugger" or "normal, this
thing is still in beta, right" or "MSFT broke my code" or "Never heard about
this and it's not documented" etc.

Yes - scary, isn't it?

 

[Guest]

OK, I didn't try to run in Release mode, any way I thoght it is the easy way
to do what I had done,
I don't access the UI components directly , I use a public methode , I still
don't think this is a bad think since I mad a public methosd, those public
methodes access the components. Why this is a bad thing.
I have one function read from USB target, as you know if target didn't
transmit the data the host will keep asking for this data, So all I tried to
do is to make this function run in another thread and before start it I start
a timer to kill it when time is out. this function call an out funtion whitch
print out the data recived from USB .
the out is a UI thread which caled from the USB thread,

 

[Jon Skeet [C# MVP]]

OK, I didn't try to run in Release mode, any way I thoght it is the easy way
to do what I had done,
I don't access the UI components directly , I use a public methode , I still
don't think this is a bad think since I mad a public methosd, those public
methodes access the components. Why this is a bad thing.

But calling methods which access the components still means you end up
accessing the components from the wrong thread, doesn't it? That
violates the rules specified in the Control documentation.

I have one function read from USB target, as you know if target didn't
transmit the data the host will keep asking for this data, So all I tried to
do is to make this function run in another thread and before start it I start
a timer to kill it when time is out. this function call an out funtion whitch
print out the data recived from USB .
the out is a UI thread which caled from the USB thread,

Not sure what you mean by "the out". See
http://www.pobox.com/~skeet/csharp/threads/winforms.shtml for how to
invoke a delegate on the UI thread from a different thread.

 

[Willy Denoyette [MVP]]

You seem to confuse public methods with threads and I'm afraid you need to
spend some time to read about multithreading in a windows environment
a great place to start with is this: See
http://www.pobox.com/~skeet/csharp/threads/winforms.shtml.
The rule simple "don't directly access UI elements from code running on a
thread that doesn't own the UI elements"
In your case, you call a "public method" from a non UI thread (your USB
thread), in this method you directly update the UI elements and THIS IS A
BAD thing in windows programming.

Willy.

 

[Guest]

Thanks

You seem to confuse public methods with threads and I'm afraid you need to
spend some time to read about multithreading in a windows environment
a great place to start with is this: See
http://www.pobox.com/~skeet/csharp/threads/winforms.shtml.
The rule simple "don't directly access UI elements from code running on a
thread that doesn't own the UI elements"
In your case, you call a "public method" from a non UI thread (your USB
thread), in this method you directly update the UI elements and THIS IS A
BAD thing in windows programming.

Willy.

 

[Ian Griffiths [C# MVP]]

By the way, the reason they allow such code to run fine when it's outside
the debugger doesn't have anything to do with burning CPU cycles. It is to
make sure that existing code that has this problem works exactly as well as
it did with the previous release.

So any code that does this thing (which, as has been pointed out has always
been very bad - it's not that they allowed you to do it before, it's just
that it tended to crash in less obvious ways) will carry on working as
before outside of the debugger. But in the debugger it now tells you
straight away that there's a problem.

Since Microsoft Allowd such a bad thing,

They didn't. Code that did this breaks eventually today. In release mode
it will be no more or less unreliable with VS.NET 2005 than it was before.

there are product doing this bad think

Yes, and such products have a lot of problems. This hasn't changed in
VS.NET 2005 - products can still do this and will still have as many
problems as they did before when they run outside the debugger. And now, if
they happen to be in the debugger, they'll be told what they've done wrong.

So this is a case of the debugger doing a better job of telling you when
something is going wrong. This is a good thing.