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).
Related
I have very generic question. I tried google it but couldn't find anything good.
So the question is: I have winform application where based on option selected from menu bar, child form/view is loaded and these child forms are used to display reports.
in order to generate report, these child form contains report selection criteria like date, name etc and these value comes from DB. based on values available in DB, we add controls in the view.
Problem comes when screen takes lots of time to load, it freeze UI/application during loading that I don't want.
I also tried run tasks async but since it is using view during the processing, this option failed.
ThreadPool.QueueUserWorkItem(delegate { method.Invoke(presenter, results); });
presenter is my viewpresenter and results is parameters to invoke it. application concluding presenter name at run time and calling its default method using methodinfo.invoke().
Is there any other way to achive the same.
Point: I cannot redesign the whole application to separate out complete DB logic from UI logic as it is legacy application and this might break the application.
If "freezing" is the problem, you could use doevents, see here: Use of Application.DoEvents()
Or, you could go the really old fashioned, vb6 way: run the code that freezes your UI synchronously, but from a modal window shown above your ui. You can event present the user with the progress indicator.
My app consists of 3 tabs, each tab has a DGV, tab 1 and 2 do not contain that much data within the DGV but in tab 3 it can be between 100-5000 rows
The problem im having is that when i start my app, and move to tab 3 it takes a while before anything is displayed..
Im looking for a way to display a loading form to the user while the data is being added to the DGV..
How would i accomplish something like this?
Start loading data on a background thread and monitor the progress(displayed as progress bar).If you are doing it on main thread than you'll hang your interface.
Theres one good article but it is in VB.
Long running operations should be running in a seperate worker thread, commonly BackgroundWorker class. This prevents the UI from locking up during said operation. You can also choose to display a loading dialogue while this thread runs.
The other answers here are correct. But since you specifically asked about a loading window, I remembered a very nice example in Code Project.
In a project I was involved with, we took this example and made it independent. We added static methods called Start and Stop, and the Start method would create a thread, and then load the window, while the Stop method signaled the form it needs to close gracefully.
Hope this helps!
In my Silverlight application, I have an operation that takes a couple seconds and strongly interacts with the GUI (creation of display objects in a big "for" statement)
At first I thought of using the BackgroundWorker to avoid freezing the interface. But I cannot update the GUI directly, so I used the Dispatcher.BeginInvoke, but it still freezes the interface (since the long actions are on the gui part).
What I'd want is display a BusyIndicator while it loads my objects but I want the user to be able to continue working while it loads.
What else can I do? Any suggestions?
Even a busy icon won't help you here. Busy icons, or any other graphics item, require the UI thread to pump messages in order to not "freeze" the UI. If your long running operations are running on the UI thread then even the busy cursor will "freeze".
You need to either
Move the expensive long running logic to a background thread
Break up the UI logic into chunks and let the UI refresh in between them.
Creating UI items in the BackgroundWorker is just wrong. Creating UI elements requires switching back to the UI thread if run from a BackgroundWorker. That is just making things worse than creating them on the main thread.
I assume that lots of the work in the BackgroundWorker is not creating the elements but some additional processing that happens to create UI elements in the middle of everything else.
If that is the case you need to break out the actual generation of UI elements. Replace the generation of UI elements with dummy-classes that contains all specifications required to build all elements. Then you return that collection of specifications (the dummy-classes) and generate the actual elements in the BackgroundWorker.RunWorkerCompleted event.
In an application that I'm writing I have to load a lot of data in a listview after I push a certain button. Because this might take a while, I want to show a simple loading-screen to the user.
I did this by creating a very simple form with 1 label on it. I do a Form.Show() before I start fetching the data, and a Form.Close() once it's finished. This works partially: I get the loading screen, it closes at the right time, but as you can see the label isn't displayed.
I know I should program this loagind screen-problem with the help of a BackgroundWorker, but I'm not a very experienced C# programmer so if I could just somehow force the label to display I would be more than happy.
Is it possible to force this label to display immediately, or do I have to find another solution?
The UI Message pump has no time to update the label / refresh the screen since the loading process takes up all resources.
You can try to force the update of the label, by calling Application.DoEvents(). Although, using 'Application.DoEvents' is imho a 'code-smell', and thus indicates that the design is not that good. So, it should be avoided.
Therefore, using DoEvents is surely not the best solution to this problem. It is merely a symptom-fix.
You've mentionned the best solution already yourself: use another thread to load all the data. (You can indeed use a BackGroundWorker for this purpose, since this will abstract away a lot of plumbing code).
BackgroudWorker is very easy to use , even c# is very powerful and simple langugage
See Here
i am almost sure that , you would not need any more help with BackGroundWorker but if you have any query , you canm always post on SO ?? Collabartive Intelligence is what SO is?
My program consists of a large graphing UI control that I need to spend about 15 seconds re-loading every once in a while. Because the updating code works primarily with the UI control (maybe 90% of it actually sets properties on the control), it would make sense to me to actually let the UI thread handle that. I really don't want the control to visually re-paint while it is loading in a separate thread from the UI.
I also want a progress bar to update as well that lives in the status bar of the same application window. Is there a way to break the rule in this case and re-paint only the progress bar, or should I just open a new application window for the progress bar to live in?
What would you do in this particular case?
If you can break your primary task (ie. updating the graph) in many steps, you can perform each step as a separate dispatcher message. This will allow other messages to be processed, including giving you the ability to update progress information.
The basic pattern is:
Invoke your primary task, passing in zero for the step.
Perform the step.
If there are more steps, queue another message, passing in step + 1.
You can then add in progress updates at the appropriate points in your code.
PS. Not saying this is your best option - hard to tell without knowing all the details. But this is an option.
It is not really true that there is only one UI thread in an application, it is just that most windows applications only ever create UI objects in one thread so this thread becomes "the" UI thread in the application. It is easy to understand why - this makes the code simpler to understand, and protects us from implicit thread binding issues between controls.
This suggests a possible idea, should it prove impossible to improve the speed of updating the control (which is what I would suggest to do first). Create the UI control on a separate thread. You need to make sure that the thread is suitable for UI, that is to say the threading model is STA, and that it will pump messages and not die before the control is destroyed. I don't know if you need to create the parent window in the UI thread as well, or just the control but it may be worth experimenting here.
Find a graphing UI control that is more efficient. Unless the UI thread yields to the message loop any other updates won't happen (and it will slow down your graph control's updates).
I would suggest using a progressbar in a new window (without the form headers). Make it paint the progress bar by reading the shared properties of a graph control. this way you can avoid the thread blocking (sluggish loading).. And it gives you good visual experience (progressive painting on both the controls).