1. Command Routing
(See above diagram) Suppose you add a menu item that will send the ID_MY_COMMAND command message to the MDI main frame of your application:
1. The command is first routed to the main frame, which will check the active child frame first.
2. The child frame will first check the active view, which checks its own message map before routing the command to the associated document.
3. The document will check its own message map before checking the message map of the associated document template.
4. Going back to the child frame's routing, the child frame will check its own message map.
5. Going back to the main frame's routing, the main frame will check its own message map.
6. Ultimately, the message map of the application object is checked, where an entry for your message is found and the appropriate handler is called.
If you find that you must use a different command routing scheme, perhaps to include your own special command target classes, you can do so by overriding the OnCmdMsg()member of CCmdTarget. This may involve overriding OnCmdMsg() for several classes and is beyond the scope of this book; for more information, see Command Routing in the MFC online documentation.
One of the most remarkable features of the document/view architecture is that an application can handle command messages almost anywhere. Command messages is MFC's term for the WM_COMMAND messages that are generated when items are selected from menus, keyboard accelerators are pressed, and toolbar buttons are clicked. The frame window is the physical recipient of most command messages, but command messages can be handled in the view class, the document class, or even the application class by simply including entries for the messages you want to handle in the class's message map. Command routing lets you put command handlers where it makes the most sense to put them rather than relegate them all to the frame window class. Update commands for menu items, toolbar buttons, and other user interface objects are also subject to command routing, so you can put ON_UPDATE_COMMAND_UI handlers in nonframe window classes as well.
CFrameWnd::OnCmdMsg first routes the message to the active view by calling the view's OnCmdMsg function. If pView->OnCmdMsg returns 0, indicating that the view didn't process the message (that is, that the view's message map doesn't contain an entry for this particular message), the frame window tries to handle the message itself by calling CWnd::OnCmdMsg. If that, too, fails, the frame window then tries the application object. Ultimately, if none of the objects processes the message, CFrameWnd::OnCmdMsg returns FALSE and the framework passes the message to ::DefWindowProc for default processing.
This explains how a command message received by a frame window gets routed to the active view and the application object, but what about the document object? When CFrameWnd::OnCmdMsg calls the active view's OnCmdMsg function, the view first tries to handle the message itself. If it doesn't have a handler for the message, the view calls the document's OnCmdMsg function. If the document can't handle the message, it passes it up the ladder to the document template. Figure 9-2 shows the path that a command message travels when it's delivered to an SDI frame window. The active view gets first crack at the message, followed by the document associated with that view, the document template, the frame window, and finally the application object. The routing stops if any object along the way processes the message, but it continues all the way up to ::DefWindowProc if none of the objects' message maps contains an entry for the message. Routing is much the same for command messages delivered to MDI frame windows, with the framework making sure that all the relevant objects, including the child window frame that surrounds the active MDI view, get the opportunity to weigh in.
The value of command routing becomes apparent when you look at how a typical document/view application handles commands from menus, accelerators, and toolbar buttons. By convention, the File-New, File-Open, and File-Exit commands are mapped to the application object, where CWinApp provides OnFileNew, OnFileOpen, and OnAppExit command handlers for them. File-Save and File-Save As are normally handled by the document object, which provides default command handlers named CDocument::OnFileSave and CDocument::OnFileSaveAs. Commands to show and hide toolbars and status bars are handled by the frame window using CFrameWnd member functions, and most other commands are handled by either the document or the view.
An important point to keep in mind as you consider where to put your message handlers is that only command messages and user interface updates are subject to routing. Standard Windows messages such as WM_CHAR, WM_LBUTTONDOWN, WM_CREATE, and WM_SIZE must be handled by the window that receives the message. Mouse and keyboard messages generally go to the view, and most other messages go to the frame window. Document objects and application objects never receive noncommand messages.
Links:
MFC Messages and Commands Routing -
http://www.informit.com/library/content.aspx?b=Visual_C_PlusPlus&seqNum=45
Modal Dialog Box Prevents Calls to PreTranslateMessage - http://support.microsoft.com/kb/126874
MFC Tech Notes - http://msdn.microsoft.com/en-us/library/azt48yaw(VS.71).aspx
MFC Command Routing - http://www.ezdoum.com/upload/MFCMessageRouting.pdf
2. MFC SubClassing
Subclassing is a standard technique in Windows programming for customizing the behavior of a window. MFC wrap subclassing into virtual function overriding.
Subclassing is a technique that allows an application to intercept and process messages sent or posted to a particular window before the window has a chance to process them. This is typically done by replacing the Window Procedure for a window with application-defined window procedure.
The term subclassing is different from the object-oriented subclass term and really means use this class to handle the Windows messages for this control. This subclassing normally is performed during the first pass of DoDataExchange() from inside a DDX_Control() routine. You must pass the control ID and a valid parent dialog box pointer to SubclassDlgItem().
To manually subclass the new custom edit box (m_ceditCustomEdit), for example, your OnInitDialog() function may look like this:
BOOL CCustomDlg::OnInitDialog(){ CDialog::OnInitDialog(); m_ceditCustomEdit.SubclassDlgItem(IDC_CUSTOM_EDIT,this); return TRUE;}WARNING
You must call SubclassDlgItem() only after your dialog box and control window have valid window handles. This means placing the subclass call after the call to the OnInitDialog() base class.
If the subclassing succeeds, SubclassDlgItem() returns TRUE. If you already know the HWND handle of the control, you can call SubclassWindow() from the dialog box instead, passing the control's window handle. SubclassWindow() also returns TRUE if the subclassing was successful.
You can add an override for the PreSubclassWindow() virtual function in your derived control class. Your PreSubclassWindow() override is called just before the control's messages are hooked into your derived class's message map. This lets you perform dynamic changes to the subclassing procedure or just some last-minute initialization of your new control-handler class.
You can call UnsubclassWindow() to make the control revert to using the original default (CWnd) handler object.
MFC ActiveX Controls: Subclassing a Windows Control :
This article describes the process for subclassing a common Windows control to create an ActiveX control. Subclassing an existing Windows control is a quick way to develop an ActiveX control. The new control will have the abilities of the subclassed Windows control, such as painting and responding to mouse clicks. The MFC ActiveX controls sample BUTTON is an example of subclassing a Windows control.
To subclass a Windows control, complete the following tasks:
1. Override the IsSubclassedControl and PreCreateWindow member functions of COleControl
2. Modify the OnDraw member function
3. Handle any ActiveX control messages (OCM) reflected to the control
Links:
http://www.informit.com/library/content.aspx?b=Visual_C_PlusPlus&seqNum=63
MFC & ActiveX Control - http://msdn.microsoft.com/en-us/library/9s2s80tk(VS.80).aspx
3. OnOpenDocument vs OnNewDocument
Generally speaking, MFC applications more commonly override OnNewDocument than OnOpenDocument. Why? Because OnOpenDocument indirectly calls the document's Serialize function, which initializes a document's persistent data members with values retrieved from a document file. Only nonpersistent data members—those that aren't initialized by Serialize—need to be initialized in OnOpenDocument. OnNewDocument, by contrast, performs no default initialization of the document's data members. If you add data members to a document class and want those data members reinitialized whenever a new document is created, you need to override OnNewDocument.
Before a new document is created or opened, the framework calls the document object's virtual DeleteContents function to delete the document's existing data. Therefore, an SDI application can override CDocument::DeleteContents and take the opportunity to free any resources allocated to the document and perform other necessary cleanup chores in preparation for reusing the document object. MDI applications generally follow this model also, although MDI document objects differ from SDI document objects in that they are individually created and destroyed as the user opens and closes documents.
4. SDI and MDI
MFC makes it easy to work with both single-document interface (SDI) and multiple-document interface (MDI) applications.
SDI applications allow only one open document frame window at a time. MDI applications allow multiple document frame windows to be open in the same instance of an application.
An MDI application has a window within which multiple MDI child windows, which are frame windows themselves, can be opened, each containing a separate document. In some applications, the child windows can be of different types, such as chart windows and spreadsheet windows. In that case, the menu bar can change as MDI child windows of different types are activated.
5. Device Contexts in MFC
Device contexts are Win32 objects; they are represented by HDC device-context handles. The MFC provides wrapper classes for the device-context object as the CDC base class, as well as a number of more specialized derived classes.
The basic CDC class is huge and supports all the GDI drawing functions, coordinate mapping functions, clipping functions, font-manipulation and rendering functions, printer-specific functions, path-tracking functions, and metafile-playing functions.
The CDC base class encapsulates all the device-context functionality and drawing functions that use a Win32 HDC object. The actual Win32 device-context handle is accessible via the public m_hDC member. You can retrieve this handle with the device context's GetSafeHdc() function.
You often will be handed a pointer to an initialized CDC object from MFC framework functions, such as CView::OnDraw() and CView::OnBeginPrinting(). These objects are nicely clipped to the dimensions of the window client area so that the results of drawing functions do not appear outside the area of the window.
You also can obtain a pointer to a CDC object for the client area of a window using the CWnd::GetDC() function. If you want a CDC pointer for the entire window area (including the title bar and borders), you can use the CWnd::GetWindowDC() function instead. You can even get a pointer to the entire Windows desktop by calling GetDesktopWindow()->GetWindowDC().
Links:
Windows GDI Tutorial - http://www.codeproject.com/KB/graphics/gditutorial.aspx
Inform IT Tutorial - http://www.informit.com/library/content.aspx?b=Visual_C_PlusPlus&seqNum=67
6. STA vs MTA
What is a multi-threaded apartment (MTA)? Single-threaded apartment (STA).
Anyway, apartments were introduced by Microsoft in NT 3.51 and late Windows 95 to isolate the problem of running legacy non-thread safe code into multithreaded environment. Each thread was "encapsulated" into so called single-threaded apartment. The reason to create an object in apartment is thread-safety. COM is responsible synchronize access to the object even if the object inside of the apartment is not thread-safe. Multithreaded apartments (MTA, or free threading apartment) were introduced in NT 4.0. Idea behind MTA is that COM is not responsible to synchronize object calls between threads.
In MTA the developer is responsible for that. See "Professional DCOM Programming" of Dr. Grimes et al. or "Essential COM" of Don Box for the further discussion on this topic.
Link : http://www.techinterviews.com/?p=103
7. MFC Msic
a. In a dialog based Application, we can use the following API to get handle to active Device Context.
CDC *pDC = GetDC();
b. We can use the following API to repaint a particular area(rectangle) on the screen
InvalidateRect()
c. MFC IPicture COM Interface can be used to load JPEG, GIF ( not PNG)
d. Image Processing Libraries like CxImage can be used to load JPEG, GIF & PNG
e. WM_TIMER(OnTimer) – MFC Timers can be used to get the Animation look if we have images(BITMAP,JPEG … ) ; Catch is to loadImages with an interval.
f. Loading JPEG and GIF pictures - http://www.arstdesign.com/articles/picloader.html
Add GIF-animation to your MFC and ATL projects with the help of CPictureEx and CPictureExWnd - http://www.codeproject.com/KB/graphics/pictureex.aspx
VC++ Setting WallPaper : http://www.codeproject.com/KB/applications/wallpaperq.aspx
