The information in this article applies to:
SUMMARY
Windows-based applications often display data-entry dialog boxes to request
information from users. These dialog boxes may contain several edit
controls and two command (push) buttons, labeled OK and CANCEL. An example
of a data-entry dialog box is one that requests personal information, such
as social security number, address, identification (ID) number, date/time,
and so on, from users. Each of these items is entered into an edit control.
MORE INFORMATIONMethod I: (WM_COMMAND)This method is based on the following behavior of dialog boxes (Dialog Manager) and focus handling in Windows.If a dialog box or one of its controls currently has the input focus, then pressing the ENTER key causes Windows to send a WM_COMMAND message with the idItem (wParam) parameter set to the ID of the default command button. If the dialog box does not have a default command button, then the idItem parameter is set to IDOK by default. When an application receives the WM_COMMAND message with idItem set to the ID of the default command button, the focus remains with the control that had the focus before the ENTER key was pressed. Calling GetFocus() at this point returns the handle of the control that had the focus before the ENTER key was pressed. The application can check this control handle and determine whether it belongs to any of the edit controls in the dialog box. If it does, then the user was entering data into one of the edit controls and after doing so, pressed ENTER. At this point, the application can send the WM_NEXTDLGCTL message to the dialog box to move the focus to the next control. However, if the focus was with one of the command buttons (CANCEL or OK), then GetFocus() returns a button control handle, at which point one can dismiss the dialog box. The pseudo code for this logic resembles the following in the application's dialog box procedure:
Method IIThis method involves subclassing/superclassing the edit control in the dialog box. Once the edit controls are subclassed or superclassed, all keyboard input is sent the subclass/superclass procedure of the edit control that currently has input focus, regardless of whether or not the dialog box has a default command button. The application can trap the key down (or char) messages, look for the ENTER key, and do the processing accordingly. The following is a sample subclass procedure that looks for the ENTER key:
Method 3This method involves using App Studio and ClassWizard and creating a new dialog box member function.This method will allow a user to press the ENTER key and have the focus advance to the next edit control. If the focus is currently on the last edit control in the dialog box, the focus will advance to the first edit control. First, use App Studio to change the ID of the OK button of the dialog box. The default behavior of App Studio is to give the OK button the ID IDOK. The OK button's ID should be changed to another value, such as IDC_OK. Also, change the properties of the OK button so that it is not a default pushbutton. Next, use ClassWizard to create a new dialog box member funciton. Name the new member function something like OnClickedOK. This function should be tied to the BN_CLICKED message from the IDC_OK control. Once this is done, write the body of the OnClickedOK function. You should put the code that you would normally put in the OnOK function into the new OnClickedOK function, including a class's OnOK function. Add the following prototype to the header file for the dialog box:
Add an OnOK function to the dialog box and code is as demonstrated below:
Additional query words: push RETURN keydown
Keywords : kbCtrl kbDlg kbEditCtrl kbNTOS kbWinOS2000 kbSDKWin32 kbGrpUser kbWinOS |
Last Reviewed: February 3, 2000 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |