MFC much document window
CList deposit of a pointer to a window is open the window, the window is closed when not delete the window from CList pointer
In another parts of the project need to traverse the Clist do some other operating
The code below
For (int I=0; Pos & amp; & i <(UINT) theApp. M_List. GetCount (); I++) {
PView=theApp. M_List. GetNext (pos);
If (pView & amp; & : : IsWindow (pView - & gt; M_hWnd))
{
pView - & gt; Fun (); .//here occasionally cause wild pointer operations
}

In sporadic cases, after the window is closed, the traversal code above IsWindow () and not return FALSE lead to the code above red part will cause the wild pointer manipulation,

What a great god help explain the reason,

CodePudding user response:

Can't you see all the code
Roughly speculate that
The CView is a wrapper for the window, its m_hwnd can also in, but the CView was released

CodePudding user response:

Window of the corresponding window in the Clist pointer when you need to buy to 0

CodePudding user response:

You traverse the View, should go through the document template CDocTemplate to traverse

CodePudding user response:

refer to the second floor schlafenhamster response:

window closes when you put the corresponding window in the Clist pointer 0

but I want to know why IsWindow (pView. M_hwnd) without judgment to the window is no longer exist, this situation is not to happen every time, but also a little big

CodePudding user response:

reference VisualEleven reply: 3/f

you traverse the View, should traverse through the document template CDocTemplate

Because is to want to traverse a CList those views, and don't want to iterate through all the open view,

CodePudding user response:

The

reference 1/f, HDT response:

didn't see all the code
Roughly speculate that
The CView is a wrapper for the window, its m_hwnd can also in, but the CView released

Appear what circumstance can you say this kind of situation, I think the CView lifecycle is greater than or equal to its window, the window is destroyed when the class object does not necessarily destroy it, but the CView object is released, it's window must be destroyed,

CodePudding user response:

Are you sure? Suggest to find out the Attach the Cwnd function and DeAttach (memory is the likely misspelled)

CodePudding user response:

Multithreaded program/process may be interrupted at any time, __try __catch oneself handle exceptions, in order to make sure the program does not collapse

CodePudding user response:

Should be pView problem, not pView - & gt; M_hWnd, CList after pView uninstall, you don't have a synchronized to the corresponding CList Item to empty

CodePudding user response:

Because pView is destroyed, (pView - & gt; M_hWnd) has not changed with the m_hWnd destroyed,

CodePudding user response:

Handle just a structure pointer, related information, record window window is destroyed, if there is no closehandle, then iswindow judgment should be a failure,

CodePudding user response:

https://msdn.microsoft.com/en-us/library/ms633528

A thread should not use IsWindow for A window that it did not create because the window could be destroyed after this function was called. Further, because the window handles are recycled the handle could even point to A company's window.

Window after destruction, the handle may be heavy recycling

https://stackoverflow.com/questions/2344233/validate-hwnd-using-win32-api