Refer to [a great god, MFC procedures, click the close button in the top, right corner of the dialog box (x) button, can sometimes trigger breakpoints, sometimes not punishment breakpoints, this is what reason, program can run normally, all functions can also be a dog, is to click the close button at top right corner, can appear sometimes that kind of situation, sometimes will not appear, will be the result of a memory leak,

CodePudding user response:

Are there any masters know? When you don't click the close button, everything is normal, functions can be implemented, click the close button, sometimes trigger breakpoints, sometimes don't trigger breakpoints

CodePudding user response:

Before the close of the basically memory leaks, or some illegal operation

CodePudding user response:

Second floor: I have a memory leak, the memory leak will result in that situation?

CodePudding user response:

To solve the problem of memory leaks, see also not exception

CodePudding user response:

Collapsed in the pop-up dialog box, press the corresponding button to enter debugging press Alt + 7 key to view the Call Stack, namely "the Call Stack" from the inside to the following out of from the inner to outer function Call history, double-click a row to the cursor to the Call of the source code or assembly instruction, don't understand when double click on the next line, until we can read ,

CodePudding user response:

Using F5 debugging way let the program run, and then observe the debugging, stack window, look down, look at is which function in your range,

CodePudding user response:

reference 4 floor shiyanzi response:

first solve the problem of memory leaks, and see if they would abnormal

This is when debugging, wrong positioning of the function:
LRESULT a CALLBACK
AfxWndProc (HWND HWND, UINT nMsg, WPARAM WPARAM, LPARAM LPARAM)
{
//special message which identifies the window as the using AfxWndProc
If (nMsg==WM_QUERYAFXWNDPROC)
return 1;

//all other messages the route through the message map
The CWnd * pWnd=CWnd: : FromHandlePermanent (hWnd);
ASSERT (pWnd!=NULL);
ASSERT (pWnd==NULL | | pWnd - & gt; M_hWnd==hWnd);
If (pWnd==NULL | | pWnd - & gt; M_hWnd!=hWnd)
Return: : DefWindowProc (hWnd, nMsg wParam, lParam);
Return AfxCallWndProc (pWnd, hWnd nMsg, wParam, lParam);
}

CodePudding user response:

refer to 6th floor void_main_void response:

using F5 debugging way let the program run, and then observe the debugging, stack window, look down, look at is which function in your range,

LRESULT a CALLBACK
AfxWndProc (HWND HWND, UINT nMsg, WPARAM WPARAM, LPARAM LPARAM)
{
//special message which identifies the window as the using AfxWndProc
If (nMsg==WM_QUERYAFXWNDPROC)
return 1;

//all other messages the route through the message map
The CWnd * pWnd=CWnd: : FromHandlePermanent (hWnd);
ASSERT (pWnd!=NULL);
ASSERT (pWnd==NULL | | pWnd - & gt; M_hWnd==hWnd);
If (pWnd==NULL | | pWnd - & gt; M_hWnd!=hWnd)
Return: : DefWindowProc (hWnd, nMsg wParam, lParam);
Return AfxCallWndProc (pWnd, hWnd nMsg, wParam, lParam);
}
Red is wrong, when positioning the call stack inside is a function of don't understand, write their own programs all have no, the only one, and positioning and MFC automatically generated a place


CGWSQDlg DLG.
M_pMainWnd=& amp; DLG.
INT_PTR nResponse=DLG. DoModal ();
If (nResponse==IDOK)
{
//TODO: when placed in the treatment with
//"ok" to close the dialog box code
}
Else if (nResponse==IDCANCEL)
{
//TODO: when placed in the treatment with
//"cancel" to close the dialog box code
}

For help, programming beginners

CodePudding user response:

refer to 7th floor longbo19910424 response:

Quote: refer to 4th floor shiyanzi response:

To solve the problem of memory leaks, first will see still abnormal

This is when debugging, wrong positioning of the function:
LRESULT a CALLBACK
AfxWndProc (HWND HWND, UINT nMsg, WPARAM WPARAM, LPARAM LPARAM)
{
//special message which identifies the window as the using AfxWndProc
If (nMsg==WM_QUERYAFXWNDPROC)
return 1;
//all other messages the route through the message map
The CWnd * pWnd=CWnd: : FromHandlePermanent (hWnd);
ASSERT (pWnd!=NULL);
ASSERT (pWnd==NULL | | pWnd - & gt; M_hWnd==hWnd);
If (pWnd==NULL | | pWnd - & gt; M_hWnd!=hWnd)
Return: : DefWindowProc (hWnd, nMsg wParam, lParam);
Return AfxCallWndProc (pWnd, hWnd nMsg, wParam, lParam);
}

Red is the wrong place when positioning,

In general is that after a day didn't run the MFC application, easy to close the dialog button after a breakpoint, but over a period of time

CodePudding user response:

One way to check whether resource leaks:
In the process of the task manager to see inside the column selection: memory, virtual memory size, handle number, number of threads, the USER object, GDI objects
Make your program (process) don't quit, cycle through main process many times, the more the better, like 1000000 times or even an infinite loop, record the above numerical, it through at least one hour, as long as possible, such as a month, to record more than the value, if the above two groups of numerical differential is bigger or increasing over time, will certainly have a corresponding resources resource leaks!

Search "GDI leak detection"