Well, it looks like this MDA was cut from the list and can no longer be
controlled from outside a managed debugger like msdb or vs debugger. That
means that this MDA is on by-default under the debugger and off otherwise,
you can no longer control this through an environment variable, registry or
config file setting.
Others that were cut (though still in the list), are PInvokeLog and
QueryInterface MDA. It looks like these (and probably some other too) have
been removed very late in the beta process, I've usefully used the
Illegalcrossthreadcall MDA in beta2. I need to spend some time on this to
find out what still available in the relase version of V2.
Willy.
"William Stacey [MVP]" <wi************@gmail.com> wrote in message
news:uD**************@TK2MSFTNGP09.phx.gbl...
| Thanks Willy. Which one of the MDAs does this? I looked at the list and
| could not find one that seemed to match.
|
| --
| William Stacey [MVP]
|
| "Willy Denoyette [MVP]" <wi*************@telenet.be> wrote in message
| news:e8**************@TK2MSFTNGP12.phx.gbl...
|| Note that this is only true when running in debug mode, there is no such
|| check done when running a release build, so you won't get the exception.
| The
|| check is done by the CLR (where it's called a Managed Debugging Assistant
| or
|| MDA) and is quite expensive as it has to compare the thread ID of the
| thread
|| that accesses a window handle to the thread ID of the creator (the UI
|| thread) of the handle, that's why it's only done when debugging or when
| you
|| explicitly enable the MDA. Search the docs for MDA if you want to enable
|| this (or other MDA's) for release builds as well.
||
||
|| Willy.
||
||
|| "Brian Gideon" <br*********@yahoo.com> wrote in message
|| news:11*********************@e56g2000cwe.googlegro ups.com...
||| Chris,
|||
||| In addition to forms and controls not being thread-safe they also have
||| thread affinity requirements. They must only be accessed on the thread
||| that created them. Typically, that's the main UI thread. In .NET 1.0
||| and 1.1 you could access the control from another thread and it would
||| appear to work fine at least some of the time. However, the behavior
||| was unpredictable. I frequently observed the problems manifesting
||| themselves when a control would unexpectedly appear as a large red X
||| with a white background. In .NET 2.0 Microsoft decided to throw an
||| exception if a control was accessed from another thread immediately
||| informing the developer of a bug. That may be the exception you're
||| thinking of, but it isn't thrown by Control.Invoke.
|||
||| Brian
|||
||| Chris S. wrote:
||| > I've read on this thread:
||| >
||| >
||
|
http://groups.google.co.uk/group/mic...52b054bb9ac568
||| >
||| > about .NET 2.0 throwing exceptions with Control.Invoke. This is
||| > probably the threading changes I was told about. But doesn't .NET 1.1
||| > do this already when the thread doing the UI update hasn't got a
handle
||| > (and no InvokeRequired is used)?
|||
||
||
|
|