Передача сообщений Win32 API WndProc Key из одного окна в другое - PullRequest
2 голосов
/ 11 ноября 2009

Я занимаюсь разработкой для Windows Mobile на C ++, и у меня возникла проблема - я добавил свое окно класс, и в нем я ввод клавиатуры с моей WndProc реализацией. Проблема в что я получаю неправильные коды и неправильно идентифицирую такие ключи, как ключ func, и, что еще хуже, получаемые значения (wParam сообщения WM_KEYDOWN) как разные значения между двумя телефонами У меня тут для тестирования - кто знает, что будет на других телефонах.

Поработав с ним целую вечность, я обнаружил, что если я только создаю окно из предопределенный класс "EDIT", я действительно получаю ввод правильно (с точки зрения букв / ключей).

Так что проблема должна быть не в телефоне, а в способах получения сообщений (немного новичок в win32, извините за отсутствие знаний). Я пытался поиграться с режимами ввода, но отправка сообщения в мое окно с использованием EM_NUMBERS и т. Д. Всегда не удалась.

Итак, что я хотел бы сделать (хотя я открыт для предложений), так или иначе, просто получить символы из какого-то скрытого окна РЕДАКТИРОВАНИЯ и направить их в мое окно. (Хотя мне все еще нужно, чтобы мое окно имело фокус, чтобы оно правильно реагировало на сообщения, отличные от WM_KEYDOWN и т.п.)

Есть ли способ сделать это?

Это третий раз, когда я спрашиваю об этой проблеме, я бесконечно благодарен всем, кто пытался помочь до сих пор (хотя был бы еще более благодарен, если бы мне удалось решить мою проблему)

Вот соответствующие выдержки из кода:

Класс регистрации:

WNDCLASS wc; wc.style = CS_HREDRAW | CS_VREDRAW;  
wc.lpfnWndProc = WndProc;  
wc.cbClsExtra = 0;  
wc.cbWndExtra = 0;  
wc.hInstance = hInstance;  
wc.hIcon = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_ROADMAP));  
wc.hCursor = 0;  
wc.hbrBackground = (HBRUSH) GetStockObject(WHITE_BRUSH);  
wc.lpszMenuName = 0;  
wc.lpszClassName = szWindowClass;  

window creation  
if (width == -1) width = CW_USEDEFAULT;  
if (height == -1) height = CW_USEDEFAULT;  
RoadMapMainWindow = CreateWindow(g_szWindowClass, szTitle, OVERLAPPEDWINDOW,  
                                 CW_USEDEFAULT, CW_USEDEFAULT, width, height, 
                                 NULL, NULL, g_hInst, NULL);  

MessageLoop  
// Main message loop:  
while (GetMessage(&msg, NULL, 0, 0))  
{
    if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))  
    {  
        TranslateMessage(&msg);  
        DispatchMessage(&msg);    
    }  
}  

выдержка WNDPROC:

case WM_KEYDOWN:  
{  
    WORD Code = (WORD)wParam;  
    int iRepeatTimes = (lParam & 0x0000FFFF);  
    int iScanCode = (lParam & 0x00FF0000) >> 16;  
    BOOL bALT_IsDown = (lParam & 0x20000000)? TRUE: FALSE;  
    BOOL bAlreadyPressed= (lParam & 0x40000000)? TRUE: FALSE;  
    BOOL bNowReleased = (lParam & 0x80000000)? TRUE: FALSE;  
    return DefWindowProc(hWnd, message, wParam, lParam);  
}  

Ответы [ 3 ]

2 голосов
/ 11 ноября 2009

wParam WM_KEYDOWN - это код виртуального ключа, который не обязательно должен быть символом ascii (или unicode) - это просто код, который однозначно идентифицирует ключ на платформе.

Если вы хотите «текст» - вы хотите дождаться сообщения WM_CHAR - wParam WM_CHAR будет фактическим значением символа, введенным пользователем.


Дополнительная информация - в цикле вашего приложения - где вы звоните TranslateMessage - на самом деле TranslateMessage состоит в том, чтобы обнаружить WM_KEYDOWN сообщения, синтезировать и опубликовать соответствующие WM_CHAR сообщения.


TranslateAccelerator, кажется, единственное, что может помешать отправке сообщений. Конечно, иногда очень необычное поведение может проявиться, если proc сообщений Windows (или нет) передает сообщения DefWindowProc в неправильное время. Почему, например, у вас есть явный вызов DefWindowProc в вашем обработчике WM_KEYDOWN? Самый простой способ справиться с этим правильно - использовать DefWindowProc в качестве последней вещи, которую ваш оконный процессор делает так, чтобы все сообщения, обработанные и необработанные, отправлялись туда по умолчанию. исключительным случаем будут сообщения, в которых вы хотите запретить DefWindowProc получение сообщения (WM_PAINT, если вы, например, его обрабатываете).


Вы также продолжаете упоминать, что пытаетесь использовать Edit_SetInputMode - Edit_SetInputMode отправляет сообщение в окно: EM_SETINPUTMODE - это сообщение, понятное только элементам управления EDIT. Поскольку вы зарегистрировали свой собственный класс окна, 'EM_SETINPUTMODE` ничего не будет делать.

0 голосов
/ 15 декабря 2009

Я просто догадываюсь, но, может быть, ваше приложение является приложением Ansi? Это может объяснить, что разные кодовые страницы дают разные коды клавиш. Итак, вы пытались сделать все это Unicode в настройках проекта и соответственно определить строковые константы? И вы попробовали предложение ctacke сделать действительно простое приложение?

0 голосов
/ 11 ноября 2009

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

...