CODEWITHSUNDEEP
c++winapimfc
user180574
user180574

Reputation: 6094

MFC (C++): Why control on top does not receive event?

At design stage,

During runtime, a button toggles the visibility of A, and when A is visible places it on top of B (using SetWindowPos(...)).

When A is shown, it does not receive events in the overlapping area (e.g., when I click "item 4" and "item 5" in the figure below). Why and how to fix it?

enter image description here

The sample code can be accessed here https://138.197.210.223/test/test.zip.

Upvotes: 0

Views: 293

Answers (1)

Constantine Georgiou
Constantine Georgiou

Reputation: 3401

I did check the code, and found that the problem was caused by the ::SetWindowPos() command in OnBnClickedCheck1(). You call it to solve a drawing problem, but you do so by changing the Z-Order, and this causes the B control to capture the input instead. So it must be removed, and the code in OnBnClickedCheck1() can be changed as shown below (I have simplified the syntax, and used MFC, rather than WinAPI commands):

void CTestDlgActXDlg::OnBnClickedCheck1()
{
        m_list_A.ShowWindow(m_list_A.IsWindowVisible() ? SW_HIDE : SW_SHOW);
}

The drawing problem can be solved by setting the WS_CLIPSIBLINGS style in the resource script, as suggested in the comments:

.
.
LISTBOX         IDC_LIST_A,114,36,48,42,LBS_SORT | LBS_NOINTEGRALHEIGHT | NOT WS_VISIBLE | WS_VSCROLL | WS_TABSTOP
CONTROL         "",IDC_LIST_B,"SysListView32",LVS_ALIGNLEFT | WS_BORDER | WS_TABSTOP | WS_CLIPSIBLINGS,108,60,60,54
.
.

This way it works for me, the A control takes precedence over B, and sends LBN_SELCHANGE notifications, for any of its items clicked.

And something strange I have noticed, the DDX_Control(pDX, IDC_LIST_B, m_list_B); command in testdlg.cpp is run twice. Delete the 2nd call.

Weird UI design btw. 😀

Upvotes: 1

Related Questions