Error when launching a dialog in debug mode

Hi Wanting2LearnMan,

a stack overflow most probably results from calling a function recursive which never terminates (or i.e. two functions which call each other or a message handler function which itself causes the handled message to be sent, i.e. calling RedrawWindow from a WM_PAINT message handler).

The problem here is that the call stack cannot e displayed any more so you can only locate the problem by debugging - first set a breakpoint in CMainMenu::OnInitDialog and step through its code and see if the stack overflow happens there.

Since it seems the stack overflow results from a message handler function maybe a possibility to find the message which causes the problem by using the 'Spy++' tool - start the application, then find the window with Spy++, select 'Spy->Log messages', then press the launch button. This way maybe you will see which messages are sent until the stack overflow happens.


The assertion in 'afxwin2.inl' simply indicates that CWnd::GetFont() is called for a CWnd-object which isn't attached to a existing window. Do you see in the call stack from where the 'GetFont' was called?

Hope that helps,

ZOPPO

do you use TRACE() macros? if yes, it had some limit for the buffer length

Thanks for the replies:

>>do you use TRACE() macros
No

>>first set a breakpoint in CMainMenu::OnInitDialog
I have set a breakpoint here but it never reaches here.  I get the error when it comes to:
CMainMenu dlgMainMenu;
and not
dlgMainMenu.DoModal();

I have nothing in the constructor or CMainMenu either.

