Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29253 Discussions

Sporadically unresponsive Stop and Close (X) buttons in multithreaded app (based on ThreadDlg)

drstevekramer
Beginner
433 Views
Hi, folks. I used the approach shown by Jugoslav Dujic in hisThreadDlg sample code (http://www.geocities.com/jdujic/fortran/other/threaddlg/threaddlg.htm) to launch a computationally intensive calculation in a separate thread. The single argument to the number crunching routine in the worker thread is the Dlg dialog variable so that the worker thread can update a progress bar in the main dialog, and it can stop the calculation if the user presses the Stop button based on the value of a global Logical variable declared as VOLATILE.
The progress bar updating in the main dialog works fine, but I have found that the Stop button does not always work. In debugging, I have set breakpoints in the Stop button callback routine, and sometimes, even though the button reacts graphically to being pushed, the breakpoint in the callback routine is not triggered. I have even puta breakpoint in the DlgWmCommand routine of DFLOGM.f90, and when the Stop button fails to work, DlgWmCommand is not called either.
Within the IsCancelSignalled function called by the worker thread, I have tried adding a call to ProcessMessages to process messages occasionally within the worker thread, as suggested by Jugoslav here -> http://softwareforums.intel.com/ids/board/message?board.id=5&message.id=3958, but the problem of the unresponsive Stop button remains.
Also, although I have a control with an ID of IDCANCEL, the system Close (X) button in the upper-right corner of the dialog also fails to respond during the times when the Stop button is unresponsive.
Does anyone have any suggestion about why the calling thread might be intermittently failing to process dialog messages when the worker thread is running? How should I debug this problem? Any suggested workarounds?
Thanks in advance,
Steve
0 Kudos
1 Reply
Jugoslav_Dujic
Valued Contributor II
433 Views
I have no idea what is going on, yet...
WM_COMMAND ultimatively originates from a WM_LBUTTONUP (not down!) on the button. First, you could check with Spy++ whether the button receives that message.
WM_COMMAND/BN_CLICKED, however,is sent (via SendMessage), not posted (going through the message queue) directly from button's WndProc to DialogProc and then into DFLOGM. So, I guess the culprit is lack of WM_LBUTTONUP on the button. Reasons? Can't tell offhand (stale message loop? mouse capture?), but please check that fist.
Jugoslav
0 Kudos
Reply