"Jon Skeet [C# MVP]" wrote:

> Well, I suspect it's a detail of how the threading is checked in debug
> mode - but it definitely doesn't mean it's *safe* to do that work in
> the non-UI thread.

Jon Shemitz <jon@midnightbeach.com> wrote:
> "Jon Skeet [C# MVP]" wrote:
>
> > Well, I suspect it's a detail of how the threading is checked in debug
> > mode - but it definitely doesn't mean it's *safe* to do that work in
> > the non-UI thread.
>
> Yeah, I know. That's why I'm so puzzled that it does work. In Release
> mode, too.
>
> I'm wondering if the rules have changed in beta 2.

Jon Shemitz <jon@midnightbeach.com> wrote:
> I'm experimenting with a WinForms peer-to-peer .NET Remoting project.
> Each of the forms exports an object that can put messages in a
> RichTextBox, using SelectionText. The remote "client" form calls its
> proxied version of this object, to put text in the "server's"
> RichTextBox.
>
> Now, the remote requests do NOT run in the GUI thread - yet
>
> RTF.SelectionStart = RTF.Text.Length;
> RTF.SelectionColor = MessageColor;
> RTF.SelectedText = Message;
>
> does NOT cause cross-thread synchronization errors, as I'd expect it
> to. Why? Is SelectedText special in some way?
>
> Strangely, if I set Text in the GUI thread, subsequent non-GUI thread
> sets of SelectedText do cause the errors I'd expect. If I use
> SelectedText for the initial set, subsequent non-GUI thread sets of
> SelectedText do not cause any errors.
>
> 2.0 Beta 2, if that makes any difference.

"Jon Skeet [C# MVP]" wrote:

> > I'm wondering if the rules have changed in beta 2.
>
> No, things have always worked to some extent when you use the wrong
> thread - it's just that they're likely to go bang when you least expect
> it.