WM_KEYDOWN в главный цикл не попадает, а писать "новую EditBoxProc в case WM_INITDIALOG" для каждого EditBoxа кажется не совсем уместным, к тому же к етим EditBoxам уже добавилось 4 ComboBоxа, и что появится дальше никому не ихвестно

поставил SetWindowsHookEx, cool.

при иницизлизации
KeyboardHook = SetWindowsHookEx( WH_KEYBOARD , (HOOKPROC) HookOnKeyboard, NULL , GetCurrentThreadId());

Код

LRESULT CALLBACK HookOnKeyboard(int nCode,WPARAM wParam,LPARAM lParam ) {   Beep(1000,1000);  }

Теперь другая проблемма, ф-я KeybardProc отрабатывет дважды,а на breakpoint остнавливается один раз

1) Может, это WM_KEYDOWN и WM_KEYUP ?

2) Если клавишу держать "long enough", код WM_KEYDOWN повторяется, см. описание WM_KEYDOWN в MSDN

Цитата

... lParam Specifies the repeat count, scan code, extended-key flag, context code, previous key-state flag, and transition-state flag, as shown in the following table. 0-15 Specifies the repeat count for the current message. The value is the number of times the keystroke is autorepeated as a result of the user holding down the key. If the keystroke is held long enough, multiple messages are sent. However, the repeat count is not cumulative. ...

Цитата(Earnest @ 20.6.2005, 05:02)

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

Безусловно это не проблема, однако было утверждение о вешании хука на окно, вот я и уточнил, о чем речь.
Далее. Я считаю использование хуков в данном случае это из пушки по воробьям. Во-первых, они явно создают лишнюю нагрузку. Во-вторых, сама идиология перехвата сообщений внутри своей программы мне кажется странноватой. В твоей программе control flow должен контролироваться логикой программы, а не перехватами.

Цитата(Earnest @ 20.6.2005, 05:02)

Но не могу не согласиться, что для данной задачи проще и естественнее своя WindowProc.

Своя WindowProc - это не обязательно своя реализация ее. Из своей WindowProc вполне можно вызвать стандартную, сохранив ее перед этим вызвав GetWindowLong();

Цитата(Fantasist @ 21.6.2005, 08:13)

Я считаю использование хуков в данном случае это из пушки по воробьям. Во-первых, они явно создают лишнюю нагрузку. Во-вторых, сама идиология перехвата сообщений внутри своей программы мне кажется странноватой. В твоей программе control flow должен контролироваться логикой программы, а не перехватами.

В общем, конечно, правильно. Но...

Цитата(Guest @ 20.6.2005, 20:06)

к тому же к етим EditBoxам уже добавилось 4 ComboBоxа, и что появится дальше никому не ихвестно

Нельзя не посочувствовать автору... Писать хоть и тривиальные, но разные обработчики для новых типов контролов ... бр ...
Хотя я бы, наверно, в такой гипотетической ситуации (только API, без с++), написала свой модальный цикл, как это делается в том же MFC. И уж там, между GetMessage и DispatchMessagе можно делать все что угодно.

может оно и из пушки по воробьям

Но в dialog у меня что то типа GRID для базы, за последнюю неделю добаволось еше пару комбов и с десяток edit, дурдом, на МФС можно было бы за неделю все сделать(я думаю) может даже ActiveX какой впихнуть, а тут толко Си


1) Может, это WM_KEYDOWN и WM_KEYUP ?
тогда бы он на breakpoint остановился бы


короче, в HookOnKeyboard HIWORD(lParam) приходит один раз с нормальным кодом
и тут же с какойто хернеЙ которая > 49000 , что ето такое нигде не нашел
да черт с ней .

Работает ? Не трогай :

Цитата

) Может, это WM_KEYDOWN и WM_KEYUP ? тогда бы он на breakpoint остановился бы

Не обязательно. На WM_KEYDOWN остановится, а WM_KEYUP уже в другой процесс попадет... Т.к. активно в этот момент будет окно отладчика. Поймать KEYUP можно только, если пропускать KEYDOWN...

Цитата

короче, в HookOnKeyboard HIWORD(lParam) приходит один раз с нормальным кодом и тут же с какойто ... которая > 49000 , что ето такое нигде не нашел

Набери в MSDN WM_KEYDOWN и все тебе про параметры расскажут - там битовая структура. Если надо, конечно...