I am building two applications that work on the same database. My problem is that i want to create an automatic update.
Details :
I have a farmacy and on the main form i am displaying some data (list of medicines for example).
I have another application that allows me to add/edit/delete drugs.
I want the first application to update from time to time (1-2 seconds).
I tried creating another thread in the main application and call it with a 2 seconds sleep, but it frezees the application and i don't want that. I want the applications (both of them) to be functional and do a background update somehow.
Ideas ?
A BackgroundWorker would allow you to do this.
If you use an instance of System.Threading.Timer to update the display every X seconds, you can rely on the tick callback to be on a background thread. This will keep the display from freezing.
Remember, you can only access controls on the thread they were updated on. If you need to access a control on a worker thread, you can use the InvokeRequired/Invoke pattern (in WinForms).
Take a look at the Async CTP. It will help you do stuffs in background and update your views (Forms) later.
Related
I have two function in my viewModel, one of which brings data (say from Database which may take time depends on data and network ) and second method generate UI dynamically according to data.
I want to show Busy Indicator on first function call , but i don't want it to be Async .
Is there any way to show RadBusyIndicator without Async Call to the function,
i tried to put the first function in thread and then put the main thread on waiting for the working thread thread, but it doesn't work for me .
Thanks in Advance
If you don't want the long running Data fetch operation to happen on a different thread than the UI one. Then only way I can think of is to have a separate Window with waiting/busy indicator. And create this window instance and show it from a separate thread.
Close the window & thread when the Data Fetch completes. So you are going to need quiet some multi-thread sync & communication.
I know I need to create and add elements to another element on the main UI thread in WPF and you can easily do this when on another thread using the Dispatcher.
However I would like to build my elements off the UI thread then add them all in one batch if possible.
This is because I am building thousands of elements and the couple seconds it takes on the UI thread freezes the whole application.
Is there any way to do this?
I don't think so; however, you can create a smoother user experience by gradually loading the elements without making the GUI hang completely. This can be done by subscribing to the CompositionTarget.Rendering event, which will be called each time a frame is rendered. If you maintain a list of the view models (and corresponding control types) that you need to add, you can create some (say, fifty) of them and add them the visual tree inside the event handler. The next time the event is invoked, you add fifty more, and so on.
It could be possible, what you do is you create two UI threads. On one UI thread you build up your window and show some kind of progress indication (progress bar) on the other UI thread. Make your window visible when you've built it up.
http://eprystupa.wordpress.com/2008/07/28/running-wpf-application-with-multiple-ui-threads/
I recommend to you to use some composite application patter, like Prims. See Patterns For Building Composite Applications With WPF.
Prism allows to decouple your apps components, and also load them on demands.
Also you can see: Prism
Hope this helps...
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.
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.
I'm doing a windows form and would like an audit task to happen every 30 seconds. This audit is essentially checking a series of services on remote computers and reporting back into a richtextbox the status.
Current I have this running in an endless background thread and using an invoker to update the richtextbox in the main form.
Is this best practice? If I made an endless loop in my main form that would prevent any of my buttons from working, correct?
I'm just curious if every time I want to create a periodic audit check I have to create a new thread which checks the status or file or what have you?
Edit: I looked further into the Timer class and decided to go with System Timer as it proved to be better with a longer function. Thanks for pointing me in the right direction.
You should look into the Windows Forms Timer class. You don't want a loop in your main form. It's better to use the timer to fire events which can be processed asynchronously on another thread.
(I assume this is a winform application)
Invoking on the main thread is the way to go. But what about using a timer instead of an endless loop? It gives you more control. And a the timer function would execute on it's own thread.
It's good practice to let long going work execute on a background thread, so that the main thread can work with the UI.