I'm trying to decide on the right approach for communication between the UI
and a worker thread in a WinForms app. I am very familiar with threads in
the unmanaged C++ world and in the past have used WM_USER based messages to
communicate status from the worker thread back to the UI thread. What is
the right way to do this in .Net? Are asynchronous delegates the way to go,
or is there a better (or just different) approach I should consider?
-Brett- 7 9425
Brett,
If you have a control that was created on the UI thread, then you can
just call Invoke on that control, passing a delegate and the parameters to
it, and it will call the method on the UI thread, allowing you to perform UI
operations.
It's much easier than creating your own WM_USER messages and then
handling the marshalling and the like.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Brett Robichaud" <br************@nospam.yahoo.com> wrote in message
news:eK**************@TK2MSFTNGP12.phx.gbl... I'm trying to decide on the right approach for communication between the UI and a worker thread in a WinForms app. I am very familiar with threads in the unmanaged C++ world and in the past have used WM_USER based messages to communicate status from the worker thread back to the UI thread. What is the right way to do this in .Net? Are asynchronous delegates the way to go, or is there a better (or just different) approach I should consider?
-Brett-
I'd argue to generally avoid Control.Invoke in favour of Control.BeginInvoke.
Invoke waits for the method pass via the delegate to have finished executing ont he UI thread before it returns, BeginInvoke does now. It is a rare situation that a background thread requires this type of interaction it also has the possibility in some situations (depending on your code) to leave you open to deadlock between the worker and UI thread.
Regards
Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog
nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<OF*************@TK2MSFTNGP12.phx.gbl>
Brett,
If you have a control that was created on the UI thread, then you can
just call Invoke on that control, passing a delegate and the parameters to
it, and it will call the method on the UI thread, allowing you to perform UI
operations.
It's much easier than creating your own WM_USER messages and then
handling the marshalling and the like.
Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com
"Brett Robichaud" <br************@nospam.yahoo.com> wrote in message
news:eK**************@TK2MSFTNGP12.phx.gbl... I'm trying to decide on the right approach for communication between the UI and a worker thread in a WinForms app. I am very familiar with threads in the unmanaged C++ world and in the past have used WM_USER based messages to communicate status from the worker thread back to the UI thread. What is the right way to do this in .Net? Are asynchronous delegates the way to go, or is there a better (or just different) approach I should consider?
-Brett-
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system ( http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004
[microsoft.public.dotnet.languages.csharp]
But doesn't failing to call EndInvoke result in a memory leak?
--
John Wood
EMail: first name, dot, second name at priorganize.com
"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message
news:uz**************@tk2msftngp13.phx.gbl... I'd argue to generally avoid Control.Invoke in favour of
Control.BeginInvoke. Invoke waits for the method pass via the delegate to have finished
executing ont he UI thread before it returns, BeginInvoke does now. It is a
rare situation that a background thread requires this type of interaction it
also has the possibility in some situations (depending on your code) to
leave you open to deadlock between the worker and UI thread. Regards
Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog
nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<OF*************@TK2MSFTNGP12.phx.gbl> Brett,
If you have a control that was created on the UI thread, then you can just call Invoke on that control, passing a delegate and the parameters
to it, and it will call the method on the UI thread, allowing you to perform
UI operations.
It's much easier than creating your own WM_USER messages and then handling the marshalling and the like.
Hope this helps.
-- - Nicholas Paldino [.NET/C# MVP] - mv*@spam.guard.caspershouse.com
"Brett Robichaud" <br************@nospam.yahoo.com> wrote in message news:eK**************@TK2MSFTNGP12.phx.gbl... > I'm trying to decide on the right approach for communication between
the > UI > and a worker thread in a WinForms app. I am very familiar with threads
in > the unmanaged C++ world and in the past have used WM_USER based
messages > to > communicate status from the worker thread back to the UI thread. What
is > the right way to do this in .Net? Are asynchronous delegates the way to > go, > or is there a better (or just different) approach I should consider? > > -Brett- > > --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004 [microsoft.public.dotnet.languages.csharp]
This is a special case, calling EndInvoke is not required for
Control.BeginInvoke, it's only needed when calling Delegate.BeginInvoke.
Willy.
"John Wood" <sp**@isannoying.com> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl... But doesn't failing to call EndInvoke result in a memory leak?
-- John Wood EMail: first name, dot, second name at priorganize.com
"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message news:uz**************@tk2msftngp13.phx.gbl... I'd argue to generally avoid Control.Invoke in favour of Control.BeginInvoke. Invoke waits for the method pass via the delegate to have finished
executing ont he UI thread before it returns, BeginInvoke does now. It is a rare situation that a background thread requires this type of interaction it also has the possibility in some situations (depending on your code) to leave you open to deadlock between the worker and UI thread. Regards
Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog
nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<OF*************@TK2MSFTNGP12.phx.gbl> Brett,
If you have a control that was created on the UI thread, then you can just call Invoke on that control, passing a delegate and the parameters
to it, and it will call the method on the UI thread, allowing you to perform UI operations.
It's much easier than creating your own WM_USER messages and then handling the marshalling and the like.
Hope this helps.
-- - Nicholas Paldino [.NET/C# MVP] - mv*@spam.guard.caspershouse.com
"Brett Robichaud" <br************@nospam.yahoo.com> wrote in message news:eK**************@TK2MSFTNGP12.phx.gbl... > I'm trying to decide on the right approach for communication between the > UI > and a worker thread in a WinForms app. I am very familiar with threads in > the unmanaged C++ world and in the past have used WM_USER based messages > to > communicate status from the worker thread back to the UI thread. What is > the right way to do this in .Net? Are asynchronous delegates the way to > go, > or is there a better (or just different) approach I should consider? > > -Brett- > > --- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004 [microsoft.public.dotnet.languages.csharp]
Ahh now theres a good question. No it doesn't - not for *Control*.EndInvoke. For every other EndInvoke it might (Microsoft only said they reserved the right to leak not that they definitely would, and as we can't determine their implementation from SP to SP let alone version to version you must alwasy call EndInvoke apart from the Control.EndInvoke).
The problem was in terms of API naming. I asked someone from the WInforms team why they didn't rename BeginIvoke when they realised they had a clash in API names and theirs hacd different semantics from everyone elses and they said "we got there first" ... so there you go.
Regards
Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog
nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<#q**************@TK2MSFTNGP10.phx.gbl>
But doesn't failing to call EndInvoke result in a memory leak?
--
John Wood
EMail: first name, dot, second name at priorganize.com
"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message
news:uz**************@tk2msftngp13.phx.gbl... I'd argue to generally avoid Control.Invoke in favour of
Control.BeginInvoke. Invoke waits for the method pass via the delegate to have finished
executing ont he UI thread before it returns, BeginInvoke does now. It is a
rare situation that a background thread requires this type of interaction it
also has the possibility in some situations (depending on your code) to
leave you open to deadlock between the worker and UI thread. Regards
Richard Blewett - DevelopMentor http://staff.develop.com/richardb/weblog
nntp://news.microsoft.com/microsoft.public.dotnet.languages.csharp/<OF*************@TK2MSFTNGP12.phx.gbl> Brett,
If you have a control that was created on the UI thread, then you can just call Invoke on that control, passing a delegate and the parameters
to it, and it will call the method on the UI thread, allowing you to perform
UI operations.
It's much easier than creating your own WM_USER messages and then handling the marshalling and the like.
Hope this helps.
-- - Nicholas Paldino [.NET/C# MVP] - mv*@spam.guard.caspershouse.com
"Brett Robichaud" <br************@nospam.yahoo.com> wrote in message news:eK**************@TK2MSFTNGP12.phx.gbl... I'm trying to decide on the right approach for communication between
the UI and a worker thread in a WinForms app. I am very familiar with threads
in the unmanaged C++ world and in the past have used WM_USER based
messages to communicate status from the worker thread back to the UI thread. What
is the right way to do this in .Net? Are asynchronous delegates the way to go, or is there a better (or just different) approach I should consider?
-Brett-
--- Incoming mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004 [microsoft.public.dotnet.languages.csharp]
---
Incoming mail is certified Virus Free.
Checked by AVG anti-virus system ( http://www.grisoft.com).
Version: 6.0.771 / Virus Database: 518 - Release Date: 28/09/2004
[microsoft.public.dotnet.languages.csharp]
Example pattern to update a richtextbox from any thread. The actual control
could be anything, just change as needed:
private delegate void UpdateDelegate(string text);
public void UpdateRTB1(string text)
{
if ( InvokeRequired )
{
UpdateDelegate ud = new UpdateDelegate(UpdateRTB1);
BeginInvoke(ud, new object[]{text});
}
else
{
this.rtbClient1.AppendText(text);
}
}
Now just call the method from either your form or any thread (your worker
will still need a ref to the form to call the method) and it does the right
thing.
--
William Stacey, MVP
"Brett Robichaud" <br************@nospam.yahoo.com> wrote in message
news:eK**************@TK2MSFTNGP12.phx.gbl... I'm trying to decide on the right approach for communication between the
UI and a worker thread in a WinForms app. I am very familiar with threads in the unmanaged C++ world and in the past have used WM_USER based messages
to communicate status from the worker thread back to the UI thread. What is the right way to do this in .Net? Are asynchronous delegates the way to
go, or is there a better (or just different) approach I should consider?
-Brett-
"Richard Blewett [DevelopMentor]" <ri******@develop.com> wrote in message
news:uz**************@tk2msftngp13.phx.gbl... I'd argue to generally avoid Control.Invoke in favour of
Control.BeginInvoke. Invoke waits for the method pass via the delegate to have finished
executing ont he UI thread before it returns, BeginInvoke does now. It is a
rare situation that a background thread requires this type of interaction it
also has the possibility in some situations (depending on your code) to
leave you open to deadlock between the worker and UI thread.
Be wary of the Invoke and BeginInvoke methods on the form. If you call
either of these functions and the handle for the form has not been created,
an exception will be thrown. An exception will also be thrown if the handle
has been destroyed, maybe even before - (I haven't quite figured out the
semantics, nor do they seem to be included in the documentation. Please
anyone, correct me if I'm wrong here - I'd love to be).
Invoke can be handy for handling unrecoverable errors that occur on worker
threads. Getting the UI thread to show an error message dialog may be the
right thing to do. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: fooooo |
last post by:
This is a network app, written in wxPython and the socket module. This
is what I want to happen:
GUI app starts. User clicks a button to 'start' the work of the app.
When start is pressed, a new...
|
by: Mark Stokes |
last post by:
Hi there,
I wanted a bit of advice on a program (a prototype) that I am trying
to write that uses threads. I will outline what I am attempting to
do, and if anyone has any advice on the way I...
|
by: Sreedharan |
last post by:
Hello everyone,
I am a VC++ programmer.
When i develop a multi-threaded application in C++, I prefer to use
worker thread, so that the main thread and worker thread can
communicate using...
|
by: Alexander |
last post by:
Hi, I have written a program that takes on some operations much more
time than I expected. As I have seen users clicking wildly on the
screen to make something happen, I want to follow the...
|
by: Charles Law |
last post by:
My first thought was to call
WorkerThread.Suspend
but the help cautions against this (for good reason) because the caller has
no control over where the thread actually stops, and it might have...
|
by: 1944USA |
last post by:
I am re-architecting a C# application written as a multithreaded
Windows Service and trying to squeeze every bit of performance out of
it.
1) Does the thread that an object is instantiated on...
|
by: Patrick |
last post by:
I have an ASP.NET web service whose Web.Config is set to use impersonation
<authentication mode="Windows" />
<identity impersonate="true" />
Within a Web Method, I want to use...
|
by: Matthew Tylee Atkinson |
last post by:
I appear to be having some problems with the isAlive() method of
detecting if a thread is alive/active/running or not. I'd be grateful
for any advice.
I have a visualisation program (which uses...
|
by: parez |
last post by:
I start a BackGroundWorker to populate a grid. It is started off in
the ui layer
The thread follows( cannot think of a better word) the path
UI->Layer1->Layer2->Communication Layer
and it...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |