Такая ситуация. Пустое диалоговое окно. Обрабатываю сообщенеи WM_KEYUP, WM_KEYDOWN. Все хорошо. Стоит поставить на него или статик или кнопку(любой элемент) и сообщение уже "достается" тому элементу и до самого окна не доходит. Что желать.
А если элементов на окне не один.

легким движением руки этого порешить не получилось (в виду не особо хорошего знания MFC)
Возможные варианты решения:
Если делать прогу без MFC, то там все просто...
Можно использовать DirectInput.
з.ы. грамотные люди, я бы тож очень хотел знать ответ на этот вопрос

Дело в том что как только появляется на форме некоторый визуальный компонент Windows передает фокус ему и все сообщения начинает получать этот компонент и соответственно обрабатывать их своими обработчиками по умолчанию. Надо просто убрать с него фокус ввода, если интересно отвечу подробнее...

создай кнопку со стилем PARENTNOTIFY что то типа того. тогда сообщения от контрола будут идти в окно в форме WM_NOTIFY сообщения. но от самого окна также должно все идти как и раньше

Цитата

Надо просто убрать с него фокус ввода, если интересно отвечу подробнее...

Надо...
Спасибо...

Одна из возможных проблем: для того что бы убрать фокус ввода с компонента на окне как мне кажется само окно должно иметь возможность получить этот фокус... для этого окно нужно создавать со стилем WS_TABSTOP
второе что нам нужно это сделать так что бы если кнопка по каким либо причинам получила фокус то чтобы она его тут же отдавала (типа не тронь бяку)
Для этого мы можем задать ей стиль BS_NOTIFY и она будет пересылать все свои нотификационные сообщения родительскому окну...

А вот сами сообщения
#define BN_CLICKED 0
#define BN_PAINT 1
#define BN_HILITE 2
#define BN_UNHILITE 3
#define BN_DISABLE 4
#define BN_DOUBLECLICKED 5
#if(WINVER >= 0x0400)
#define BN_PUSHED BN_HILITE
#define BN_UNPUSHED BN_UNHILITE
#define BN_DBLCLK BN_DOUBLECLICKED
#define BN_SETFOCUS 6
#define BN_KILLFOCUS 7
#endif /* WINVER >= 0x0400 */

Вобщем я так понимаю тебе нужно отлавливать нотификационное сообщение BN_SETFOCUS (возможно и сообщение при нажатии WM_COMMAND)
и передавать фокус своему окну SetFocus(HandleMyWindow);

Извини если все это не сработает... если честно я не знаю как правильно работать с сообщениями хотя и приходится их постоянно использовать...
я все это опробывал в билдере а в нем сообщения перехватываются как я понимаю не так как в VC++
если не получится пиши поставлю себе VC++ и будем думать вместе...

Может уже не актуально, но вдруг кому-то понадобится (сам искал все утро):
для обработки ЛЮБЫХ сообщений до того как они будут переданы соответствующим дочерним окнам
используем в MFC - BOOL PreTranslateMessage(MSG* pMsg) т.е. CTRL+w ->Messages->PreTranslateMessage
(можно и вручную), после чего для обработки, например, клавиатуры вставляем код:

BOOL CCommanderDlg::PreTranslateMessage(MSG* pMsg)
{
// TODO: Add your specialized code here and/or call the base class
if (pMsg->message==WM_KEYDOWN && pMsg->wParam== VK_DOWN) {
AfxMessageBox("Нажата клавиша вниз!");
}
return CDialog::PreTranslateMessage(pMsg);
}

не с++, все на API.

есть диалог, на нем два десятка EditBox и две кнопки

в главном цикле диалога ловлю любые изменения в любом EditBox которые EditBox видимо посылает сам (типа я изменился)
проблема.
не могу отловить WM_KEYDOWN для служебных клавиш (Insert/Home/End)

Могу конечно создать личный обработчик для каждого EditBox, но как то уж очень грамоздко.
у кого какие идеи ??

Цитата

не могу отловить WM_KEYDOWN для служебных клавиш (Insert/Home/End)

а по моему для этого WM_SYSKEYDOWN нужен

Это сообщение отредактировал(а) chaos - 16.6.2005, 06:11

WM_SYSKEYDOWN ловит Shift/Ctrl/Alt ;(

Цитата

Могу конечно создать личный обработчик для каждого EditBox, но как то уж очень грамоздко. у кого какие идеи ??

1) Обработчик может быть один -> новая WindowProc -> класс для всех ваших edit'ов.
2) По-моему Hook, повешенный на окно, должен ловить сообщения детям/от детей, но точно не помню...

Цитата(Earnest @ 17.6.2005, 17:23)

2) По-моему Hook, повешенный на окно, должен ловить сообщения детям/от детей, но точно не помню...

О каких Нооках идет речь? Если те, что SetWindwsHookEx - так они вешаются только на поток/процесс.

А так просто своя WindowProc обычно выручает.

Да, SetWindowsHookEx, WH_KEYBOARD, можно повесить на поток, которому принадлежит окно и ловить весь клавиатурный ввод. Хотя в hook-процедуру окно не передается, но узнать, кто сейчас в фокусе, не проблема.
Но не могу не согласиться, что для данной задачи проще и естественнее своя WindowProc.

>>для данной задачи проще и естественнее своя WindowProc.

Куда уже проще

Код

BOOL CALLBACK cogoDlgProc( HWND dialog, UINT message, WPARAM wParam, LPARAM lParam ) { switch ( message ) {   case WM_INITDIALOG :     initialize_dialog( dialog ) ;     return TRUE ;   case WM_COMMAND :         do_Command( dialog, message, wParam, lParam ) ;      return TRUE;   case WM_CLOSE :     close_Dialog( dialog ) ;      return TRUE ;   default :     return FALSE ; } }

Только case WM_COMMAND на нажатие клавиш Home/End не реагирует
Пришлось создать новую EditBoxProc v case WM_INITDIALOG :

SetWindowLong( GetDlgItem( dialog, NUM_0 ),GWL_WNDPROC, (LONG) EditBoxProc ) ;

а потом в EditBoxProc ловить WM_KEYDOWN


Все же попробую SetWindowsHookEx, может получится

Цитата

Только case WM_COMMAND на нажатие клавиш Home/End не реагирует

Естественно, это не WM_COMMAND, а WM_KEYDOWN, причем приходящие одному из дочерних окон.

Цитата

Пришлось создать новую EditBoxProc v case WM_INITDIALOG :

Собственно, именно это и имелось в виду.