BUG: EM_LIMITTEXT Causes GPF in Japanese and Chinese WindowsLast reviewed: January 15, 1998Article ID: Q126820 |
3.1
WINDOWS
kbbuglist
The information in this article applies to:
SYMPTOMSUnder the Japanese and Traditional Chinese versions of Windows version 3.1, if an edit control has style ES_AUTOHSCROLL, and EM_LIMITTEXT is sent to the edit control to limit the number of bytes the user can input to the edit control, a general protection fault (GPF) will occur when the user is entering a double-byte character for the last byte. For example, if the following function is used to limit the number of bytes a user can input to 7:
SendMessage (hWnd, EM_LIMITEXT, 7, NULL);The user enters "ABCDEF"( all single-byte character) to the edit control, then try to enter a double-byte 'G' to the edit control, a GPF will occur. Also, a GPF will also occur under the Japanese version of Windows version 3.1, if EM_LIMITTEXT is used and the edit control has style ES_UPPERCASE and the edit control is using the MS MINCHO or MS GOTHIC font. Hangeul (Korean) Windows version 3.1 does not GPF if EM_LIMITTEXT is used along with the ES_UPPERCASE style and the MS MINCHO or MS GOTHIC font.
RESOLUTIONSubclass the edit control, and check the WM_CHAR message coming in. If the WM_CHAR message for the last byte is a DBCS leadbyte, discard the WM_CHAR message along with the next WM_CHAR message. The following code demonstrates this workaround: LONG FAR PASCAL SubClassFunc(HWND hWnd, WORD Message, WORD wParam, LONG lParam) {static BOOL bInvalidchar=FALSE; // Is this the last byte? if ( Message == WM_CHAR ) { if (bInvalidchar==TRUE) //The trailing byte of a DBCS character { //that comes in for the last byte in edit. bInvalidchar=FALSE; //Reset the flag. Next char is valid. return 0; //Throw away the trailing byte. } else { // Is this the last byte? Is the incoming WM_CHAR a DBCS // leadbyte? if ( IsDBCSLeadByte(LOBYTE(wParam)) && (( TEXTLIMIT - SendMessage(hWnd, WM_GETTEXTLENGTH, 0,0)) == 1)) { bInvalidchar=TRUE; //The character is invalid. return 0; // Throw away this byte. } else return CallWindowProc(lpfnOldWndProc, hWnd, Message, wParam, lParam); } } else return CallWindowProc(lpfnOldWndProc, hWnd, Message, wParam, lParam); } STATUSMicrosoft has confirmed this to be a problem in the product(s) listed at the beginning of this article. This problem does not occur in Chinese or Japenese Windows 95 or Windows NT.
|
Additional reference words: cwin jwin fesdk
© 1998 Microsoft Corporation. All rights reserved. Terms of Use. |