scary (but good) .NET 2.0 feature

[Michael Bray]

All,

I was just reading over a new MSDN Magazine article by Juval Lowy on the
new features in C# 2.0 (its a wonderful article, see link below.) In
the section titled "Anonymous Method Example" he makes reference to an
aspect of .NET 2.0 that may have a significant impact on many of your
applications, if they are multi-threaded and have a user interface.

Now we all know that the right way to update any parts of the user
interface in a multi-threaded application is to marshal the call to the
thread that created the interface control and perform the updates there.
But (be honest now) how many of us really do that for 100% of our calls?
I know I don't (maybe I'm the only one??). Apparently .NET 2.0 will
force you to do this - throwing an exception if you don't.

Note that I'm not complaining - this is surely a good thing for program
realibility. I'm just giving a heads up to those of us that tend to
relax the rules on occasion... :)

However this does bring up a question - how do most people deal with
this? Specifically...

When I do things the right way, things seem a bit cumbersome. I need a
delegate and a separate method for any function which updates the
interface.

So now I have to "control.Invoke (delegate, new object[] { ... });" which
seems to (a) make the code difficult to read (b) creates object[]'s all
over the place.

Now I've only been programming .NET for about a year, but I haven't seen
anything to indicate if there is there a better way to do it? And more
to the point, why didn't the .NET framework programmers build in thread
safety into the .NET WinForms components??

Link to article by Juval Lowy:
http://msdn.microsoft.com/msdnmag/is...0/default.aspx

-mdb

[Alvin Bruney [MVP]]

> why didn't the .NET framework programmers build in thread
safety into the .NET WinForms components??
How? By throwing exceptions or otherwise ???
--
Regards,
Alvin Bruney [ASP.NET MVP]
Got tidbits? Get it here...
http://tinyurl.com/27cok
"Michael Bray" <mb************ *******@SkPiAlM l.ctiusa.com> wrote in message
news:Xn******** *************** ***********@207 .46.248.16...

All,

I was just reading over a new MSDN Magazine article by Juval Lowy on the
new features in C# 2.0 (its a wonderful article, see link below.) In
the section titled "Anonymous Method Example" he makes reference to an
aspect of .NET 2.0 that may have a significant impact on many of your
applications, if they are multi-threaded and have a user interface.

Now we all know that the right way to update any parts of the user
interface in a multi-threaded application is to marshal the call to the
thread that created the interface control and perform the updates there.
But (be honest now) how many of us really do that for 100% of our calls?
I know I don't (maybe I'm the only one??). Apparently .NET 2.0 will
force you to do this - throwing an exception if you don't.

Note that I'm not complaining - this is surely a good thing for program
realibility. I'm just giving a heads up to those of us that tend to
relax the rules on occasion... :)

However this does bring up a question - how do most people deal with
this? Specifically...

When I do things the right way, things seem a bit cumbersome. I need a
delegate and a separate method for any function which updates the
interface.

So now I have to "control.Invoke (delegate, new object[] { ... });" which
seems to (a) make the code difficult to read (b) creates object[]'s all
over the place.

Now I've only been programming .NET for about a year, but I haven't seen
anything to indicate if there is there a better way to do it? And more
to the point, why didn't the .NET framework programmers build in thread
safety into the .NET WinForms components??

Link to article by Juval Lowy:
http://msdn.microsoft.com/msdnmag/is...0/default.aspx

-mdb

[C# Learner]

Michael Bray wrote:

All,

I was just reading over a new MSDN Magazine article by Juval Lowy on the
new features in C# 2.0 (its a wonderful article, see link below.) In
the section titled "Anonymous Method Example" he makes reference to an
aspect of .NET 2.0 that may have a significant impact on many of your
applications, if they are multi-threaded and have a user interface.

Now we all know that the right way to update any parts of the user
interface in a multi-threaded application is to marshal the call to the
thread that created the interface control and perform the updates there.
But (be honest now) how many of us really do that for 100% of our calls?
I know I don't (maybe I'm the only one??). Apparently .NET 2.0 will
force you to do this - throwing an exception if you don't.

Note that I'm not complaining - this is surely a good thing for program
realibility. I'm just giving a heads up to those of us that tend to
relax the rules on occasion... :)

However this does bring up a question - how do most people deal with
this? Specifically...

When I do things the right way, things seem a bit cumbersome. I need a
delegate and a separate method for any function which updates the
interface.

So now I have to "control.Invoke (delegate, new object[] { ... });" which
seems to (a) make the code difficult to read (b) creates object[]'s all
over the place.

Now I've only been programming .NET for about a year, but I haven't seen
anything to indicate if there is there a better way to do it? And more
to the point, why didn't the .NET framework programmers build in thread
safety into the .NET WinForms components??

Link to article by Juval Lowy:
http://msdn.microsoft.com/msdnmag/is...0/default.aspx

