invokerequired | 易学教程

What's wrong with calling Invoke, regardless of InvokeRequired?

阅读更多关于 What's wrong with calling Invoke, regardless of InvokeRequired?

I've seen the common setup for cross threading access to a GUI control, such as discussed here: Shortest way to write a thread-safe access method to a windows forms control All the web hits I found describe a similar thing. However, why do we need to check InvokeRequired? Can't we just call Invoke directly? I assume the answer is no, so my real question is 'why'? From non-UI threads we can't touch the UI - very bad things can happen, since controls have thread affinity. So from a non-UI thread we must (at a minumum) call Invoke or BeginInvoke . For UI-threads, however - we don't want to call

Cleaning up code littered with InvokeRequired

阅读更多关于 Cleaning up code littered with InvokeRequired

I know that when manipulating UI controls from any non-UI thread, you must marshal your calls to the UI thread to avoid issues. The general consensus is that you should use test InvokeRequired, and if true, use .Invoke to perform the marshaling. This leads to a lot of code that looks like this: private void UpdateSummary(string text) { if (this.InvokeRequired) { this.Invoke(new Action(() => UpdateSummary(text))); } else { summary.Text = text; } } My question is this: can I leave out the InvokeRequired test and just call Invoke, like so: private void UpdateSummary(string text) { this.Invoke(new

C# cross-thread call problem

阅读更多关于 C# cross-thread call problem

问题 I'm writing a form app in c# and I need to be able to change the contents of a Rich Text Box from any thread, I tried using a delegate and InvokeRequired , but the delegate I made still gives me a cross-thread call error, and InvokeRequired crashes the form, without giving an error. Function I need to be able to execute from any thread: public static void updateSub(int what) { subDisplay.subBox.Text = tb[what]; } The delegate I tried to use: public delegate void UpdateDelegateVoid(int what);

Why is a value copy of MainForm created when method is called or invoked cross thread?

阅读更多关于 Why is a value copy of MainForm created when method is called or invoked cross thread?

问题 Update: I think it has something to do with lazy instantiation of the window handle for MainForm - but haven't been able to work out quite how that would result in the behavior seen here. The application requests data via 3rd party COM interface providing a callback to process the results. In the callback, the UI needs to be updated - but the update doesn't work as expected. It's as if a value copy of MainForm had been created, when MainForm.DataReady is called or invoked directly cross

Run code on UI thread without control object present

阅读更多关于 Run code on UI thread without control object present

问题 I currently trying to write a component where some parts of it should run on the UI thread (explanation would be to long). So the easiest way would be to pass a control to it, and use InvokeRequired/Invoke on it. But I don't think that it is a good design to pass a control reference to a "data/background"-component, so I'm searching for a way to run code on the UI thread without the need of having a control available. Something like Application.Dispatcher.Invoke in WPF... any ideas, thx

Multithreading for a progressbar and code locations (vb.net)?

阅读更多关于 Multithreading for a progressbar and code locations (vb.net)?

问题 I am stuck updating a progressbar from a different thread. I did get it running in the simplest way, but then cleaning the code gets me stuck. My testing code looks like all the examples on the web related to backgroundworker and BeginInvoke. FormP is the Progressbar-Form. This works: Public Class Form1 Private Delegate Sub delegate_ProgressUpdate(ByVal paramValue As Integer, ByVal paramMax As Integer) Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1

Automating the InvokeRequired code pattern

阅读更多关于 Automating the InvokeRequired code pattern

问题 I have become painfully aware of just how often one needs to write the following code pattern in event-driven GUI code, where private void DoGUISwitch() { // cruisin for a bruisin\' through exception city object1.Visible = true; object2.Visible = false; } becomes: private void DoGUISwitch() { if (object1.InvokeRequired) { object1.Invoke(new MethodInvoker(() => { DoGUISwitch(); })); } else { object1.Visible = true; object2.Visible = false; } } This is an awkward pattern in C#, both to remember