Short version: How do I pump for messages while at a particular stack frame so I can wait for a custom dialog to return while blocking, just like Window.ShowDialog(). Ideally avoiding async or multiple threads.
I am creating a custom Notification Dialog for my application which supports a set of different display modes.
It can be used as a blocking popup, exactly like MessageBox.Show, by using Window.ShowDialog(). It can also act as a non-blocking message box by using the regular Show command.
However, I want to have third mode, where the dialog can be shown with a non-blocking call, but then later another call will block until the user closes the dialog. This is so I can let the user know earlier on when they will need to do something, but when the time comes, if the user hasn't already dismissed it the main application thread will block.
Keep in mind I’m not using Async with this.
Basically:
NotifyDialog.ShowNonBlocking(“please remove the device and click OK.”);
//do stuff, wait for processing to complete.
//processing now done, we really need to get rid if the device before the next thing starts.
NotifyDialog.BlockUntilClosed(); //disables main window, starts nested message pump here.
I first wrongly assumed that creating a new Window would create a new thread and Dispatcher queue automatically, so I tried using a condition. Turns out that it doesn't create a new thread. I assumed this because Window.ShowDialog() blocked while the new dialog was shown, but as far as I can tell now it just disables all other windows, and kind of hijacks the message pump (I assume that the stack would look something like main -> message pump -> event that lead us to the ShowDialog() call -> new, hijacked message pump loop.)
Anyway, I would like to reproduce this behavior manually so in my NotifyDialog.BlockUntilClosed() call I can hijack the message pump, disable my main window, and wait for the window to close.
If this isn't possible, I’m going back to the plan of launching the window on a new thread, which there seems to be a handful of articles explaining.
I want to keep this easy to use, so I don't want to depend on closed event callbacks that the consumer would need to use, and my application isn't using Async right now, so I can't await the result.
Alright, figured it out.
The dispatcher has a method called PushFrame. This function is a simple event loop. It's a while loop that won't return until the continue flag on the passed in DispatcherFrame is set to false, at which point it stops processing events and returns.
The solution was to add a member Dispatcher frame to my class, and construct it and pass it to the Dispatcher with the PushFrame call when the BlockUntilClosed method was called. Then, in my Close event handler for the dialog, I set the continue flag to false. Once the Dispatcher finished processing the close event, it detects that the continue flag has been cleared and returns.
There is a fairly good description here:
DispatcherFrame. Look in-Depth
Related
Using Winforms,
If I'm on a thread that is not the "main" ui thread can I safetly
Create a Form,
Call ShowDialog on that form
It seems like I would be obeying the rule of:
Winforms controls must be modified on the thread they were created in.
From some of the reading I've done it seems like ShowDialog will create its own message pump so that I don't need to worry about the Form being created on a thread that already has a message pump.
The background of the question is that I get a callback where I'd like to display some Winforms UI, but I don't have access to any other UI that I could use to Invoke to the main thread.
That's roughly correct, albeit that it is pretty important that you call the thread's SetApartmentState() method to switch the thread to STA. Important for many UI operations, including the clipboard, drag and drop and the shell dialogs. And that you usually have a crummy Z-order problem when the form that you create on the thread is not in the foreground and hides behind another window. Or has the nasty habit of actually do move in the foreground when the user doesn't expect it and grab a mouse click or keystroke unexpectedly.
These are hard problems to fix, they do make your app flaky. There's no good reason to not have a reference to invoke to, you can also pass it to the class some way some how. You've always got Application.OpenForms[0] to fall back on, if really necessary.
Yes, you can do that, but if you want the dialog to actually act like a modal dialog (i.e., block the parent Window, which I assume you want since you are calling ShowDialog) then be prepared to be disappointed.
What problem are you actually trying to solve here. It sounds like you want a modal dialog that doesn't block, which is a bit strange. If you explain the problem at hand there may exist a solution you have not yet considered.
I'm using the following code to open a new form (that is for user input) in my function:
Form4 f4 = new Form4();
f4.mainform = this;
f4.get_Text(matchString);
f4.ShowDialog();
It's working perfectly when not threading, but when I try to run the function on two threads I only get 1 form popup. How can I adjust it so that it will support more than one thread?
You can open a form from any thread, you just need to start a message loop on the new thread, such as:
Application.Run(f4)
The Run method will not return until the form is closed. It can cause issues, though, so you need to be careful and know what you are doing. Unless it's a real pain to do, I would sooner consider redesigning your code to be more asynchronous. For instance, you could create a event handler method to listen for the form's closing event.
The WIN32 Message pump runs on one thread -- the GUI thread. As soon as you .ShowDialog(), the c# stops until the user closes the dialog. Even if you use .Show() to avoid a "stop and wait for the user to push ok", you still must handle all GUI events on the GUI thread by .Invoke()ing to the GUI thread.
The way to support multi-threaded-ness is by doing non-GUI work on alternate threads.
ShowDialog does pump messages so it would technically work on a separate thread without needing a dedicated message loop. However, what you currently have looks like a recipe for disaster because that form appears to hold a reference to another form via f4.mainform = this and it is presumably trying to access it. You simply cannot do this without littering (and I mean that literally) your code with a bunch of Invoke or BeginInvoke calls.
Furthermore, running UI forms on a thread other than the main UI thread generally does not work well. There are a few obscure problems you can run into. For example, since there would be two UI threads in play it is possible to have 2 active modal dialog boxes open. One might be hidden behind the other and the end user would not see it. This reason, among others, is why it is not generally recommended to use more than one UI thread.
My advice is to figure out a way to make this work with a single UI thread. Your life will be simplier if you do.
I have a lengthy process that I can't run asynchronously, so just like Explorer when you're copying files, I have a progress dialog. I show the dialog modally, then perform the operations (we'll call it copying files to keep it abstract), update the progress dialog, and pump messages with Application.DoEvents() to keep the application main frame painting and responsive.
Since the dialog is modal, the user isn't able to do anything other than watch or cancel. In other words, they can't select a menu item or click any buttons.
I've always believed Application.DoEvents to be extremely evil, because you could re-enter code you didn't intend to be re-entrant. But in this case, since the progress dialog is modal, I can't see a reason why this is a bad or dangerous solution.
Am I overlooking something, or is pumping messages with Application.DoEvents a legitimate thing to do with a modal dialog up?
I don't see a particular problem with this limited use of DoEvents. We successfully use it in very limited situations like this when background processing isn't an option.
Normally, your UI thread in the application will pump messages. Now even though modal dialogs run their own message pump this is merely to keep the call behavior as expected (e.g. the call only returns when the modal dialog is closed), it is not a necessity for dealing with the modal dialog per se. (See also this blog post from "the old new thing" blog).
Therefore it isn't really a problem to call Application.DoEvents() either, even though it usually shows a design problem (e.g. non-cooperative processing in the UI thread) and it may cause re-entrancy if some window messages and event handlers are triggering each other - but that's independent of dialog modality.
I'm writing a c# application that requires user authentication.
When the user hits the log in button, quite a bit of stuff is done in the background, but I'm having trouble informing the user that something is happening, and that the program isn't just frozen.
I have some hidden text fields that I would like to have show up after they log in, while this stuff is running, but I can't seem to get it to show up.
Basically, when the user hits the log in button, it checks to see if their credentials are correct, then the messages should show up, and then either some other functions might run, followed by a different form being shown.
After the credentials are checked, and I know that the user is valid, I tried running this:
please_wait.Visible = true;
But it doesn't change when it gets to that point in the code.
I've tried threading it, to see if that would help. Instead of calling the above line, I just start a thread that does it.
That doesn't work either. The field still doesn't show up.
If I return out of the function right after I either start the thread or change the Visible property, it works just fine.
How do I get it to work fine and have more code run after the change?
The problem isn't that you need to update the UI from a background thread. Rather, it's that you should be performing your long-running task in a background thread and marshalling updates to the foreground. This is frequently done via a BackgroundWorker with progress notification (on a progressbar, for example).
Basically, your UI foreground thread is either loaded or blocked doing work, so it isn't handling messages in its message queue to update your user interface.
Along with what Greg recommends (which is certainly the first step if you're not already doing it) you may also need to give up some quantum.
If you are taxing the scheduler, it's possible that the UI updates (which are pretty low priority) may be getting preempted until your worker is complete. Adding an Application.DoEvents (or maybe Thread.Sleep(1) in the background thread) could give the UI a little scheduler time to paint.
Have you tried adding a call to Application.DoEvents()? It's a hack, but it's all you sometimes need.
I'm building a UI for a program, and I can't figure out why my progress bar won't become visible after the convert button is clicked.
private void convertButton_Click(object sender, EventArgs e)
{
toolStripProgressBar.Visible = true;
...
toolStripProgressBar.Visible = false;
}
I ran into a similar problem with tkinter in Python, and I had to call a function to update the idle tasks. Is there a way to do this with windows forms without using threads?
Edit: On a side note, this is a progress bar in a toolStrip that also contains a label that gets updated with status bar text. Is there any way to get the label on the left side and the progress bar on the other instead of right next to each other on the left?
Well, there is a way to do this without using threads (Application.DoEvents) but I strongly recommend against you using it. Re-entrancy is nasty, and you really don't want the UI thread tied up at all.
Use BackgroundWorker instead - it's easy, and it's pretty much designed for progress bars. It takes the hassle out of using a separate thread and reporting progress back to the UI thread. No need for Control.Invoke etc - it takes care of that for you.
There are lots of tutorials for BackgroundWorker - it shouldn't take you too long to get going with it.
Per the question you asked for the way to do this WITHOUT threads, that is to do it with Application.DoEvents();. (Just add that call right after setting the progress bar as visible.)
Now I do agree with Jon Skeet though that BackgroundWorker is a better way of doing this, but it does use a separate thread.
You need to execute your process in a thread separate from the UI thread, and then have it periodically report back to the UI thread with it's progress. If your convert operation is working inside the UI thread, it will simply go unresponsive until the operation is complete.
The progress bar can only become visible when it is allowed to paint which occurs during the processing of messages. Message processing cannot normally happen while you are in the middle of an event handler. If you want the progress bar to show up you will have to set the visiblitity to true, start a background thread to complete the work and return from the handler.
I'm guessing the problem is that the "..." in your code is a long-running process. UI updates are not instantaneous, but must run through the message queue in windows and then be painted to the screen. The queue is pumped and painting takes place in the same thread as your events.
As a result, any long-running tasks need to be moved to a different thread. More than that, your line line of code needs to called after that thread terminates. Otherwise you set the progress bar and then immediately turn it off again.
One way to do that is with a BackgroundWorker control.
Here go two links trying to explain you how things work:
(1) (2)
Now, I will try to explain it as shortly as I can. Most of what happens inside a windows forms application happens in a single thread, usually the same thread Main() runs in. If you open Program.cs, you will see that Main() has a line that looks like the following:
Application.Run(new Form1());
If you debug the application at any moment and examine the call stack, you will see it will trace back to that Run method. This means that a Windows Forms application is in fact a continuous run of the Run method. So, what is Run doing? Run is eating a message queue through which Windows sends messages to it. Run then dispatches those messages to the correct controls, which themselves do things like add text which corresponds to the key being pressed, redraw themselves, etc. Notice that all this happens during and endless loop running alongside a single thread, so weather you are typing or simply moving the window around, loads of those messages are being passed onto the application, which in turn is processing them and reacting accordingly, all in that single thread. Controls can also send messages to themselves through the queue and even you can place messages in the pump via Control.BeginInvoke. One of the things those controls do is to raise events according to what happens. So, if you click a button, the code you've written to handle that click will ultimately and indirectly be run by the Application.Run method.
Now, what is happening with your code is that even though you are changing the visible status of your progress bar to visible and then updating its Value, you are then changing its visibility to false, all in the same method. This means that only after you leave the method, will Application.Run() be able to continue iterating and consuming the message queue, effectively asking the progress bar to update its display. When that happens, you've already left the progress bar's visibility to false, the last thing you did before exiting the method. DoEvents() is a quick and dirty workaround to your problem as it reads the messages in the queue and processes them. I don't really feel comfortable using it as it can bring reentrancy problems.
Using threads is a good solution, but I would recommend using a ThreadPool thread instead of a custom thread in this kind of situation, as I tend to use custom threads only in cases where I have a limited number of long lived threads and I need to control their life cycles. The easiest and most practical way to use threads is to use the BackgroundWorker component, even though I would recommend going through the pains of understanding how to do Windows Forms multithreading with delegates if you want to really understand what is going on.
My solution is to call refresh on the status strip.
I believe this causes the UI thread to repaint the status strip.
toolStripStatusBar1.PerformStep();
statusStrip1.Refresh();
This is for .NET 4.0. Even though this question is old it was the first I found on googling this issue.