scary (but good) .NET 2.0 feature

  • Thread starter Thread starter Michael Bray
  • Start date Start date
M

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/issues/04/05/C20/default.aspx

-mdb
 
why didn't the .NET framework programmers build in thread
safety into the .NET WinForms components??
How? By throwing exceptions or otherwise ???
 
Michael said:
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/issues/04/05/C20/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.
 
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
 
Michael Bray said:
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.
 
Michael Bray said:
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/issues/04/05/C20/default.aspx

-mdb

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

Willy.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top