SAMPLE: Implementing a Read-Only Edit Control In Windows

Last reviewed: February 15, 1996
Article ID: Q80946
The information in this article applies to:
  • Microsoft Windows Software Development Kit (SDK) for Windows versions 3.0 and 3.1

SUMMARY

In some situations, an application may contain text that is displayed for the user to read, which is undesirable for the user to modify. The application can use a static control to contain this text if the message is short. However, for larger amounts of text, which require scrolling to display all the text in the allotted area, something closer to an edit control is required. This article, and its associated sample code, details how to make an edit control "read- only."

ROEDIT is a file in the Microsoft Software Library that demonstrates the techniques discussed in this article.

Download ROEDIT.EXE, a self-extracting file, from the Microsoft Software Library (MSL) on the following services:

  • Microsoft Download Service (MSDL)

          Dial (206) 936-6735 to connect to MSDL
          Download ROEDIT.EXE (size: 23594 bytes) 
    
  • Internet (anonymous FTP)

          ftp ftp.microsoft.com
          Change to the \SOFTLIB\MSLFILES directory
          Get ROEDIT.EXE (size: 23594 bytes) 
    

MORE INFORMATION

An application can create a read-only edit control by subclassing or superclassing a standard edit control. The subclass procedure filters out messages that change the contents of the edit control. The following code fragment demonstrates this process:

   FARPROC gOldProc;

   LONG FAR PASCAL ROEditProc(HWND hWnd, WORD msg,
                              WORD wParam, LONG lParam)
   {
       switch (msg)
       {
           case WM_KEYUP:
           case WM_KEYDOWN:
           case WM_CHAR:
           case WM_CUT:
           case WM_COPY:
           case WM_PASTE:
           case WM_LBUTTONUP:
           case WM_LBUTTONDOWN:
           case WM_LBUTTONDBLCLK:
               return 1L;

           case WM_GETDLGCODE:
               return 0L;
       }

       return CallWindowProc(gOldProc, hWnd, msg, wParam, lParam);
   } //*** ROEditProc

In the example above, the subclass procedure traps mouse clicks, keystrokes, and the cut, copy, and paste commands. It also traps the WM_GETDLGCODE message to prevent an edit control in a dialog box from receiving the input focus.

The following example demonstrates superclassing an edit control to create a new ROEDIT-class control that behaves similar to a read-only edit control. A ROEDIT control implements the window procedure provided above. It also changes the cursor to an arrow instead of an I-beam, which provides an additional indication to the user that the contents of the control cannot be changed. Using an ROEDIT control eliminates the necessity of subclassing each control after it is created. When the application creates a control from the ROEDIT class, the read-only behavior is provided automatically.

The following code demonstrates superclassing an edit control as described above:

   FARPROC gOldProc;

   BOOL RegisterROEdit(HANDLE hInstance)
   {
       WNDCLASS wc;

       if (!GetClassInfo(NULL, "EDIT", &wc))
           return FALSE;

       gOldProc = (FARPROC)wc.lpfnWndProc;

       wc.style        &= ~CS_GLOBALCLASS;
       wc.lpfnWndProc   = ROEditProc;
       wc.hInstance     = hInstance;
       wc.hCursor       = LoadCursor(NULL, IDC_ARROW);
       wc.lpszClassName = "ROEDIT";

       return RegisterClass(&wc);

   } //*** RegisterROEdit

In Windows 3.1, there is a new style bit for the edit control (ES_READONLY) that removes the editing capabilities of the edit control, leaving only the viewing capabilities. This style is useful when the application shows the user a body of static text that the user reads and does not modify.


Additional reference words: 3.00 3.10 softlib ROEDIT.EXE
KBCategory: kbprg kbfile
KBSubcategory: UsrCtl


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: February 15, 1996
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.