Thread.Join() and GUI
-
Hi everyone, I have a question about how to handle
Thread.Join() and the cases where the thread is updating using Invoke. The problem is my background thread calls back into a method periodically that usesInvoke()to update some GUI elements. Now, when I callJoin()on my background thread (in response to the user cancelling the job and the application waiting for the thread to finish), the whole application hangs as the subsequentInvoke()calls never return becauseJoin()is blocking the caller thread (i.e. my main thread). Does anyone know how I can get around this?Thread.Sleep()is no use either as I do want the main thread to be responsive and at least handle these UI events. I was under the impression that the message pump was supposed to be active when usingThread.Join()Cheers, Pankaj -
Hi everyone, I have a question about how to handle
Thread.Join() and the cases where the thread is updating using Invoke. The problem is my background thread calls back into a method periodically that usesInvoke()to update some GUI elements. Now, when I callJoin()on my background thread (in response to the user cancelling the job and the application waiting for the thread to finish), the whole application hangs as the subsequentInvoke()calls never return becauseJoin()is blocking the caller thread (i.e. my main thread). Does anyone know how I can get around this?Thread.Sleep()is no use either as I do want the main thread to be responsive and at least handle these UI events. I was under the impression that the message pump was supposed to be active when usingThread.Join()Cheers, PankajWhy would you need Thread.Join() in your main thread? As I told you recently, the main thread should never take long and should never block. Thread.Join() is OK when one background thread needs to wait on another background thread, you should not use it in the main thrad. If your main thread needs to know some background activity is finished, use another mechanism; however most of the time, you should not be interested in when exactly the background activity finishes, all you need to do is set a flag that tells it you are no longer interested, which allows it to exit early and tells it not to produce anything anymore (yes, your code now needs to test that flag on every action you don't want to go on). :)
Luc Pattyn [Forum Guidelines] [Why QA sucks] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, and improve readability.
-
Hi everyone, I have a question about how to handle
Thread.Join() and the cases where the thread is updating using Invoke. The problem is my background thread calls back into a method periodically that usesInvoke()to update some GUI elements. Now, when I callJoin()on my background thread (in response to the user cancelling the job and the application waiting for the thread to finish), the whole application hangs as the subsequentInvoke()calls never return becauseJoin()is blocking the caller thread (i.e. my main thread). Does anyone know how I can get around this?Thread.Sleep()is no use either as I do want the main thread to be responsive and at least handle these UI events. I was under the impression that the message pump was supposed to be active when usingThread.Join()Cheers, PankajI have 2 suggestions: 1. Do not use the
Threadclass unless you have to, because it adds a lot of complexity (couldBackgroundWorkerdo the job?) 2. I would never useThread.Join()unless I really had to... What if you just set a flag to notify the background thread about the cancellation and wait for the thread to complete without callingJoin()? -
Hi everyone, I have a question about how to handle
Thread.Join() and the cases where the thread is updating using Invoke. The problem is my background thread calls back into a method periodically that usesInvoke()to update some GUI elements. Now, when I callJoin()on my background thread (in response to the user cancelling the job and the application waiting for the thread to finish), the whole application hangs as the subsequentInvoke()calls never return becauseJoin()is blocking the caller thread (i.e. my main thread). Does anyone know how I can get around this?Thread.Sleep()is no use either as I do want the main thread to be responsive and at least handle these UI events. I was under the impression that the message pump was supposed to be active when usingThread.Join()Cheers, PankajJust because you call a join does not mean that the function that you are running is terminated. When calling join, the caller (in your case the background process) will block indefinetly as long as the thread has not terminated. If the thread is completed, then the join method will end immediately. To fix your problem, ensure that you are exiting the function that is running in the background thread when the user 'cancels' the request.
-
Hi everyone, I have a question about how to handle
Thread.Join() and the cases where the thread is updating using Invoke. The problem is my background thread calls back into a method periodically that usesInvoke()to update some GUI elements. Now, when I callJoin()on my background thread (in response to the user cancelling the job and the application waiting for the thread to finish), the whole application hangs as the subsequentInvoke()calls never return becauseJoin()is blocking the caller thread (i.e. my main thread). Does anyone know how I can get around this?Thread.Sleep()is no use either as I do want the main thread to be responsive and at least handle these UI events. I was under the impression that the message pump was supposed to be active when usingThread.Join()Cheers, PankajAs others have said, I also recommend the
BackgroundWorker, b/c it works very well and was designed to be used in conjunction with a UI. I'm curious, however, why you need a background thread at all if you do not want your GUI to be responsive. You could just do everything in the main thread if you don't want the GUI to be responsive. Also, have you considered settingEnabled = falseon controls you do not want the user clicking (since you don't want them messing with things). An easier mechanism is to put controls in a panel (or container) and setEnabled = falseon the panel (or container). This way the GUI is still responsive (no stupid white "not responding" window) but the user can't update / click fields either.