Debug vs. Release paint problem
in [MFC]
|
From: jc on 27 May 2010 16:09 Hello, We are developing an MFC application using VC2008. We discovered an "ugly" paint problem. It was suprising to us. that we had not discovered the problem earlier, through all of our testing. What was most suprising, was learning the fact that the problem only exists, in the debug version. The paint problem does not exist in the release version. Basically, when one of our dialog boxes is covered by different application's window, a part of the dialog box does not get repainted, and it shows a default brush color. Unfortunately, the brush color is not the same color that we selected. We do not do anything special in the release version versus the debug version. Any ideas, on how we can fix the paint problem in the debug version? TIA -jc
From: John H. on 27 May 2010 19:00 jc wrote: > We do not do anything special in the release version versus the debug version. > Any ideas, on how we can fix the paint problem in the debug version? Try stepping through in the debugger to see when things manifest themselves as wrong. One thing that comes to mind is when dealing with uninitialized memory. I think in debug mode, MSVC++ will decorate the memory with known values (e.g. 0xcd for allocated but uninitialized dynamic memory). This will not happen in release mode, so it could result in different runtime behavior even though the code looks the same. Assertion macros are another thing that could change behavior between release and debug modes.
From: jc on 27 May 2010 20:15 Hello John, Thank you for taking the time to reply to my posting. Yes, we tried stepping through the code with the debugger, but it is extremely difficult to catch a "paint" problem. We have no dynamically allocated memory. We will make a few more attempts, at trying to isolate the problem with the debugger. Thanks again, -jc
From: jc on 28 May 2010 01:46 Hello John, It was a simple fix. We increased the size of the client rect, the area that was not getting repainted, and all is well. I have no idea, what that has to do with a release build vs. a debug build, but the problem has been resolved. -jc
From: John H. on 28 May 2010 11:31
jc wrote: > Yes, we tried stepping through the code with the > debugger, but it is extremely difficult to catch a "paint" > problem. We have no dynamically allocated memory. Yes, things can get tricky there. One thing I have found that helps is to have dual monitors, so that the working with the IDE on one monitor doesn't force repainting to occur in the app that is running on the other. |