Re: Debugger / message pump problems

From: Charles (spacefrodo_at_yahoo.com)
Date: 02/20/04 

Date: 20 Feb 2004 00:22:47 -0800

jollygreenfat@yahoo.com (RBoggs) wrote in message news:<faed1edd.0402101919.6c708e57@posting.google.com>...
> I'm having problems debugging a MFC app in eVC++ 4. The application is
> essentially a container for several ActiveX controls with a
> dialog-based graphical UI. Everything had been working well, until I
> recently added several new dialogs & associated classes. Now when I
> run the debug build of the application through the debugger, at a
> certain point it always seems to lose the main dialog's message pump.
> At this point there is a CEdit-derived object onscreen that has the
> WM_ONCHAR message handled, and also a CButton-derived object w/ a
> click handler. Previously these both behaved as expected; however, now
> as soon as this screen displays, no messages are processed. The
> OnChar, OnClick, and even events firing from the contained controls
> are all unprocessed. The overall application is NOT hung, as trace
> statements running in the background attest. The last thing done was
> to set a flag telling the CEdit's KillFocus handler that it should not
> allow focus to be taken away.
>
> At this point the only way out is to kill the cemgr.exe process on the
> debugging PC. Immediately upon doing this all the messages generated
> on the CE platform get processed, and the debug application runs as
> expected. eVC must be closed & restarted so that cemgr will fire back
> up properly. The only symptom on the CE side is that when the same
> screen is entered, now gwes.exe creates data aborts, but it does not
> appear to affect the program's behavior.
>
> I had of course originally thought that all my new code has some kind
> of flaw in it. However, further trial & error indicates that simply
> commenting out enough code in the application will allow things to run
> as normal. It doesn't matter WHAT code, be it in older "established"
> code or in the new code. It doesn't have to be code that's ever run up
> to the point at which the "hang" occurs -- simply the amount being
> compiled seems to be a factor. This is not a particularly large
> application -- the release exe is only 600K, and memory usage w/ the
> debug build is much less that what the system can handle (and only a
> few K difference from a version that works properly). The ONLY time it
> hangs is in a debug build running with the debugger - a release
> (stand-alone or through debugger) always works, as does a debug
> version run alone.
>
> I'm clueless at this point at what could be the issue, or how I could
> continue with proper debugging of the full application. Any
> help/experience/thoughts would be GREATLY appreciated.
>
> Richard Boggs
> jollygreenfat@yahoo.com

Hi, I am experiencing about the same kind of problem you have with MFC
except mine was on eVC 3.0... My original codes ran fine till I tried
to rearrange a little part of them (basically the OnInitDialog of a
derived CDialog class and the InitInstance of my derived CWinApp
class) to handle a flag condition. If the condition is false, I will
not display a certain dialog. Previously, the code simply displays the
dialog everytime. I have also added a few new bitmaps and dialogs and
toolbars for testing but never actually added any codes to display
them.

When I compile and execute the program on both my Pocket PC emulator
and my device, I discovered that the context menu which should be
activated by a tap-and-hold event did not show up. I have not touched
the MFC message maps for the dialog nor did any big changes that would
seemingly interfere with the MFC message passing (unless that simple
rearrangement of dialog displaying codes from 1 place to another had
somehow prevented normal messages to be processed?).

Another unrelated MFC problem was when I simply added a checkbox to a
dialog to let the user choose between showing or not showing the
above-mentioned dialog but in the end, 2 things happened, (1) when the
appln was run, the dialog was still the old look. (2) Another case was
the dialog couldn't even display and simply crash with an access
violation exception. If I just remove the checkbox, then it would work
again.

I also wish that there were some convenient ways or tools to "debug"
the MFC UI/messaging system instead of digging into the messy MFC
source codes. If any of you know of such things, or u have a solution
to our problems, do appreciate you can help us. Many thanks.

Charles