TranslateMessage()가 무조건 0이 아닌 값을 반환하기 때문에 번역이 발생했음을 사실 전후에 어떻게 알 수 있습니까?

Question

이것은에서 연속입니다.

비 IME 레이아웃 (영문), TSF가 아닌 IME (Windows XP DDK의 일본어 FAKEIME) 및 TSF 텍스트 서비스 (Windows 7과 함께 제공되는 모든 것)로 실험 한 후에 나타납니다 활성 입력 프로세서 프로파일이 TSF 텍스트 서비스 (즉, TF_PROFILETYPE_KEYBOARDLAYOUT)가 아닌 경우에도 키 입력 및 WM_CHAR 메시지를 처리해야 텍스트 입력을 수행 할 수 있습니다.

내 문제는 내 아키텍처가 텍스트 입력 메시지로 변환 되었기 때문에 현재 키 메시지를 무시할 수 있다고 말하는 방법이 필요하다는 것입니다. 이것이 번역 전후에 일어날 지에 대해서는 상관하지 않습니다. 그러한 번역이 일어나거나 일어 났음을 알 필요가 있습니다. 또는 의사의 측면에서 :

// if I can suppress WM_CHAR generation and synthesize it myself (including if the translation is just dead keys) 
case WM_KEYDOWN: 
case WM_SYSKEYDOWN: 
    if (WillTranslateMessage()) 
     InsertChar(GenerateEquivalentChar()); 
    else 
     HandleRawKeyEvent(); 
    break; 

// if I can know if a WM_CHAR was generated (or will be generated; for instance, in the case of dead keys) 
case WM_KEYDOWN: 
case WM_SYSKEYDOWN: 
    if (!DidTranslateMessage()) 
     HandleRawKeyEvent(); 
    break; 
case WM_CHAR: 
case WM_SYSCHAR: 
    InsertChar(wParam); 
    break; 

키보드 또는 비 TSF IME 통해서, 텍스트 입력을 처리하는 표준 방법은 TranslateMessage()가 WM_KEYDOWN Di의 WM_CHAR 번역을 할 수 있도록하는 것입니다. 그러나 문제가있다 : MSDN는 메시지가 WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, 또는 WM_SYSKEYUP 경우, 반환 값에 관계없이 번역의 0이 아닌

을 말한다.

즉 번역이 발생했는지 확인할 수 없다는 의미입니다.

마이클 카플란 블로그 게시물을 읽은 후 GetKeyboardState()에서 상태 배열을 전달하여 ToUnicode() 또는 ToUnicodeEx()을 직접 사용하여 변환 작업을 수행 할 수 있다고 생각했습니다. The wine source code seems to agree하지만 그들은 와인 특정 또는뿐만 아니라 실제 윈도우에서 수행해야하는 경우 잘 모르겠어요 두 가지 특별한 경우가 있습니다

• VK_PACKET는 -에서 직접 WM_CHAR를 생성하는 메시지의 LPARAM
• VK_PROCESS - 와인 특정 함수 또는 문서화되지 않은 imm32.dll 함수로 보이는 함수 ImmTranslateMessage()을 호출합니다. 나는 사실이다 말할 수 없다

그리고 와인도 WM_KEYUP와 WM_SYSKEYUP와 아무것도하지 않는다; 다시 말하지만, 이것이 와인에만 사실인지는 모르겠습니다.

그러나 TSF를 사용하는 프로그램에서 이러한 경우에 대해 걱정할 필요가 있습니까? 그리고 제가 그렇게한다면, "공식적인"방법은 무엇입니까? 그리고 심지어 그때, 내가 무엇을 할 것이냐고 WM_KEYUP/WM_SYSKEYUP; 그 사람들도 ToUnicode()에 보내야합니까? WM_CHAR이 있다면 특별히 내 창에서 WM_KEYUP을 (를) catch해야합니까?

아니면 그냥 TSF에서 TF_PROFILETYPE_KEYBOARDLAYOUT 프로세서를 처리하도록 허용 할 MSDN TSF 샘플에없는 항목이 누락 되었습니까? 나는 TSF가 투명한 IME 패스 스루를했다고 생각했지만 FAKEIME 샘플을 사용한 나의 실험은 그렇지 않았다 ...? Firefox와 Chromium 모두 TF_PROFILETYPE_KEYBOARDLAYOUT을 확인하고 ImmGetIMEFileName()을 사용하여 키보드 레이아웃이 IME에 의해 뒷받침되는지 여부를 확인합니다.하지만 실제로이 경우 입력 자체를 처리할지 여부는 알 수 없습니다.

내 최소 버전은 현재 윈도우 7

감사합니다.

업데이트이 질문의 원본 버전은 관련 WM_KEYUP; 다른 플랫폼에서 내 동등한 코드를 통해 두 번째로 살펴본 결과, 결국 TranslateMessage()의 세부 사항을 제외하고는 필요하지 않습니다. 그에 따라 질문을 조정했습니다. (OS X에서는 텍스트 입력 시스템에 키 릴리스 이벤트조차하지 않고 GTK +에서는 키보드를 삽입하면 문자가 삽입되지 않는 것이므로 어쨌든 처리되지 않습니다. 내가 시도한 입력 방법 (거기에는 몇 가지가있을 수있다 ...).) 내가 말하지 않았 으면, 나는 또 다른 하위 질문을 추가했다.

Answer 1

일반적으로 Windows 내부를 복제하려고하지 않는 것이 좋습니다. 지루하고 오류가 발생하기 쉽고 사전 통보없이 변경 될 가능성이 있습니다.

WM_KEYDOWN 핸들러에서 화살표 키 (및 다른 특정 키)를 선택하고 다른 모든 것을 기본 핸들러로 전달하여 (결국) WM_CHAR 또는 TSF 입력 호출을 생성하는 소스 액세스 권한을 가진 편집 컨트롤 (if 귀하의 통제가 TSF를 지원합니다).

관련된 TSF 처리기가없는 경우에도 여전히 WM_CHAR이 필요합니다. 그러나 항상 WM_CHAR 처리기에서 ITextStoreACP :: InsertTextAtSelection 메서드를 호출하도록 할 수 있습니다.