How Can I Trap the Enter Key to Control the Cursor on a Dialog?

The Tab key and the mouse are the default controls for navigating through text-input fields, but for some data entry tasks, the Enter key makes more sense


September 17, 2002
URL:http://www.drdobbs.com/windows/how-can-i-trap-the-enter-key-to-control/184416769

Some years ago, I was at a conference where Microsoft was talking about the latest version of MFC and how to apply it to different user interface design models. The speaker mentioned two major models—document/view and forms. With possibly the exception of Access, all of Microsoft’s productivity applications such as Excel, Word, and so on are document/view applications. The user works within a document that may have some structure (like a spreadsheet) but is usually free to enter data in whatever manner they see fit. There are also often multiple presentations of the same data available like a graph of spreadsheet data. The speaker later mentioned that sometime in the future Microsoft would develop the forms model alongside the doc/view model. Sadly this never really occurred. Although Microsoft did develop at least one notable form-style application (Microsoft Money) they never really provided much support in the MFC framework (or even in the SDK) to make form applications easy to develop.

If you have ever watched a data entry clerk enter data into an application, it’s amazing how fast some of them can read a paper form, key in the data, and move to the next entry. To make their lives as easy (and productive) as possible, the software application needs to accommodate natural keyboard motions. Unfortunately, using the Tab key to move from one control to another (or worse, using the mouse) does not lend itself to fast data entry. At some point in the distant past, Microsoft decided that the Enter key would be tied to the default command button (i.e., the OK button) on a dialog (unless overridden by the developer). For some dialogs, like property sheets, this may be okay because you don’t typically key data into every field and thus need a mode of entry that is very efficient; using the mouse or tab key in this situation is just fine.

Ironically, in the MS-DOS world that preceded Windows on the PC, use of the Enter key to move around a form input model was very typical. Most form based “frameworks” available at the time provided this capability out-of-the-box. It was only when Windows 3.0 arrived that form developers first faced the loss of this feature. My own experience with this issue occurred when a company I worked for moved an application from MS-DOS to Windows. During the rewrite, we attempted to follow the Microsoft Windows dictums as closely as possible to ensure we had a “compliant” application (see the 8/7/02 Windows Q&A Newsletter on UI standardization). After initial user testing showed that the Windows application was significantly more difficult for a data entry clerk to work with, we went back to the drawing board and incorporated many form-based mechanisms into the application. One such mechanism was forcing the Enter key to work like the Tab key on a dialog (or other form class like CFormView).

By default, the Enter key is handled by the dialog manager of each dialog window. It’s meaning is assumed to be the following:

  1. Determine the ID of the default command button on the dialog (or form).
    Typically this is IDOK (1).
  2. Send a WM_COMMAND message to the parent of the command button with the ID of the command button.
  3. If ID = 1 (the default), dialog manager calls EndDialog(), which closes the dialog.

There are a couple of options here to override this behavior. One of the simplest (in MFC) is to override CWnd::OnCommand(WPARAM,LPARAM) for the parent dialog or form. Here is some code to illustrate:

	BOOL CMyCoolDialog::OnCommand(WPARAM wp,LPARAM lp)
	{
		int defBtnId = <some value>
		if ( wp == IDOK || wp == defBtnId )
		{
			// user hit the Enter key. 
			// Move to next ctl in the tab order..
			::PostMessage( m_hWnd,WM_NEXTDLGCTL,0,0 );
			return TRUE;
		}
		else
			return CDialog::OnCommand(wp,lp);
	}

Pretty simple, eh? Notice the use of the message WM_NEXTDLGCTL to move focus to the next control in the tab order. You might be wondering why I use this somewhat obscure message rather than the more straightforward SetFocus(). The problem with moving focus to a control by using SetFocus() is that you can often get in the middle of the message flow that occurs when Windows tries to be helpful and move focus for you automatically. You may end up with odd behavior where focus moves initially to where you tell it to go, only to be moved somewhere else an instant later because there was another WM_SETFOCUS message somewhere in the window message queue. This can also occur when you try to override a WM_KILLFOCUS message and perform some field level validation and want to keep the user in the control until they fix the problem (but that's a topic for another day).

Another approach is to subclass each control on the dialog (or form). You would need to trap on the following messages: WM_GETDLGCODE (return DLGC_WANTALLKEYS), WM_CHAR, and WM_KEYDOWN. Then you could filter the Enter key directly and move it another control using WM_NEXTDLGCTL. This approach is preferred if you have a custom window that works similar to a traditional dialog, but is based on a different class. However it's a lot more work, particularly if you have many different kinds of controls on the dialog.

If you are using third-party controls, particularly grids or spreadsheets, look for a built-in property that provides Enter-As-Tab behavior. Many provide this capability since it is so commonly needed in a grid-style interface.

It would have been nice if the MFC team would have just created a property on the CDialog and CFormView classes named something like "UseEnterAsTab to automate this behavior for those working with form based input. But as you can see, doing it yourself is not too difficult, once you know the procedure.

Finally, a note of thanks to the readers who are sending in their questions. Feel free to pepper me with ones that are thorny or might be of interest to other readers. I will answer them in future newsletters for everyone's benefit.


Mark M. Baker is the Chief of Research & Development at BNA Software located in Washington, D.C. Send your Windows development questions to [email protected]. To subscribe, visit http://www.windevnet.com/newsletters/.

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.