Под WM5 что-то изменили в обработке нажатий клавиш?

igg

Под WM5 что-то изменили в обработке нажатий клавиш? Не обрабатываются стрелки влево и вправо в OnKeyDown.

Ситуация. Проограмма, сделанная под MS eMbedded Visual C++ (MFC). Имеется диалоговое окно, на этом диалоговом окне - List Control. У этого контрола обрабатывается LVN_KEYDOWN, где проверяется код нажатой клавиши, и если это стрелка влево (37) или вправо (39), выполняется листание страницы назад или вперед.

Все прекрасно работало под WM2003. И я проверил этот код в эмуляторе, пересобрав его под x86 - все работает, то есть, я ничего не испортил. А при запуске этого же exe'шника под WM5 обработка стрелок влево и вправо не работает.

В то же время, например, стрелки вверх/вниз по-прежнему можно обработать, я проверял, вставив отладочный AfxMessageBox, он срабатывает при нажатии стрелок вверх и вниз, и не срабатывает при нажатии стрелок влево и вправо.

Прошу совета. Что может быть не так? Фрагмент кода:

igg

Еще одно интересное наблюдение. Сделал я пустой проект, содержащий только List Control (стиль Report) и обработку этого события. В случае, когда список в List пустой, до обработчика не доходят даже нажатия на стрелки вверх и вниз. А если в список добавить несколько item'ов, то нажатия вверх и вниз доходят, но только если есть куда сдвинуть выделение.

Когда же нажимаешь вверх на самом верхнем, или вниз на самом нижнем элементе, то нажатие клавиши не доходит до обработчика. Очевидно, по аналогичной причине не доходит и нажатие влево-вправо - WM считает, что раз некуда двигать выделение, то нечего и событие до обработчика доводить. Под WM2003 все работает нормально, все нажатия доходят...

Очень неудобная логика. Не знает ли кто, как объяснить ей, что мне все-таки нужно получать это событие?..

alpax

Попробуй выводить куда-то в лог или TextBox все нажатые клавиши - может код не тот? Откуда ты взял именно 37 и 39? Констант подобных никаких не определено в системных хедерах? Если нет, тогда наверно коды кнопок теоретически могут меняться от системы к системе.

igg

alpax,
Нет, нажатия вообще не приходят. Я поставил AfxMessageBox, чтобы он высвечивал все нажатия, посмотри код в первой мессаге. И ничего, просто не доходят события.

alpax

igg

alpax,
Ну, грешить на MFC нет никаких оснований по той причине, что один и тот же exe'шник, запущенный под WM2003 и WM5, ведет себя по-разному. Вот ведь в чем проблема.

alpax

igg

alpax,
Нечем, у меня есть только eVT 3.0, до сих пор хватало Smile

Качать огромные объемы не очень хочется.

Если не трудно, попробуй сам - создай пустой проект, добавь в него CListCtrl в режиме репорт, навесь обработчик LVN_KEYDOWN и в нем - отладочную выдачу с кодом клавиши. После чего запусти и понажимай стрелки джойстика.

Меня смущает, что явно прослеживается иная логика - если действие невозможно, то и не надо событие доводить до обработчика. Это больше похоже на целенаправленную смену идеологии функционирования контрола, чем на глюк. Неясно только, как это с минимиальными затратами обойти...

AE

Думаю, все-таки причина где-то в MFC. Точнее даже в его движке который на КПК в виде .DLL.
Потому как на чистом API все сообщения приходят как положено и совершенно одинаково что на 2k3 что на WM5.

В WM5 стрелки обрабатываются несколько по разному на КПК и на смартфонах - поскольку влево-вправо - используются вместо таба, для выбора текущего контрола. Может быть как раз здесь собака.

К сожалению, к гуру в MFC меня никак не отнести - но попробуй сесть верхом на самый главный windowproc формы, поверх MFC'шного обработчика. Туда-то уж должно бы все приходить. А так, боюсь, тебе все-таки придется спуститься до ближайшего перехода и взять VS2005 Smile

Стоит в нем поотлаживаться, стоит. Особенно если рассчитывать на смартфоны и писать на голом API Smile

igg

AE, о, идея разумная, вполне вероятно, что причина в том, что стрелки теперь работают на смену контролов. Надо посмотреть, приходят ли события о входе в контрол и выходе из контрола. Спасибо.

А VS2005 найду, это не проблема. У нас народ на VFP пишет, у них есть, наверняка. Кстати, обнаружил тут у себя несколько дисков - VS .NET, например, это не подойдет? Еще есть некий диск Visual Studio 6. Как они соотносятся с VS2005?

alpax

igg

Понятно, спасибо. Найду и вернусь к этой теме Smile

alpax

Да, кстати, про 2005. Насколько я понял, там используется MFC уже версии 8.0, и соответствующие DLL не на всех девайсах есть. Кто-нибудь в курсе, как это принято обходить? Можно ли в программе под VS2005 использовать более старые библиотеки MFC? Если нет, надо ли устанавливать MFC8*.DLL (плюс что-то еще?) вместе с ЕХЕшником или предполагается, что новые устройства уже должны ее содержать?

AE

... а Visual Studio 6 - это вообще 98-99 год, и для КПК под ним ничего не соберешь Smile

VS 2005 - это просто наиболее актуальная версия девелоперовской среды от MS. Минус - не поддерживает старые платформы и не умеет собирать под MIPS/SH3.

Что до версий MFC - то (опять-таки чисто умозрительно, ибо чистый API - рулез!) - если собрать проект под 2003 SE - то он будет работать так же как и в EVC4 с соответствующим SDK. Ну и проблем по совместимости быть не должно. Наверное Smile

igg

В общем, расскажу результаты борьбы с данным глюком - может, пригодится кому.

Причина действительно оказалась в том, что стрелки влево и вправо задействованы теперь для навигации между контролами. Непонятно, почему из этого следует, что события не должны доходить до обработчика LVN_KEYDOWN, но так сделано, что поделаешь, MFC живет своей жизнью Smile

Никаким путем добиться перехвата сообщения мне не удалось. В обработчике события потери фокуса узнать, какая клавиша была нажата - влево или вправо - тоже не удалось.

Решил проблему так. Поставил на форму два поля ввода, одно перед списком по Tab Order, другое - после. Через получение фокуса этими двумя полями определяется направление перехода, делается PgUp или PgDn, затем фокус принудительно возвращается списку.

Возник эффект двойного мерцания указателя текущего элемента в списке, который я поборол запрещением перерисовки списка при потере фокуса, и разрешением его перерисовки после отработки перелистывания в SetFocus'ах полей ввода.