If I am wrong then please correct me as I am new in this. I have one thread which display image captured from webcam on a windows created using CreateWindowEx() function. Now when i execute my program I can see that my paint code (in WindowProc()) in never reached (called InvalidateRect() from child thread to redraw), checked using breakpoint.
Actually frame capture and display is being done in thread and I think because its in child thread and Window is in Main thread that is why its not able to call paint event.
Can you help me on this
Calling InvalidateRect() from a child thread should make your window redraw. However WM_PAINT is a low priority message, so it is possible that the window doesn't get redrawn if there is too much other activity. Have you tried putting a Sleep() into you processing thread to give the painting a chance to get done?
Related
I have created a Single Dialog application which basically does a series of complex calculation. The application was first created as a Win32 console application and later I decided to add a progressbar and then I converted the console application to a Single Dialog based application. The dialog has a progressbar on it. in OnInitDialog() function of the dialog, I start the calculations. The calculations are running on a worker thread. This thread is created by calling _beginthreadex function. The progressbar is updated by the thread by posting messages to the Dialog by using PostMessage. After the thread has completed execution, I call CDialog::OnOK() function to close the dialog. The issue is that, even after the dialog is closed, the application is not end immediately. It takes nearly 2 seconds to close the application even though the dialog is closed.
Any help to solve this issue is highly appreciated.
Thanks.
It's because your worker thread is still running. The application will not terminate until all threads are finished running. Since your UI thread closes before the worker thread, the window may be hidden, but the process does not terminate until the worker thread has completed its work.
The worker thread might be still running. To make sure that the thread is stopped use events to signal . you can signal an event to kill the thread when the user presses close button in the dialog.
You can check whether the event is signaled inside your complex calculation (may be a loop) and break from it. Thus stopping the thread without any issues.
while(true)
{
//Some complex task
DWORD dwWaitResult;
dwWaitResult = WaitForSingleObject(hwndShutdownEvent,0);
if (WAIT_OBJECT_0 == dwWaitResult)
{
break;
}
}
I am trying to use MFC to create a tool. This tool main job is to sort data. Well, I found that when the tool is sorting, since there is only main thread; therefore, while it is doing sorting work, no dialog boxes can be moved or clicked. Hence, I created another thread to do sorting work and works fine.
But there is another problem after I used a thread. I don't how to make main thread to wait for the sorting thread. I want to do something after sorting thread is done, but right now, main thread just moves onto the next procedures without waiting for sorting thread to finish its work.
Here is snippet
AfxBeginThread(processfiles, tVals) // A thread do its work.
// below I want to do something with the result I got from the thread above.
//But main thread just do its work separately without waiting for the thread to finish its work.
.
please help thanks!!
So write code to do that. Pop up a dialog box. Indicate that the sorting is taking place. Do whatever you want. Have the other thread send your thread a signal when it's done, say by sending you a message with PostMessage.
I used this tutorial http://delphi.about.com/od/kbthread/a/thread-gui.htm to create a class that asynchronously downloads a file from the internet in another thread with a TDownLoadURL. I did this because I want to download a file without blocking the UI thread so the program doesn't become unresponsive during large downloads, the progress bar can update, etc.
I am having a problem because even though I have done the download in another thread (inheriting from TThread and doing the work in the Execute method) the GUI thread seems to be blocked and does not process messages until the download is finished. Here is the code for my class: http://codepad.org/nArfOPJK (it's just 99 lines, a simple class). I am executing it by this, in the event handler for a button click:
var
frame: TTProgressFrame;
dlt: TDownloadThread;
begin
dlt := TDownloadThread.Create(True);
dlt.SetFile('C:\ohayo.zip');
dlt.SetURL('http://download.thinkbroadband.com/512MB.zip');
dlt.SetFrame(frame);
dlt.SetApp(Application);
dlt.Start;
Note: The SetApp method was for when I was manually calling app.ProcessMessages from inside the UpdateDownloadProgress method of my class TDownloadThread. This would keep the GUI from being unresponsive, but it made the progress bar behave wierdly (the moving glowing light thing of aero's progress bar moving way too fast), so I removed it. I want to fix this properly, and if I have to call ProcessMessages there's really no point in multithreading it.
Can someone help me fix this problem? Thanks.
I now have the solution for you!
Calling TDownLoadURL.Execute (your call to dl.Execute in TDownloadThread) results in the action being transferred back into the main thread which is why your UI becomes unresponsive.
Instead you should call ExecuteTarget(nil) which performs no such machinations and works as you intend: the download runs on the worker thread.
At the moment, I am using WaitForSingleObject to wait for a sub-task thread to complete. Unfortunately, this causes my GUI to lock up. What I would like to do instead, is set a handler (in the GUI thread) that will be called after the sub-task thread is complete. Is there another function for this?
What you can do is to let the last thing that your thread does be posting a custom message to your window. Then handle that as a regular message using MFC's message map. If you cannot change the thread code, you can create a new thread that waits for your thread and then sends the message.
As you already noticed, it is not a good idea to lock up the GUI thread...
Edit: Posting the message is done using the PostMessage function as pointed out by Hans in the comments.
Could also have a look at MsgWaitForMultipleObjects (or MsgWaitForMultipleObjectsEx).
These allow a thread to wait for event handles and service windows messages (examine the return value to see what causes the call to return). Examples of usage should be available via a goodle search.
http://msdn.microsoft.com/en-us/library/ms684245(VS.85).aspx
Error Log says:
bool _WebTryThreadLock(bool), 0x3c689f0: Tried to obtain the web lock from a thread other than the main thread or the web thread. This may be a result of calling to UIKit from a secondary thread. Crashing now...
App structure:
worker threads are detached from the MainThread as new data is needed via user interaction, each worker thread feeds data into its own slot in an array. The problem arises only when I use the NavigationController to go "back" to the previous view WHILE a thread is still gathering data. I've tried to send a [NSThread exit] to each thread upon viewWillDisappear thats not going to work...
Any suggestions on thread clean-up upon poppin' the view controller?
So apparently i needed to build in checks to the runloop as well as the didRecieveData loop to watch for a global variable to indicate if the view has disappeared. This in turn needs to toggle the global var, causing all open threads to cancel the connection as well as exit the thread.