Перенос Win32 API WndProc Ключевые сообщения из одного окна в другое

Question

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

После долгой игры я узнал, что если я только создаю окно из предопределенного класса «EDIT» 10, я действительно правильно понимаю вход (с точки зрения букв/клавиш).

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

Итак, что бы я хотел сделать (хотя я открыт для предложений), так или иначе просто получите символы из скрытого окна EDIT и переместите их в мое окно. (Хотя мне все еще нужно мое окно, чтобы иметь фокус, чтобы он правильно реагировал на сообщения, отличные от сообщений WM_KEYDOWN и т.п.)

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

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

Вот соответствующий код выдержки: регистрация

Класс:

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); 
} 

Answer 1

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

Answer 2

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

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

---

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

---

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

---

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

Answer 3

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