[Zooms]

Okay, so just a quick question. I've been hearing a lot that the option specified in the title,

Control.CheckForIllegalCrossThreadCalls = False

,
is bad practice to use while programming, but I've never really heard any more than just that.

So, if anyone would mind explaining what makes it so bad, or pointing me to a post that states why, it'd be very helpful!

Thank you!

This post has been edited by Zooms: 26 April 2012 - 01:25 PM

[m_wylie85]

yes it is bad practice. You see if you do this you are not fixing the problem but hiding the problem which mean your program could crash so please avoid doing this.

This post has been edited by m_wylie85: 26 April 2012 - 01:34 PM

[_HAWK_]

There are ways to delegate the work back to the thread.

Control.CheckForIllegalCrossThreadCalls is for debugging assistance not for a finished application.

[Zooms]

@m_wylie85 - How do you mean it hides it? What makes it more prone to crashing because of it?

@_HAWK_ - Why is it not for finished ones?

Sorry for the questions, I'm just trying to understand 'why', and not just that it is, heh

[_HAWK_]

Because you should not tell the compiler to not check them - it should or it will crash your app if the appropriate steps are not taken when multi-threading. The approach is using delegates to bring data from worker threads to the main UI thread to access controls.

[Zooms]

I can understand why to use delegates, so that two threads won't collide when updating an UI object, or a similar situation to that occurs.
But still, is there any downsides *except* that?

[_HAWK_]

I would say that is enough reason not to use it. Use the best practice always. Use delegates out lambda subs inside invocations.