Microsoft KB Archive/126820

{|
 * width="100%"|

BUG: EM_LIMITTEXT Causes GPF in Japanese and Chinese Windows

 * }

Q126820

-

The information in this article applies to:


 * Microsoft Windows Software Development Kit (SDK) for Windows (Japanese and Traditional Chinese), version 3.1

-

SYMPTOMS
Under 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.

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

STATUS
Microsoft 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 query words: cwin jwin fesdk

Keywords : kb16bitonly

Issue type :

Technology : kbHLangJapanese kbHLangChineseTrad kbAudDeveloper kbWin3xSearch kbSDKSearch kbZNotKeyword3 kbWinSDKSearch kbWinSDK310