BUG: EM_LIMITTEXT Causes GPF in Japanese and Chinese Windows

Last reviewed: January 15, 1998
Article ID: Q126820
3.1 WINDOWS kbbuglist

The information in this article applies to:

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

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 reference words: cwin jwin fesdk
KBCategory: kbbuglist kbprg
KBSubcategory: KBIntlDev
Keywords : kb16bitonly


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: January 15, 1998
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.