Visual C++视频_音频开发实用工程案例精选

This is a part of the Microsoft Foundation Classes C++ library. Copyright (C) 1994-1998 Microsoft Corporation All rights reserved. This source code is only intended as a supplement to the Microsoft Foundation Classes Reference and related electronic documentation provided with the library. See these sources for detailed information regarding the Microsoft Foundation Classes product. ------------------------------------------------------- MTMDI Sample Microsoft Foundation Classes Application ------------------------------------------------------- The MTMDI sample illustrates an MFC user-interface thread, where user interface events are processed in a thread separate from the main application thread. This sample is a modified version of the single thread MDI sample. The MTMDI sample does not claim a strong rationale for putting the bouncing ball window in a separate thread. An end-user would not be able to detect the difference between the MDI and MTMDI samples on a single processor machine. Even on a multi-processor machine, the end-user would not be able to detect the difference given that the ball movement is based on a window timer. Further, the MTMDI sample does not claim a strong rationale for using an MFC worker thread instead of an MFC user-interface thread. MFC worker threads generally are easier to use and more appropriate than user-interface threads for tasks that do not involve processing of user interface events. The drawing of the bouncing ball could have been implemented in a worker thread instead of a user-interface thread, if some technique other than window timers were used to advance the ball. The use of the window timer in a separate thread requires a message pump; therefore the separate thread must be a user-interface thread instead of a worker thread. To add slightly more justification for using a user-interface thread, the MTMDI sample includes one additional user-interface feature not in the MDI sample: you can click anywhere in the bounce window to immediately change the position of the moving ball. Although the MDI sample does not claim a strong rationale for using threads, it nevertheless does illustrate techniques for implementing an MFC user-interface thread. The remainder of this readme describes the differences between the implementation of the single thread MDI application and the multiple thread MTMDI application. These differences illustrate that it is more difficult to implement an application with a user-interface thread than a corresponding application that executes in a single thread. This should be a warning that you should not use user-interface threads unless you have good reasons. The overall differences between the implementation of the MDI and MTMDI samples are these: 1. The CBounceWnd window runs in a separate user-interface thread in the MTMDI application. 2. In the MDI sample, CBounceWnd is derived from CMDIChildWnd. In the MTMDI sample, CBounceWnd is derived from CWnd, and a CBounceWnd window is a child of the MDI child window. In the MTMDI sample, the CBounceWnd child window fills exactly the client area of the parent MDI child window (a CMDIChildBounceWnd). 3. In the MDI sample, normal MFC command routing and command user- interface initialization are used for menu commands associated with the bounce window. In the MTMDI sample, the MDI child window's OnCmdMsg function is overridden in order to send the OnCmdMsg parameters via SendMessage to the CBounceWnd executing in the separate thread. In general, SendMessage typically needs to be used us to make calls from a window in one thread to a window in another thread in an MFC application. Note: The Hello window is left in the main application thread. Implementing the Bounce window in a separate thread is sufficient to illustrate the MFC multithread techniques. This MTMDI sample does not directly illustrate a view running in a separate thread, because MTMDI and the original MDI sample do not use MFC's document/view architecture. Still, the design of MTMDI can be applied to an application where you might want the view to run in a separate thread. In general, you cannot successfully implement member functions of a CView to run in a separate thread, because the MFC document/view architecture relies on thread local storage (TLC) for some of the data that coordinates documents and views. However, you can apply the design of MTMDI by implementing a child window of the CView window, and processing user- interface events of this child window in a separate thread. The design of MTMDI is summarized below. For additional details, see source code comments. ================= CWinThread object ================= The thread object for the bouncing ball window is implemented in a CWinThread-derived class, CBounceThread, in mtbounce.cpp. Beginning the user-interface thread ----------------------------------- The overridden CMDIChildBounceWnd::OnCreate begins the thread for the bouncing ball. There are two ways to begin an MFC user-interface thread: (1) call AfxBeginThread, passing the CRuntimeClass of the CWinThread-derived class; or (2) implement two-stage construction of the CWinThread-derived object by new'ing it and then calling CWinThread::CreateThread. We use the second method because it offers the easiest way to pass the HWND of the CMainFrame window to the thread, which needs the parent HWND to create the child window. We simply pass the HWND to the CBounceThread constructor. An alternative method is: - call AfxBeginThread with a CREATE_SUSPENDED parameter; - pass the parent HWND via a new CBounceThread::SetParentWnd function; or make the CBounceThread::m_hwndParent member variable public and set it directly; and then - call CWinThread::ResumeThread. Thread instance initialization ------------------------------ CWinThread::InitInstance is the only member function that must be overridden for a user-interface thread. The implementation of CBounceThread::InitInstance is typical in that it creates (using CWnd::Create) the window that processes messages in the separate thread. Terminating the user-interface thread ------------------------------------- The easiest way to terminate a user-interface thread is to rely on automatic termination of the thread when the main window associated with the thread is destroyed. The only thing you need to do to implement such automatic thread termination is to set the CWinThread::m_pMainWnd to the main window. This is illustrated in CBounceThread::InitInstance. The default CWnd::OnNcDestroy handler checks whether the window being destroyed is the thread's m_pMainWnd and, if so, terminates the thread, provided it isn't the main application thread. Unless you change the default TRUE value of CWinThread::m_bAutoDelete, the framework will automatically delete the CWinThread object when the thread terminates. Avoiding memory leak detection of CWinThread object --------------------------------------------------- When the application terminates, it destroys each window in the window hierarchy, and then, in debug mode, checks for memory leaks. It is possible that the application will falsely detect a memory leak of the CWinThread object before the user-interface thread has had a chance to automatically terminate. The reported memory leak is false because eventually the CWinThread object will be automatically destroyed anyway. Nevertheless, the dumping of memory leak information can be disconcerting. To avoid this, we use a "bounce thread killed" event. The CBounceThread delete operator sets the event. The main application waits for this event before terminating. It is better to set the event in the delete operator rather than in the CBounceThread destructor, because it is remotely possible that the applicati