I have a C# Windows Forms Application with a progress bar. I want to progress that dynamically based on some method status. I have that method in a separate class, and am creating a new thread for that method, with a delegate to pass the status of the method to the parent thread.
The same situation I am able solve in a WPF application using progressbar.Dispatcher but in a Windows Forms application there is no Dispatcher, even if I use the System.Threading namespace.
progressbar.Dispatcher seems to be available only in a WPF Application.
In winforms you can use the ProgressBar.Invoke or ProgressBar.BeginInvoke to update the control from another thread.
In Windows Form application BackgroundWorker should fit perfectly for your task. In particular, it has ReportProgress method to send progress depending on your calculations and ProgressChanged to track changes from UI thread. See MSDN article for full details
In WinForms the Invoke/BeginInvoke methods are directly on the control objects as you can see from the docs of System.Windows.Forms.Control. So you'd have progressBar.BeginInvoke(...) for example.
Related
I am developing one chat application in windows phone. I am using Deployment.Current.Dispatcher.BeginInvoke method to update the UI, but at the time of using Dispatcher.BeginInvoke the screen will struck. How to solve this or any way to update the UI without stuck?
If you use the dispatcher then you will execute the given code in the UI thread. And while you execute code in the UI thread, the UI is stuck. There's no way around that, so you must make sure to execute only the absolute minimum amount of code in the UI thread. The common pattern is to retrieve/compute the data in a background thread, then switch to the UI only to update the controls. The BackgroundWorker class is a convenient helper to reach this result.
Hi, I've tried to create a Thread in windows phone 8.1 without success.
Althought in msdn documentation is written that Thread is supported, actually do not works (https://msdn.microsoft.com/en-us/library/274eh01d(v=vs.110).aspx)
so I can't figureout how can I create a Thread, I want to create a Syncronization context to execute async on a single thread (not current thread), but just to achieve what event loop do
thanks
update for further information:
I would be more specific:
platform is universal app, so I mean windows 8.1 & windows phone 8.1, no silverlight ecc.
I need to create a thread because I want to create a syncronization context to execute some async code, here is an example about what I mean http://blogs.msdn.com/b/pfxteam/archive/2012/01/20/10259049.aspx
the difference from this link is I would use a specific thread for all async code instead current thread.
thanks again
If you just want to run some code asynchronously, look into using Task.Run. It provides a much simpler mechanism than managing threads yourself.
If you are building an Universal Windows Phone 8.1 app, you can't use the .NET Thread type. If you need more control over the execution, you can use the WinRT ThreadPool.
Finally, if you really really need lots of control, there's always CreateThread if you want to write native code (this has recently been added to the allowed list of APIs for Store Apps, although MSDN isn't updated yet).
What is the best way in C# 4.0 to show MessageBox (or other form) in which elapsed time is presented till different method is done?
I would like to know how to do this using TPL in .net 4.0
thanks for any guideness
I don't think you'll be able to use a MessageBox. But if you're using WPF, you could create a form with controls that are bound to a data object implementing INotifyPropertyChanged which contains the data you want to display (i.e., the number of seconds remaining). You would just then display that form as a modal dialog box in the UI thread, and then update the values of the data object in one of your backgrounds threads (using Dispatcher.BeginInvoke() of course to make sure that the actual update gets marshaled to the UI thread).
I have a taskBarIcon element extending Application Context from which my entire UI is designed. This is because the original functionality of the application was to run a background process and simply provide the icon as a confirmation that the app was running.
However, I am now adding additional functionality in the form of a menu that may be accessed by right clicking the icon, and since the core functionality is running on one thread, and the icon on the main thread, I am having issues accessing the icon in the simple case of needing to display a notification bubble. There are no other points at which the two threads may be accessing the same memory, so synchronization is not really an issue.
I am used to Java, in which this process is far simpler. I've read the articles I can find regarding the Invoke-Delegate dance that C# requires, but none are specific to an object extending Application Context. My current implementation is far too unpredictable to be production safe.
My question is this: How do I send the message to the other process to display the notification bubble, without disturbing the accessibility of the menu? Specifically, a simple example with a UI class extending Application Context and a class on a separate thread calling the invoke method would be very helpful.
I really appreciate any help!
badPanda
You could just as well use a SynchronizationContext object that you assign to SynchronizationContext.Current on the same thread that you create the notification bubble. You would then pass your SynchronizationContext object into whatever component the menu is on and it would use context.Send(....) to send a message. Or, if you have access to the notification bubble component or the form it's on, you could do form.Invoke((MethodInvoker)delegate {....});
I'm looking at creating a tabbed interface which has user controls (possibly written by plug-in developers) within a tabbed or MDI interface. These plug-in controls could unintentionally freeze their GUI thread, and I'd prefer that they not influence user controls in other tabs. Much like Google Chrome creates a process for each tab; but in this case, just threads.
Or perhaps even an MDI interface where the child MDI forms are owned by separate threads?
I've found that while I can run multiple GUI threads at once, the Form level is where they MUST be separated. Any workarounds/ideas?
For those saying this shouldn't be needed, I call bullshit. Google's Chrome browser runs tabs in separate processes for security and UI reasons. I'm merely trying to duplicate this behavior. When the people writing the user controls are sucky plug-in developers, this is important.
No it is not possible to do this in the way you are describing. A control which is owned / affinitized to another GUI thread cannot be directly contained within a control which is owned / affinitized to a different thread in such a way that it's paint function runs on the other thread.
The right way to fix this situation is to write UserControls that don't perform long-running tasks on the UI thread. If the control is blocking and waiting on some computational task, fix that. Make that task run in the background, and have the control display some non-compute-intensive content until it's done. If that task freezes, the control will be frozen in its "I'm waiting..." state, but it won't intrude on the rest of the UI.
If you're using a third-party control that you can't fix, well, in the immortal words of Jay-Z, I feel bad for you, son.
For the most part, controls shouldn't be performing any processing. Their purpose is to provide interactivity between the user and the application. For example, it is not the job of a button to fetch data from a database and present it to the user. That being said, hopefully you are doing your processing in a controls event handler, such as the Click event on the Button control. In your event handler, you can prevent the UI from appearing "hung" by processing tasks in a background thread. The BackgroundWorker is often useful in these situations.
I suggest reading up on Threading. The Microsoft® .NET Framework Application Development Foundation book has a section on threading (even if no other certification books are read, I at least recommend all .NET developers read this book). Just remember not to update the UI from a child thread. Read an example on how to make a thread-safe call to Windows controls if you're not familiar with this approach.
Instead of having or owning different GUI threads, you should view the whole issue from a different angle. Why would you want a thread associated to tab's child control to be freezed? If it does freeze and everything else feezes too, threading aside, that's not done right from ground up.
What JaredPar pointed out is correct, but that doesn't mean you cannot achieve what you want. I assume you want stuff running within a tab to continue running/stopping without affecting other controls and user-experience.
I've done it before in a complex WinForm app. Here are some readings which might give you more insights:
Threading out tasks in a C#.NET GUI
Thread and GUI
Updating GUI from Other Threads in C#
Advanced Techniques To Avoid And Detect Deadlocks In .NET Apps