Mouse move messages (nonclient and client)Created: April 15, 1992
ABSTRACT
This technical note describes the MFC debugging and trace options for Windows-based applications.
The Microsoft Foundation Class (MFC) library provides a full-featured set of C++ object classes for the MicrosoftÒ WindowsÔ graphical environment. It includes classes that directly support application development for Windows as well as general-purpose classes for collections, files, persistent storage, exceptions, diagnostics, memory management, strings, and time. Each MFC technical note describes a feature of MFC using code fragments and examples.
The TRACE mechanism helps debug programs for the MicrosoftÒ WindowsÔ graphical environment. Textual debugging output goes to the debug console (debug terminal or Microsoft CodeViewÒ for Windows command window). Debugging and trace options are enabled when you compile your program with the _DEBUG symbol defined.
You can set the options described in this technical note by using a debugger, in the initialization code of your application, or by using the AFX.INI file. A sample AFX.INI file is in the \C700\MFC\SRC subdirectory. This file turns on diagnostic messages and uses the standard options. You must place the file in your Windows directory.
By default, TRACE output is ignored. Setting the afxTraceEnabled global integer to TRUE routes TRACE output (and default afxDump output) to the debugger.
The afxTraceFlags global integer turns on the built-in reporting features of the MFC library.
The flags are stored in the afxTraceFlags global integer, which you can set under program control or with the debugger. This global integer uses each bit to select a trace reporting option.
You can turn any bit on or off. Experiment to get an idea of the report information they generate.
// Example under program control:
afxTraceFlags = 4 + 8; // windows message dumping
This functionality exists only in the debugging version of the library.
0x01: Multi-application debugging
This option prefixes each TRACE output with the name of the application. This affects the explicit TRACE output of your program as well as the additional report options described below.
0x02: Windows message report—in message pump
This option reports each message received in the main CWinApp message pump. It lists the window handle, the message name or number, and the wParam and lParam. The report is generated after GetMessage but before the message is translated or dispatched.
Dynamic data exchange (DDE) messages display additional data, which is good for some debugging scenarios in object linking and embedding (OLE). This option displays messages that are posted, not those that are sent.
0x04: Windows Message report—in WndProc
This option is similar to option 0x02 but applies to messages dispatched in the CWnd::WindowProc (that is, this option prints both posted and sent messages just before they are dispatched).
0x08: Command handling report
A special case for WM_COMMAND/OnCommand handling. This option reports the progress of the command routing mechanism. It reports which class receives the command (that is, when there is a matching message map entry) and when classes don’t receive a command (that is, when there is no matching message map entry). This is useful for MDI applications to see the flow of command messages (that is, where the child is given the opportunity to handle the message first, followed by the frame window).
0x10: Verbose OLE reporting
This option reports significant OLE notifications or requests. Turn this on for an OLE client or server to get an indication of the communication between the OLE dynamic link libraries (DLLs) and your OLE application.
For ease of reading, certain frequent messages are not reported, including:
Mouse move messages (nonclient and client)
WM_NCHITTEST
WM_SETCURSOR
WM_ENTERIDLE
WM_CTLCOLOR