I have a C# app that receives updates from a server, processes it, and updates the GUI. the updates come in constantly, say several times a second. I want the app to update the GUI at most once every 2 seconds. so if an update comes in at time T, I want all updates that come in from T through T+2sec to stay in a buffer, and at T+2sec do the processing and GUI update. I know in JS you can use setTimeout() to execute some code at some time in the future, so I want something like that.
what's an appropriate way to do this? I've heard that using threads to "schedule" a function call isn't a great idea, but I'm not sure of a better way to do this. would it be so bad to use a Timer with a two second interval, synchronized to the GUI thread, that does the processing/updating?
You can use a System.Windows.Forms.Timer. It doesn't run events in a separate thread, it's the GUI thread that runs them. That way you can update the GUI directly without having to use Invoke.
You should use one of the timer classes, as you posted in your question.
See this MSDN article comparing them - this should give you a good basis to make a decision.
Related
I have a C# Windows Forms application wicht does some camera control and computer vision. For all the parts which take longer for calculation I used seperate threads. But there are still some parts which are in the callback functions of the GUI. As I understand, all these callback functions are executed in the same thread. Is there a way to see how much time this thread is working or idle? What percentage of idle time is needed such that the GUI is still responsive?
It's recommended that you shouldn't block the UI thread for more than 50ms, otherwise it will affect the UI responsiveness. I.e., two UI callbacks queued with Form.BeginInvoke, each taking ~50ms to complete, may introduce some unpleasant UI experience to the user.
It doesn't make sense to update the UI more often than the user can react to it (i.e, ~24 frames per second). So, you should throttle the UI thread callbacks and give user input events a priority.
I recently posted an example of how it can possibly be done:
https://stackoverflow.com/a/21654436/1768303
For simple tasks you could use a stopwatch and measure the time manually. However I think you'll need to check what a performance profiler is.
Also - there is little situations in which your GUI needs that heavy processing. In most cases the problem comes from putting too much calculations in event handlers instead of implementing them somewhere outside and then update the form when finished. It's less of a single/multi-threading problem and more of using available events properly.
I'm using the following code to take screenshots from a process:
Get a screenshot of a specific application (Maurice Flanagan's answer)
I would like to read data from the process screenshot quite frequently. It takes about 100ms for the method to execute once. My idea is to put it inside a timer which updates a few times per second. I suppose this will "freeze" the app each time the method runs (since I run it on the main thread).
So what I would like to know is; what kind of asynchronous solution would fit this scenario best? I know that there are some built-in classes for this. I just need a pointer in the right direction (not very familiar with WinForms).
Check out the BackgroundWorker class: http://msdn.microsoft.com/en-us/library/system.componentmodel.backgroundworker.aspx
I have datagridview and need to update it on separate thread. Or maybe even on same thread but only when data ready. I have 90% of data loading right away and would like to show it to user. Then I have 2 more columns that can load 20+ seconds sometimes and would like to update them as soon as data ready. What is the best way to accomplish this?
In WinForms, your best bet is BackgroundWorker, it's a nice class for doing work on a different thread and updating a WinForms based UI.
Having not seen any code, I would suggest creating your own event. Once the data is ready, you throw a new event with the new data as the argument, and then load that. It'll happen on the same UI thread though.
Not sure if you already have a way to poll for that being completed. Making a thread to run in the background and just poll for that wouldn't be too hard.
Where is the remaining 10% of your data coming from? What are you binding to? Is this a scenario where you're making one hit to your data source for the "90%" and then making a totally separate hit to go get the rest of your data?
I am new to the world of GUI programming and I am writing a little GUI app using IronPython and WinForms. It reads values from an external device and displays them in a ListView component (name, value). I want to periodically perform the reading and updating of the ListView component at a certain fixed rate.
I had the following ideas to accomplish this:
A timer, which periodically triggers the read/screen update directly in the OnTick handler
A timer, whose OnTick handler triggers a BackgroundWorker to perform the read/update
Since the first solution will block the GUI until the read/update loop is done, which, depending on the number of values being read from the device, could take some time, I think the BackgroundWorker might be a better solution. I might want to add some functionality to manipulate the ListView items later (add, remove values etc.) and a blocked GUI does not seem like a good idea.
Is there a certain design pattern or a better way to accomplish reading/updating screen data?
NOTE: Any code examples can be IronPython or C#. The conversion from C# to IronPython is pretty straight forward. Thanks!
Personally, I'd have one thread that's responsible for reading values out of the device and storing the data in a data structure, and then a System.Windows.Forms.Timer (there's 3 Timers in .NET, this is the only one that ticks in the thread that's safe to update your controls) to read values out of that data structure and update the UI. You may need to synchronise that data structure, you may not.
That way the device can take as long as it likes to return data, or it can push as many millions of rows per second at you, and the UI thread will still poll at your predetermined tick rate (probably every 100 msec?). Since your timer ticks are just reading data out of memory, the UI won't block for IO.
The BackgroundWorker is prefered when you have lot of work to do in the background.
Use a Timer to trigger a function that will do the necessary work in a second thread.
It won't block the UI. (don't forget to update the controls on the UI thread).
System.Threading.Thread newThread;
newThread = new System.Threading.Thread(anObject.AMethod);
http://msdn.microsoft.com/fr-fr/library/ms173178(VS.80).aspx
Another option rather than getting the Timer and the Background worker thread working would be to use the System.Threading.Timer, this will execute your method on a thread on a regular interval and once you have the data you can use Control.Invoke or Control.BeginInvoke to update the control in the UI thread.
Could you please tell me how do I go about pausing my program for 500 milliseconds and then continue?
I read Thread.Sleep(500) is not good as it holds up the GUI thread.
Using a timer it fires a callback ...
I just want to wait 500ms and then continue to the next statement.
Please advise.
EDIT: I need to display a status bar message for 500ms and then update the message with a different one. Sorry, I meant 500 not 50.
EDIT: I do understand what all you have said. but: [I just want to wait 500ms and then continue to the next statement.] I think because it is such a short interval i am going do a Thread.Sleep(500) on the main GUI thread. Otherwise i would have to rewrite a lot of code to accomodate this brief interval of 500 milliseconds.
EDIT: i will try to reformat my status message so the pause is not needed.
Hmya, what you're trying to do is pretty fundamentally incompatible with the Windows programming model. A native Windows program is event driven. Your program is always idle, sitting inside a loop started by Application.Run(), waiting for Windows to tell it that something interesting happened that it should respond to. Paint requests, mouse clicks, timer expirations, stuff like that.
Your program should respond to this and filter what is interesting to you. When you drop a button on a form, you are always interested in the Click event, generated when Windows sends the MouseDown notification message. Your Click event handler runs some kind of custom code that you write. Like updating a status bar message in your case.
Updating the status bar message half a second later doesn't make a whole heckofalot of sense. What exactly happened during those 500 milliseconds that changed the way your program responds to events? You can call the Update() method of the StatusBar so the new message is visible, then call System.Threading.Thread.Sleep(500) to get what you want. You'll get away with it, the "Not Responding" ghost that Windows puts up takes your program going dead for several seconds.
But that doesn't make a lot of sense, nothing happened during that half second, the state of your program didn't change. It couldn't change, it was dead to Windows and not receiving any messages that would allow it to change state.
Well, that's about as far as I can take this. Please update your question and explain why you need to do this. Just in case: if you're contemplating this to fake doing something important for half a second, your user will not be impressed. She'll eventually notice your UI is dead for half a second without anything to show for it.
You have two choices:
Use a timer as you suggested. Split your method up into two methods, foo1 and foo2. Use the foo1 to start the timer and run foo2 in the callback.
Use a BackgroundWorker for running the entire function and use Thread.Sleep on the worker thread.
From your update it seems that the only thing you want to do is change a single field. I would definitely recommend the first method: using a timer. Starting a BackgroundWorker for this task is overkill and will just give you unnecessary extra work and complications.
Instead of pausing the UI directly for 500 ms, you can always use a BackgroundWorker. That will cause your callback to run in a separate thread, where you can use Thread.Sleep to pause it without blocking the UI. Then when you are done, just update the status bar with your new message.
More context to the question would be helpful.
Thread.Sleep(50) will pause the current thread for 50 milliseconds. If you're doing this in the UI thread, then yes, it will freeze the UI for 50 milliseconds. However, if you use a different thread to do this processing, then calling Sleep on that thread will pause it for 50 milliseconds without freezing your UI thread.
See Marc's answer to this question for an example on using a BackgroundWorker instance to do what you need.
In C# your best bet is to use the Timer and fire a callback.
In F# there is an awesome way to do what you want, see
F# async on the client side
which shows how to write straight-line code and have the language take care of the callbacks for you.
You need to allocate another thread. In that thread you Sleep(500) and change the needed data. Caution: you would need to use the original thread's dispatcher, because the data related to UI should be usually updated from the GUI thread.