0

Let me give you quick scenario:

I have CEdit decleration in MyDlg.h but never used.

CEdit m_edit;   // member variable of CMyDlg

So, my guess is if I'm not mistaken, any CWndcontrols' m_pWnd gets destroyed through CWnd::DestroyWindow(); function when application gets closed.

In this case, m_edit is not getting be created, that means it has no valid m_pWnd value.

In result, when trying to destroy m_edit, which m_edit.m_pWnd == NULL, I think it may be problem.

So, here is my question:

What is the probability of an error occurring in this situation? and how bad is doing this?




Updating question:

When I run my app, sometimes gives this exception: unhandled exception occurred during a user callback

When I see in callStack, called in this order: ~CMainFrame()--> ~CMyDlg() --> ~CEdit() --> ~CWnd() and it stops in wincore.cpp line804: delete m_pMFCCtrlContainer;

As I explained in old question, I was thinking if it's because of my unused CEdit declaration. But no, even if I commented that out the same issue is happening.

Related to that, there was this answer:

Line 804 in wincore.cpp is only ever hit if m_hWnd != NULL. The statement that m_edit were never used is thus necessarily false. Your code is either constructing a window (through a call to Create or similar), or attaching the m_edit instance to an existing window (commonly done through a DDX_Control in DoDataExchange).

But CEdit variable is not attached to a window (checked in DoDataExchange), also any Create or similar functions are called

So, how do you think what can be the reason of this delete m_pMFCCtrlContainer; issue??

Zrn-dev
  • 99
  • 5
  • Have you tried ? If so - what was the result ? Just guessing, but I would imagine a `CWnd` derived class will handle this situation properly. – wohlstad Nov 24 '22 at 09:03
  • 2
    I'd be very surprised if that is a problem. I'm confident that the destructor for CWnd will check for a NULL window handle before trying to destroy the window. – john Nov 24 '22 at 09:05
  • Actually I faced _unhandled exception occurred during a user callback_ error. When I see in callStack, called in this order: ```~CMainFrame()--> ~CMyDlg() --> ~CEdit() --> ~CWnd()``` and it stops in ```wincore.cpp line804: delete m_pMFCCtrlContainer;```. I checked CMyDlg() and only thing I could guess was this question.. – Zrn-dev Nov 24 '22 at 09:49
  • 2
    If "you never use it" when I why don't you just comment out or delete the variable from the class? – Andrew Truckle Nov 24 '22 at 12:08
  • Unhandled exception? I'm not so sure... There is a `TRACE()` message at line 804 of wincore.cpp, not an exception. A point is, that block of code is executed only if the window handle is not NULL (amongst other checks), so this means that the Win32 control (edit box) has been created and bound with the MFC class instance (m_Edit), ie you have actually "used" it in some way. The warning (trace message) just tells you that the window should have been destroyed before the destructor is reached, but this is not a runtime error, or unhandled exception. – Constantine Georgiou Nov 24 '22 at 12:37
  • 1
    The description and error diagnostic do not match. A default-constructed `CWnd` object has its sole `m_hWnd` member set to `NULL`. Line 804 in *wincore.cpp* is only ever hit if `m_hWnd != NULL`. The statement that `m_edit` were never used is thus necessarily false. Your code is either constructing a window (through a call to `Create` or similar), or attaching the `m_edit` instance to an existing window (commonly done through a `DDX_Control` in `DoDataExchange`). If you need an answer, you'll have to update the question to accurately describe the issue. – IInspectable Nov 24 '22 at 13:08
  • *But no, even if I commented that out the same issue is happening* is a hint that the problem is somewhere else and has nothing to do with the unused control. – j6t Nov 28 '22 at 06:58
  • Use data breakpoints to find the spot where a value is changed that should not be changed. – j6t Nov 28 '22 at 07:00

0 Answers0