BUG: EM_LIMITTEXT Causes GPF in Japanese and Chinese Windows

ID: 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
Version : :3.1
Platform :
Issue type :