Knowledge Base

BUG: EM_LIMITTEXT Causes GPF in Japanese and Chinese Windows

Article ID: 126820

Article Last Modified on 7/11/2005


APPLIES TO


This article was previously published under Q126820

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 KB126820