Help with multi-threaded app
-
I've been working on a small multi-threaded app for a while, and I've ironed out all of the bugs except for one. I'm not very proficient with threading in general, so for all I know, this could be a simple problem. The app actually consists of two worker threads and the main GUI thread, but the problem lies within the GUI thread. As a quick note, the worker threads do not touch the GUI thread, so I know that's not what is causing the trouble. I have a simple Browse button that brings up a CFileDialog to allow the user to pick an input file, which works as it is supposed to. There are several other fields of data that the user must enter (basically data that is relevant to the file and how it will be processed). After entering the data, the user then pushes another button that will add this info to a CListCtrl and an internal list that is used for processing the file(s) later. I also have an 'Options' button that brings up another dialog where the user sets various program parameters. Here is where the problem arises: If the user clicks the 'Options' button before they save information to the list of files to be processed, the dialog comes up without any problems. So long as no information has been added to the CListCtrl, the 'Options' dialog works like it supposed to. As soon as any info is added to the CListCtrl, however, the program will lock upon the user clicking the 'Options' button. I know from tracing through the code that the program locks upon the call
hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate, pParentWnd->GetSafeHwnd(), AfxDlgProc);
The above statement is part of DLGCORE.CPP, and is called upon trying to open the 'Options' dialog. Could someone please enlighten me as to what I am doing wrong? Any ideas would be appreciated. --Dean
-
I've been working on a small multi-threaded app for a while, and I've ironed out all of the bugs except for one. I'm not very proficient with threading in general, so for all I know, this could be a simple problem. The app actually consists of two worker threads and the main GUI thread, but the problem lies within the GUI thread. As a quick note, the worker threads do not touch the GUI thread, so I know that's not what is causing the trouble. I have a simple Browse button that brings up a CFileDialog to allow the user to pick an input file, which works as it is supposed to. There are several other fields of data that the user must enter (basically data that is relevant to the file and how it will be processed). After entering the data, the user then pushes another button that will add this info to a CListCtrl and an internal list that is used for processing the file(s) later. I also have an 'Options' button that brings up another dialog where the user sets various program parameters. Here is where the problem arises: If the user clicks the 'Options' button before they save information to the list of files to be processed, the dialog comes up without any problems. So long as no information has been added to the CListCtrl, the 'Options' dialog works like it supposed to. As soon as any info is added to the CListCtrl, however, the program will lock upon the user clicking the 'Options' button. I know from tracing through the code that the program locks upon the call
hWnd = ::CreateDialogIndirect(hInst, lpDialogTemplate, pParentWnd->GetSafeHwnd(), AfxDlgProc);
The above statement is part of DLGCORE.CPP, and is called upon trying to open the 'Options' dialog. Could someone please enlighten me as to what I am doing wrong? Any ideas would be appreciated. --Dean
Try Debug|Break when application hangs. You should be able to have a look at the other threads' stacks - this information may be helpful. Tomasz Sowinski -- http://www.shooltz.com
-
Try Debug|Break when application hangs. You should be able to have a look at the other threads' stacks - this information may be helpful. Tomasz Sowinski -- http://www.shooltz.com
The other threads have nothing to do with the GUI though. In fact, when the app hangs, the other (worker threads) haven't even been started. --Dean
-
The other threads have nothing to do with the GUI though. In fact, when the app hangs, the other (worker threads) haven't even been started. --Dean
But what's on the stack when you Debug|Break? A call to ::CreateDialogIndirect or something else? Tomasz Sowinski -- http://www.shooltz.com
-
But what's on the stack when you Debug|Break? A call to ::CreateDialogIndirect or something else? Tomasz Sowinski -- http://www.shooltz.com
Funny -- this has been a bug for a very long time now, and now that I'm trying to reproduce it so I can see what's on the stack, everything works perfectly. You gotta love it...