MF C (C ++): Почему элемент управления сверху не получает событие? - PullRequest
0 голосов
/ 06 февраля 2020

На этапе проектирования

  • A (список) рисуется до того, как B (List Ctrl)
  • A изначально невидимо
  • A охватывает часть B

Во время выполнения кнопка переключает видимость A, а когда A становится видимым, помещает ее поверх B (используя SetWindowPos (...)).

Когда A является показано, что он не получает события в перекрывающейся области (например, когда я нажимаю «элемент 4» и «элемент 5» на рисунке ниже). Почему и как это исправить?

enter image description here

Пример кода доступен здесь https://138.197.210.223/test/test.zip.

1 Ответ

0 голосов
/ 07 февраля 2020

Я проверил код и обнаружил, что проблема была вызвана командой ::SetWindowPos() в OnBnClickedCheck1(). Вызываете это, чтобы решить проблему рисования, но вы делаете это, изменяя Z-порядок, и это заставляет элемент управления B захватывать ввод. Поэтому его необходимо удалить, и код в OnBnClickedCheck1() можно изменить, как показано ниже (я упростил синтаксис и использовал MF C вместо команд WinAPI):

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

Рисунок Проблема может быть решена путем установки стиля WS_CLIPSIBLINGS в скрипте ресурса, как предлагается в комментариях:

.
.
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
.
.

Таким образом, это работает для меня, элемент управления A имеет приоритет над B и отправляет LBN_SELCHANGE уведомления, для любого из его пунктов нажал.

И что-то странное, что я заметил, команда DDX_Control(pDX, IDC_LIST_B, m_list_B); в testdlg. cpp запускается дважды. Удалите второй вызов.

Кстати, странный дизайн интерфейса. ?

...