I find it a real pain in the backside, and I usually work around it by
making another class, whose purpose is to marshall things.

This class has, as part of its state, a reference to the relevant
form(s) that need to be updated. It responds to events from the
specific object by calling Invoke() on the relevant form.

[Michael Bray]

"Alvin Bruney [MVP]" <vapor at steaming post office> wrote in
news:eM******** ******@TK2MSFTN GP12.phx.gbl:

why didn't the .NET framework programmers build in thread

safety into the .NET WinForms components??
How? By throwing exceptions or otherwise ???

Just as he describes for the 'SafeLabel' in his article. For example,
they could have done something like:

public class Label : Control
{
....
private string text;
public string Text
{
get { return text; }
set
{
if (InvokeRequired )
{
... (marshal the call)
}
else
{
... (set it directly)
}
}
}
}

but apparently they didn't do that.

-mdb

[TT \(Tom Tempelaere\)]

"Michael Bray" <mb************ *******@SkPiAlM l.ctiusa.com> wrote in message
news:Xn******** *************** ***********@207 .46.248.16...

I was just reading over a new MSDN Magazine article by Juval Lowy on the
new features in C# 2.0 (its a wonderful article, see link below.) In
the section titled "Anonymous Method Example" he makes reference to an
aspect of .NET 2.0 that may have a significant impact on many of your
applications, if they are multi-threaded and have a user interface.

Now we all know that the right way to update any parts of the user
interface in a multi-threaded application is to marshal the call to the
thread that created the interface control and perform the updates there.
But (be honest now) how many of us really do that for 100% of our calls?
I, for one. I don't see any reason to touch UI directly. It's asking for
trouble.
I know I don't (maybe I'm the only one??). Apparently .NET 2.0 will
force you to do this - throwing an exception if you don't.

Note that I'm not complaining - this is surely a good thing for program
realibility. I'm just giving a heads up to those of us that tend to
relax the rules on occasion... :)

However this does bring up a question - how do most people deal with
this? Specifically...
delegate + invoke
When I do things the right way, things seem a bit cumbersome. I need a
delegate and a separate method for any function which updates the
interface.
So? What is wrong with that?
So now I have to "control.Invoke (delegate, new object[] { ... });" which
seems to (a) make the code difficult to read (b) creates object[]'s all
over the place.

Now I've only been programming .NET for about a year, but I haven't seen
anything to indicate if there is there a better way to do it? And more
to the point, why didn't the .NET framework programmers build in thread
safety into the .NET WinForms components??

Probably because that would make UI code slower in general.

Tom.

[Willy Denoyette [MVP]]

"Michael Bray" <mb************ *******@SkPiAlM l.ctiusa.com> wrote in message
news:Xn******** *************** ***********@207 .46.248.16...

All,

I was just reading over a new MSDN Magazine article by Juval Lowy on the
new features in C# 2.0 (its a wonderful article, see link below.) In
the section titled "Anonymous Method Example" he makes reference to an
aspect of .NET 2.0 that may have a significant impact on many of your
applications, if they are multi-threaded and have a user interface.

Now we all know that the right way to update any parts of the user
interface in a multi-threaded application is to marshal the call to the
thread that created the interface control and perform the updates there.
But (be honest now) how many of us really do that for 100% of our calls?
I know I don't (maybe I'm the only one??). Apparently .NET 2.0 will
force you to do this - throwing an exception if you don't.

Note that I'm not complaining - this is surely a good thing for program
realibility. I'm just giving a heads up to those of us that tend to
relax the rules on occasion... :)

However this does bring up a question - how do most people deal with
this? Specifically...

When I do things the right way, things seem a bit cumbersome. I need a
delegate and a separate method for any function which updates the
interface.

So now I have to "control.Invoke (delegate, new object[] { ... });" which
seems to (a) make the code difficult to read (b) creates object[]'s all
over the place.

Now I've only been programming .NET for about a year, but I haven't seen
anything to indicate if there is there a better way to do it? And more
to the point, why didn't the .NET framework programmers build in thread
safety into the .NET WinForms components??

Link to article by Juval Lowy:
http://msdn.microsoft.com/msdnmag/is...0/default.aspx

-mdb

..NET 2.0 also introduces a new class in the Windows.Forms namespace called
BackgroundWorke r that handles all UI delegation/marshalling for you.

Willy.

[Joerg Jooss]

Willy Denoyette [MVP] wrote:

"Michael Bray" <mb************ *******@SkPiAlM l.ctiusa.com> wrote in
message news:Xn******** *************** ***********@207 .46.248.16... [...] .NET 2.0 also introduces a new class in the Windows.Forms namespace
called BackgroundWorke r that handles all UI delegation/marshalling
for you.

And Juwal Löwy even provides a .NET 1.1 implementation on the iDesign web
site -- see
http://www.idesign.net/idesign/Deskt...ndex=5&tabid=8

Cheers,

--
Joerg Jooss
jo*********@gmx .net