I notice that when I step into the code it gets to the constructor then the message appears:
CMainMenu::CMainMenu(CWnd* pParent /*=NULL*/)
      : CDialog(CMainMenu::IDD, pParent)
{    <---- THE ERROR MESSAGE APPEARS JUST HERE
      m_bActivate = true;

hm - IMO this either means the CDialog-constructor fails or the constructor of a member of CMainMenu fails - I guess the second one is the reason.

What members are declared in CMainMenu? Do you use any classes there which themselve do something in ther constructors?

ZOPPO

>>The assertion in 'afxwin2.inl' simply indicates that CWnd::GetFont() is called for a CWnd-object which isn't attached to a existing window. Do you see in the call stack from where the 'GetFont' was called?

Yes I have noticed that the CMainMenu class has a variable of:
CMyBmpButton m_BitmapButton;

now CMyBmpButton is a class derived from CBitmapButton and in its constructor it calls a function which does:
                     LOGFONT lf;
      memset(&lf, 0, sizeof(LOGFONT));

      lf.lfHeight = nHeight;
      lf.lfWeight = nWeight;
      lf.lfCharSet = ANSI_CHARSET;
      lf.lfOutPrecision = OUT_DEFAULT_PRECIS;
      lf.lfClipPrecision = CLIP_DEFAULT_PRECIS;
      lf.lfPitchAndFamily = VARIABLE_PITCH|FF_ROMAN;
      lstrcpy(lf.lfFaceName, szFont);

      m_fontInfo.CreateFontIndirect(&lf);
      SetFont(&m_fontInfo);                         <----PROBLEM IS HERE

It is at this SetFont(&m_fontInfo); line where it bombs out.

Why is this a problem in debug and not release, how can I fix this???

Ah, then it's clear. You can't call most functions on CWnd-derived classes before they are attached to existing windows. The windows themself are created inside the DoModal() function. I guess you added that member using ClassWizard or similar, so that member won't be attached before the first call to CMainMenu::UpdateData() - this is normally called the first time from 'CDialog::OnInitDialog'.

So, best is you add a initialization function, i.e. 'Init' to CMyBmpButtom and call this for the 'm_BitmapButton' in CMainSetup::OnInitDialog after CDialog::OInInitDialog is called.

ZOPPO

The difference between Release and Debug is that the Debug build tries to show an ASSERTion dialog - for any reason this leads to the stack-overflow. In Release build this ASSERTion isn't shown, the 'SetFont' simply fails since the WM_SETFONT (which is called by CWnd::SetFont) is simply sent to a NULL-window.

Excellent.  Thanks.

One more problem before I can hopefully close this.

When I go to launch another dialog it bombs out again in the OnINit where I try to do:
m_bmpOpt1.AutoLoad(IDC_MENU1_BUTTON, this);
      m_bmpOpt2.AutoLoad(IDC_MENU2_BUTTON, this);
      m_bmpOpt3.AutoLoad(IDC_MENU3_BUTTON, this);
      m_bmpOpt4.AutoLoad(IDC_MENU4_BUTTON, this);

      m_bmpOpt1.LoadBitmaps(IDB_XPBUTTONGREEN_BITMAP, IDB_XPBUTTONGREEN_BITMAP, 0, IDB_XPBTNMENUDIS_BITMAP);
      m_bmpOpt2.LoadBitmaps(IDB_XPBTNMENUUPGREENMED_BITMAP, IDB_XPBTNMENUUPGREENMED_BITMAP, 0, IDB_XPBTNMENUGREENMEDDIS_BITMAP);
      m_bmpOpt3.LoadBitmaps(IDB_XPBTNMENUUPGREENMED_BITMAP, IDB_XPBTNMENUUPGREENMED_BITMAP, 0, IDB_XPBTNMENUGREENMEDDIS_BITMAP);
      m_bmpOpt4.LoadBitmaps(IDB_XPBUTTONGREEN_BITMAP, IDB_XPBUTTONDOWN_BITMAP, 0, IDB_XPBTNMENUGREENMEDDIS_BITMAP);


m_bmpOpt1.AutoLoad(IDC_MENU1_BUTTON, this);<<--It BOMBS OUT HERE

this m_bmpOpt1 is also of type CMyBmpButton.

When I step into m_bmpOpt1.AutoLoad(IDC_MENU1_BUTTON, this);
I find that it it eventually crashes here:

// LoadBitmaps will load in one, two, three or all four bitmaps
// returns TRUE if all specified images are loaded
BOOL CBitmapButton::LoadBitmaps(LPCTSTR lpszBitmapResource,
      LPCTSTR lpszBitmapResourceSel, LPCTSTR lpszBitmapResourceFocus,
      LPCTSTR lpszBitmapResourceDisabled)
{
      // delete old bitmaps (if present)
      m_bitmap.DeleteObject();
      m_bitmapSel.DeleteObject();
      m_bitmapFocus.DeleteObject();
      m_bitmapDisabled.DeleteObject();

      if (!m_bitmap.LoadBitmap(lpszBitmapResource))<-- CRASHES HERE
      {
#ifndef _WIN32_WCE
            TRACE(traceAppMsg, 0, "Failed to load bitmap for normal image.\n");
#else      //!_WIN32_WCE
            TRACE0( "Failed to load bitmap for normal image.\n");
#endif       //_WIN32_WCE
            return FALSE;   // need this one image
      }
      BOOL bAllLoaded = TRUE;



I have did the exact same in the previous dialog to load bitmaps like this.

Any Ideas???

When I right-click on IDC_MENU1_BUTTON and select go to definition I see that there are multiple entries in the Resource.h file  like so:

#define IDC_BUTTON5                     1017
#define IDC_D_BUTTON                    1017
#define IDC_MENU1_BUTTON                1017
#define IDC_U14_BUTTON                  1017
#define IDC_SQUAD3_BUTTON               1017
#define IDC_BUTTON1a                    1017
#define IDC_BUTTON6                     1018
#define IDC_E_BUTTON                    1018
#define IDC_MENU2_BUTTON                1018

should all these not be unique??

Hi again,

I guess the problem with 'AutoLoad' is a naming issue - to get 'AutoLoad' working properly you need to have four bitmaps with resource identifer strings (not just numeric IDs) which exactly have to be the text of the button plus the endings 'U', 'D', 'F' and 'X', so if your button's test is i.e. 'StartButton' the bitmaps need to be names 'StartButtonU', 'StartButtonD', 'StartButtonF' and 'StartButtonX' - if this is not correct the 'LoadBitmaps' throws an ASSERTion.

To the other question: the IDs only need to be unique when used within one and the same dialog - in general the resource editer avoid that it can happen that two or more objects have the same numerical ID (except IDC_STATIC, this can occur multiple times).

ZOPPO

>>if this is not correct the 'LoadBitmaps' throws an ASSERTion.

But when I run my program in release mode all is ok, is this expected??

Well, the question is why you need this AutoLoad at all since later on you use LoadBitmaps to load the bitmaps which are finally used. If you wouldn't do this you simply would see no bitmaps. I think you can simply skip these AutoLoad calls ...

ZOPPO

I have 4 buttons on my menu with IDs of: IDC_MENU1_BUTTON, IDC_MENU2_BUTTON, IDC_MENU3_BUTTON & DC_MENU4_BUTTON

I want to do the following:
m_bmpOpt1.SetDrawText(true);
m_bmpOpt1.SetFontInfo(24, FW_NORMAL);
m_bmpOpt1.SetTextColor(COLOR_Black);

If I dont do AutoLoad how do I associate the bitmap with the button then??

Thanks

If I dont

SubclassDlgItem did the trick for me.

All this code has been upgraded from eVC++4.o to VS2005 and has never been put through a debugger til now.

Thanks for all your help.

Excellent answers,

You're welcome - I glad I could help.

BTW: I think it's alway a good idea to test both Debug and Release builds. ASSERTions in Debug builds often show an indication about real problems, sometimes problems which lead to bugs in Release build which cannot be reproduced. And Release builds sometimes show bugs which don't occur in Debug builds since i.e. not initialized variables implicit are initialized in Debug builds but not in Release builds.

Have a nice day,

best regards,

ZOPPO

Yeah I'm trying to trackdown a resource leak in my app and its a real pain....

Thanks

as an afterthought for the memory leak - maybe try to install SOTI and observe in real time what happens with the memory usage when you execute your app on the device