Notes on Programming with Microsoft Foundation Classes (MFC)

See also:

• Programming Tools

Introduction

Notes on MFC

• 2009-Oct-09: DLL Hell returns with Visual Studio 2005 and side by side assemblies. [8605]
• 2008-Apr-29: When sub-classing an MFC CComboBox one can run into some difficulties, this is because the CComboBox is actually comprised of two controls in one package and Microsoft did not try very hard to make the result behave like a single control. For example, trying to use OnChar() to look at the keys the user is pressing will not work as noted here. Microsoft's approach to solving this problem is quite bizarre, most people appear to be using PreTranslateMessage() to do this, for example look at this code that adds auto-completion to the control. [6000]
• 2008-Apr-23: How to avoid the use of GetDlgItem() in your MFC code by calling DDX_Control(). [5955]
• 2008-Apr-08: A note on how the CDocument::DoSave() function set works. [5748]
• 2008-Mar-14: Saving and restoring the window size and position of the CMainFrame in an MFC application to the registry is explained here. An older approach is here. [5281]
• 2008-Mar-13: A discussion of how to update the state of controls within MFC programs, including enabling and disabling menu items, by using the ON_UPDATE_COMMAND_UI messages. [5265]
• 2008-Mar-10: Understanding MFC's CCtrlView which is used in the CTreeView and other MFC classes. [5249]
• 2008-Mar-06: Creating icons for Windows programs from within Visual Studio. [5235]
• 2008-Mar-03: An example of an owner-drawn list control in MFC. [5211]
• 2008-Mar-03: So you're happily coding away on some dialogs and have some special need to use SetFocus() and TABSTOP to get the tab key sequencing through the controls in exactly the right fashion. But sometimes you notice that the focus rectangle is not getting drawn on the control that has the keyboard focus and you think this is a problem in your code and you start to tear out the few remaining hairs on your head.

  If you are using Windows XP or Vista this might not be a problem with your code, it appears that some UI designer (who's brain was obviously too big and has a full head of hair) at Microsoft decided that the keyboard focus indicator was too distracting and ordered it turned off by default. But to make life more confusing the focus box will get drawn when signs of keyboard activity are sensed (such as when you press an ALT key or perhaps the left or right arrow keys - but NOT the TAB key). Then, just to make matters even worse, the Vista team rearranged the way this option is hidden in the Windows preferences system, so even if you found the instructions on how to re-enable this behavior under XP you'll never find the control for it under Vista - this article has a good guide to where to find the setting under both Vista and XP. In short for Vista you need to:

  1. right click on the desktop,
  2. select the "Personalize" menu item,
  3. then click on the "Ease of access" link,
  4. then click on "Make keyboard easier to use",
  5. then check the "Underline keyboard shortcuts and access keys" option
  6. and (finally!) hit the "Save" button.
  for Windows XP you need to:
  1. right click on the desktop,
  2. select the "Properties" menu item,
  3. then click on the "Appearance" tab,
  4. then click on "Effects..." button,
  5. remove the check from the "Hide underlined letters for keyboard navigation until I press the Alt key" option
  6. and (finally!) hit the "OK" button.
  [5210]
• 2008-Mar-01: Trapping ENTER in a dialog and rebinding it to tab to the next control gets discussed in this DJJ article [5193]
• 2008-Mar-01: For an in-depth write up on messaging in MFC and things like PreTranslateMessage see: this article. Some of the additional related articles are worth a read too. [5192]
• 2008-Mar-01: Creating a CListBox with user-editable contents: CEditableListBox and Listbox Tutorial. [5191]
• 2008-Mar-01: The CWnd class has the necessary functions for traversal of the child/parent/sibling window lists (and since CDialog inherits from CWnd it has all these too). Traversal in TAB key order (within dialogs) gets more complex because there are sub windows that do not have TABSTOP set on them, so they get skipped. Plus the tabbing logic knows to skip any windows that are disabled. The tab logic will always descend into dialog windows that have the WS_EX_CONTROLPARENT set (this might happen even if there are no windows in them that have tabstop set, which can make for a tab traversal that seems to stop and catch the tab).

  Getting out of a sub dialog, by hitting the tab can be done by trapping the tab key and putting in some code to manually move the focus out of the dialog to another window. If you really want this behavior the best thing to do would be to override CDialog::PreTranslateMsg() to handle the tab key and then use that version of CDialog as your base class for dialogs.

  Using the Spy++ tool can help understand the window tabbing order because the tabbing order is the order that windows appear in its view (i.e. the order they are constructed and chained together).

  The win32 function ::GetWindow(HWND, UINT) can be used to find the first child window of a given window when UINT == GW_CHILD. It can also be used to find the first (among several) sibling windows when UINT == GW_HWNDFIRST. There is a CWnd::GetWindow() equivalent function. [5190]

• 2008-Mar-01: Setting focus to controls in a dialog can be troublesome see:
  • The Old New Thing
  • Microsoft
  • ClubFarPoint
  [5189]
• 2008-Mar-01: WTL (home page) might be an alternative to MFC. [5188]
• 2008-Mar-01: Buddy buttons, a small button or control that gets embedded within the space of an edit control. [5187]
• 2008-Mar-01: Discussion of the enter key and how to override its default functionality (of OK-ing the dialog) as well this mentions that the tab key order is the same as z-order for a dialog and has discussion of PreTranslateMessage() which can be used to implement accelerator keys in a dialog. [5186]