Updating Winforms and multi-threading
-
Is there any other way of updating forms in a thread safe way apart from the delegate/InvokeRequired trick? I'm working on an app (RSS Reader) which has a separate thread for checking if new items appeared and updating context menus accordingly, can I acquire some sort of lock to a control or do I have to create UpdateContextMenuItem(ToolStripMenuItem menuitem, ToolStripItem subitem)-esque methods for each and every action that I may need to perform? I'm new to C#/.NET, and despite initial bias I was quite impressed how clean and well-designed it is, until now. TIA, Greg
-
Is there any other way of updating forms in a thread safe way apart from the delegate/InvokeRequired trick? I'm working on an app (RSS Reader) which has a separate thread for checking if new items appeared and updating context menus accordingly, can I acquire some sort of lock to a control or do I have to create UpdateContextMenuItem(ToolStripMenuItem menuitem, ToolStripItem subitem)-esque methods for each and every action that I may need to perform? I'm new to C#/.NET, and despite initial bias I was quite impressed how clean and well-designed it is, until now. TIA, Greg
Jergosh wrote:
I'm new to C#/.NET
What about Object Oriented Programming and/or Design Patterns, are you new to those as well? What is your background?
Jergosh wrote:
apart from the delegate/InvokeRequired trick?
Why is that a trick? It's an implementation of inter-thread communications, do you know of some way to communicate between threads that doesn't involve communicating between threads?
led mike
-
Jergosh wrote:
I'm new to C#/.NET
What about Object Oriented Programming and/or Design Patterns, are you new to those as well? What is your background?
Jergosh wrote:
apart from the delegate/InvokeRequired trick?
Why is that a trick? It's an implementation of inter-thread communications, do you know of some way to communicate between threads that doesn't involve communicating between threads?
led mike
led mike wrote:
What about Object Oriented Programming and/or Design Patterns, are you new to those as well? What is your background?
I have experience with C, C++ and Python as well as have completed misc university courses (algorithms and data structures etc) but I don't see how that's relevant.
led mike wrote:
Why is that a trick? It's an implementation of inter-thread communications, do you know of some way to communicate between threads that doesn't involve communicating between threads?
I'd say it's less standard than just acquiring lock, doing whatever we like with the object and then releasing it. Less convenient as well if I want, say, clear a menu and populate it with dynamic content as I have to write several helper methods. Apart from that, replacing menuItem.DropDownItems.Clear(); with self-made ClearDropDownMenu(menuItem) isn't particularly object-oriented (or at least doesn't look as if it was). Could we please get back to my initial question?
modified on Thursday, March 6, 2008 3:15 PM
-
Is there any other way of updating forms in a thread safe way apart from the delegate/InvokeRequired trick? I'm working on an app (RSS Reader) which has a separate thread for checking if new items appeared and updating context menus accordingly, can I acquire some sort of lock to a control or do I have to create UpdateContextMenuItem(ToolStripMenuItem menuitem, ToolStripItem subitem)-esque methods for each and every action that I may need to perform? I'm new to C#/.NET, and despite initial bias I was quite impressed how clean and well-designed it is, until now. TIA, Greg
Hi, accessing a Control must be done by the thread that created the Control, normally the main thread a.k.a. GUI thread. So other threads must SOMEHOW pass the GUI access actions to the main thread. There are basically two ways to do that: 1. the Control.InvokeRequired/Invoke pattern 2. otherwise passing sufficient data to the GUI thread and have it access the Controls (e.g. prepare a collection with new data, and have it processed by a Windows.Forms.Timer, which always ticks on GUI thread! :)
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips: - before you ask a question here, search CodeProject, then Google; - the quality and detail of your question reflects on the effectiveness of the help you are likely to get; - use PRE tags to preserve formatting when showing multi-line code snippets.
-
Hi, accessing a Control must be done by the thread that created the Control, normally the main thread a.k.a. GUI thread. So other threads must SOMEHOW pass the GUI access actions to the main thread. There are basically two ways to do that: 1. the Control.InvokeRequired/Invoke pattern 2. otherwise passing sufficient data to the GUI thread and have it access the Controls (e.g. prepare a collection with new data, and have it processed by a Windows.Forms.Timer, which always ticks on GUI thread! :)
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips: - before you ask a question here, search CodeProject, then Google; - the quality and detail of your question reflects on the effectiveness of the help you are likely to get; - use PRE tags to preserve formatting when showing multi-line code snippets.
Luc Pattyn wrote:
There are basically two ways to do that: 1. the Control.InvokeRequired/Invoke pattern 2. otherwise passing sufficient data to the GUI thread and have it access the Controls (e.g. prepare a collection with new data, and have it processed by a Windows.Forms.Timer, which always ticks on GUI thread!
Most helpful, many thanks :-)
-
led mike wrote:
What about Object Oriented Programming and/or Design Patterns, are you new to those as well? What is your background?
I have experience with C, C++ and Python as well as have completed misc university courses (algorithms and data structures etc) but I don't see how that's relevant.
led mike wrote:
Why is that a trick? It's an implementation of inter-thread communications, do you know of some way to communicate between threads that doesn't involve communicating between threads?
I'd say it's less standard than just acquiring lock, doing whatever we like with the object and then releasing it. Less convenient as well if I want, say, clear a menu and populate it with dynamic content as I have to write several helper methods. Apart from that, replacing menuItem.DropDownItems.Clear(); with self-made ClearDropDownMenu(menuItem) isn't particularly object-oriented (or at least doesn't look as if it was). Could we please get back to my initial question?
modified on Thursday, March 6, 2008 3:15 PM
Jergosh wrote:
I'd say it's less standard than just acquiring lock
How does acquiring a lock switch your codes execution context to another thread?
Jergosh wrote:
Could we please get back to my initial question?
Your initial question appears to be based upon a misunderstanding of some of the things that are involved in the answer to your question. The direction of my posts was based on the idea that you might consider it of value to gain an improved understanding of these rather than just be given a "do this" solution. If that's not the case then so be it.
led mike
-
Luc Pattyn wrote:
There are basically two ways to do that: 1. the Control.InvokeRequired/Invoke pattern 2. otherwise passing sufficient data to the GUI thread and have it access the Controls (e.g. prepare a collection with new data, and have it processed by a Windows.Forms.Timer, which always ticks on GUI thread!
Most helpful, many thanks :-)
You're welcome. :)
Luc Pattyn [Forum Guidelines] [My Articles]
This month's tips: - before you ask a question here, search CodeProject, then Google; - the quality and detail of your question reflects on the effectiveness of the help you are likely to get; - use PRE tags to preserve formatting when showing multi-line code snippets.