2012-01-27 4 views
4

오늘 인수가 없는데도 GetWindowLong (및 GetWindowLongPtr)에 'ANSI'(A) 및 '유니 코드'(W)가 있음을 알게되었습니다. MSDN page on GetWindowLong은 이러한 변형이 존재 함을 나타내지 만 그 이유는 언급하지 않습니다.GetWindowLong에 ANSI 및 유니 코드 변형이있는 이유는 무엇입니까?

CreateWindowEx (A/W 맛이 있음) 또는 RegisterClass의 인코딩과 일치해야한다고 생각할 수 있습니다. 그러나 여러 가지 이유로 이것이 의미가 있다고 생각하지 않습니다. 외관상으로는, someone reported that the Unicode version may fail on XP (비록 XP가 NT이고, 내가 이해할 수 있듯이 모든 유니 코드가 후드 임에도 불구하고). 나는 또한 (모두 GetWindowLong의 맛을 포함하고 있음)의 32 비트 버전을 해체하려고 시도했으며 일부 명백한 인코딩 차이 *에 따라 추가 작업이 이루어졌습니다.

내가 선택한 기능은 무엇입니까?


*이 GetWindowLong의 맛은 다른 함수로 전달 주위 부울 제외한 동일하다. 이 부울은 메모리 구조의 플래그 비트와 비교됩니다. 정적 코드 분석을 사용하여 추적 할 수는 없습니다.

+1

바보 같은 질문 - 왜 2012 년에 ANSI 버전에 신경을 썼겠습니까? –

+0

중요한 두 가지 시나리오를 상상할 수 있습니다. 하나는 제 3자가 제공 한 창 클래스를 사용하는 곳이며, ANSI 클래스로 등록합니다. 뒤에서 발생하는 'A <-> W'변환은 성능상의 불이익을 초래할 수 있습니다. 다른 하나는 ANSI를 사용하는 곳입니다. 왜냐하면 단순히 i18n에 관심이 없기 때문입니다 (예 : 게임을 작성 중이며 어쨌든 창이 전체 화면을 차지하고 있음). –

+0

필자는 .. 어쨌든 함수는 내부적으로 (ANSI 응용 프로그램의 경우) 변환을 수행합니다. 또한 UI 코드의 문자열 변환 성능은 거의 문제가되지 않습니다. –

답변

7

나는 현재 창 절차는 당신이 그것을 호출 할 수 있기 때문에 다음 실제 함수 포인터가 반환 할 수 없습니다 GetWindowLongPtr의 발신자와 호환되지 않는 경우 What are these strange values returned from GWLP_WNDPROC?

, 이유는 레이몬드 첸의 문서에서 설명 믿는다 . 대신 "마법 쿠키"가 반환됩니다. 이 쿠키의 유일한 목적은 CallWindowProc에 의해 인식되어 메시지 매개 변수를 윈도우 프로 시저가 예상하는 형식으로 변환 할 수 있습니다.

예를 들어 Windows XP를 실행 중이고 창은 UNICODE 창이지만 ANSI로 컴파일 된 구성 요소는 GetWindowLong (hwnd, GWL_WNDPROC)을 호출한다고 가정합니다. 호출자가 ANSI 창 메시지를 사용하고 있지만 창 프로 시저가 UNICODE 창 메시지를 필요로하기 때문에 원시 창 프로 시저를 반환 할 수 없습니다. 대신에 마술 쿠키가 반환됩니다. 이 마법 쿠키를 CallWindowProc에 전달하면 "아, ANSI에서 UNICODE로 메시지를 변환 한 다음 UNICODE 메시지를 해당 창 프로 시저에 전달해야합니다."라고 인식합니다.

+0

그러면 UNICODE 창은 무엇입니까? 'RegisterClassW' 또는'CreateWindowExW'? –

+2

['RegisterClassEx'] (http://msdn.microsoft.com/en-us/library/windows/desktop/ms633587.aspx)는 다음과 같이 결정합니다. "RegisterClassExA를 사용하여 창 클래스를 등록하면 응용 프로그램이 시스템에 알립니다 생성 된 클래스의 창은 ANSI 문자 집합을 사용하는 텍스트 또는 문자 매개 변수가있는 메시지를 필요로하며 RegisterClassExW를 사용하여 등록하면 응용 프로그램이 시스템의 텍스트 매개 변수를 유니 코드 형식으로 전달하도록 요청합니다. " –

관련 문제