AfxRegisterWndClass() causes crash

Hello,

My app crashes when I attempt to create a CWnd as shown below. I am attempting to create the CWnd with a a parent of type CFormView. Does anyone know why this might be crashing?

Code:

---

CWnd::Create(AfxRegisterWndClass(CS_DBLCLKS), CString(windowName.c_str()), WS_VISIBLE | WS_BORDER, dimensions, parent, NULL, NULL);

---

The call stack looks like this:

Code:

---

mfc100ud.dll!AfxGetInstanceHandle()  Line 21 + 0x20 bytes        C++
mfc100ud.dll!AfxRegisterWndClass(unsigned int nClassStyle, HICON__ * hCursor, HBRUSH__ * hbrBackground, HICON__ * hIcon)  Line 1462 + 0x5 bytes        C++

---

and the line that crashes here us the AfxGetInstanceHandle() call:

Code:

---

LPCTSTR AFXAPI AfxRegisterWndClass(UINT nClassStyle,
        HCURSOR hCursor, HBRUSH hbrBackground, HICON hIcon)
{
        // Returns a temporary string name for the class
        //  Save in a CString if you want to use it for a long time
        LPTSTR lpszName = AfxGetThreadState()->m_szTempClassName;

        // generate a synthetic name for this class
        HINSTANCE hInst = AfxGetInstanceHandle();

---

Where do you call this CWnd::Create from?
Why do you use CWnd:: prefix?

As Victor already suggested, most possible you are calling CWnd::Create... in a wrong way/place, trying to re-create the current window. That asserts in a debug build and may crash in a release one.

One aside note: why are you using boogie-woogie code like this?

Code:

---

... CString(windowName.c_str()) ...

---

As long as you are using MFC, CString MFC class is enough for handling strings.
std::string does not help much, just can give you more headaches.

Ok, i have 3 classes involved in the Create() call. I have the View class, which has a handle to the CWnd derived window. In the view's OnCreate() I have:

Code:

---

int CDisplayView::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
    if(CFormView::OnCreate(lpCreateStruct) == -1)
        return -1;

    CRect rect(0,0,0,0);
    windowHandle_.CreateWin(rect, this, "My Window");
    return 0;
}

---

The windowHandle_ is of type CMapWindow, which is derived from CBaseWnd, which is derived from CWnd. The CreateWin() call is in the CBaseWnd class which looks like this:

Code:

---

void BaseWnd::CreateWin(CRect dimension, CWnd* parent, string windowName)
{
    CWnd::Create(AfxRegisterWndClass(CS_DBLCLKS), CString(windowName.c_str()), WS_VISIBLE | WS_BORDER, dimensions, parent, NULL, NULL);
}

---

Anyone know why this crashes at AfxGetInstanceHandle() ?

Thanks!

I fixed this issue by converting my project to unicode.

Quote:

---

Originally Posted by ekhule

I fixed this issue by converting my project to unicode.

---

This case it's possible you have some mismatch between UNICODE and ANSI strings. If yes, most possible that's because you are mixing STL in MFC. See my first post.

Quote:

---

Originally Posted by ekhule

I fixed this issue by converting my project to unicode.

---

I'm very doubt you did. This is not the way how crashes get fixed.

Quote:

---

Originally Posted by ekhule

I fixed this issue by converting my project to unicode.

---

And how exactly did this fix the issue? If you don't know, then that isn't a fix. You could have had a buffer overrun, and changing the binary executable just moved the bug somewhere else.

Before doing voodo "fixes", I would suggest you change your code back to the way it was, duplicate the error, and actually figure out why the crash occurs so that a proper fix can be established. Otherwise, you have a program that cannot be proven that it's stable.

Regards,

Paul McKenzie

Quote:

---

Originally Posted by Paul McKenzie

And how exactly did this fix the issue? If you don't know, then that isn't a fix. You could have had a buffer overrun, and changing the binary executable just moved the bug somewhere else.

Before doing voodo "fixes", I would suggest you change your code back to the way it was, duplicate the error, and actually figure out why the crash occurs so that a proper fix can be established. Otherwise, you have a program that cannot be proven that it's stable.

---

I totally agree that such fixes are not the way to proceed with such problems with c/c++ code. They might temporarily mask the problem but at some stage they will come back 'to bite you hard'. The only way to deal with these problems is with some hard debugging to find the source of the problem and to then change the faulty code appropriately in the knowledge that you know what you are doing and why you are changing the code. Just 'trying a few things' and seeing what happens is not the way to fix any problem!

...and finally: avoid as much as possible mixing STL in MFC code!
That prevents a lot of painful headaches.
No sweat, a trifle, like a walking in the park. :)

...and an additional remark:
Once you are using MFC framework, why do you need using the "boogie-woogie architecture" like that described here http://forums.codeguru.com/showthrea...25#post2119225?

MFC, good or bad as it is, respects the KISS paradigm.
Any attempt to step beyond, does nothing else but generating headaches.

Quote:

---

Originally Posted by ovidiucucu

...and an additional remark:
Once you are using MFC framework, why do you need using the "boogie-woogie architecture" like that described here http://forums.codeguru.com/showthrea...25#post2119225?

MFC, good or bad as it is, respects the KISS paradigm.
Any attempt to step beyond, does nothing else but generating headaches.

---

For an a different opinion, below is from a codeguru post by
Ronald Laeremans, Visual C++ product unit manager in 2006:

Quote:

---

The MFC collection classes are only there for backwards compatibility.
C++ has a standard for collection classes and that is the
Standards C++ Library. There is no technical drawback for using
any of the standard library in an MFC application.

---

See: http://forums.codeguru.com/showthread.php?391319 for full discussion.


"Further, deponent sayeth naught"