MFC的执行过程分析

MFC程序的执行细节剖析

MFC程序也是Windows程序,所以它应该也有一个WinMain。可是在程序中看不到它的踪影。事实上在程序进入点之前。另一个(并且仅有一个)全局对象(theApp)。这就是所谓的Application object,当操作系统将程序载入并激活时,这个全局对象获得配置,其构造函数会先运行。比WinMain更早。

一 CWinApp代替WinMain

CWinApp的派生对象被称为application object,能够想见,CWinApp本身就代表一个程序本体。所谓程序本体是与程序本身有关而不与窗体有关的数据或动作。CWinApp类定义例如以下:

class CWinApp :
public CWinThread

{

//startup args

HINSTANCE m_hInstance;

HINSTANCE m_hPrevInstance;

LPTSTR m_lpCmdLine;

int m_nCmdShow;

//Runing args

CWnd* m_pMainWnd;

CWnd* m_pActiveWnd;

LPCTSTR m_pszAppName;

LPCTSTR m_pszRegistryKey;

public:

LPCTSTR m_pszExeName;       //executable name

LPCTSTR m_pszHelpFilePath;  //default based on module path

LPCTSTR m_pszProfileName;   //default based on app name

public:

virtual BOOL InitApplication();

//overrides for implementation

virtual BOOL InitInstance();

virtual
int ExitInstance();

virtual
int Run();

virtual BOOL OnIdle(LONG lCount);

};

传统意义上SDK程序的WinMain所完毕的工作如今由CWinApp的三个函数完毕:

virtual BOOL InitApplication();

virtual BOOL InitInstance();

virtual int Run();

那么WndProc函数到哪里去了呢?CFrameWnd主要用来掌握一个窗体,你差点儿能够说它是用来代替SDK程序中的窗体函数的地位。

MFC通过内建了一个所谓的Message Map机制,会把消息自己主动送到“与消息相应的特定函数”中去。

有关Message Map实现机制请看另外一篇博客。

二 程序执行过程分析

如图所看到的,左半边MFC程序代码。右半部是我们自己写的程序代码。

当程序開始运行时,theApp这个全局对象产生,于是构造函数运行起来。CWinApp的构造函数例如以下

CWinApp::CWinApp(LPCSTR lpszAppName)

{

m_pszAppName = lpszAppName;

//initialize CWinThread state

AFX_MODULE_THREAD_STATE* pThreadState = AfxGetModuleThreadState();

pThreadState->m_pCurrentWinThread =
this;

m_hThread = ::GetCurrentThread();

m_nThreadID = ::GetCurrentThreadId();

//initialize CWinApp state

AFX_MODULE_STATE* pModuleState = AfxGetModuleState();

pModuleState->m_pCurrentWinApp = this;

//in non-running state until WinMain

m_hInstance = NULL;

m_pszHelpFilePath = NULL;

........

}

CWinApp之中的成员变量将由于theApp这个全局对象的诞生而获得配置与初值。theApp配置完毕后,WinMain登场。我们并未编写WinMain程序代码,这是MFC早就已经准备好并由链接器直接加到应用程序代码中:

extern “c” int WINAPI

_tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)

{

return AfxWinMain(hInstance, hPrevInstance, lpCmdLine, nCmdShow);

}

int AFXAPI AfxWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)

{

int nReturnCode = -1;

CWinApp* pApp = AfxGetApp();

AfxWinInit(hInstance, hPrevInstance, lpCmdLine, nCmdShow);

pApp->InitApplication();

pApp->InitInstance();

nReturnCode = pApp->Run;

AfxWinTerm();

return nReturnCode;

}

当中。AfxGetApp是一个全局函数,定义域AFXWIN1.INL中:

_AFXWIN_INLINE  CWinApp* AFXAPI AfxGetApp()

{ return afxCurrentWinApp; }

#define afxCurrentWinApp  AfxGetModuleState()->m_pCurrentWinApp

依据之前描写叙述的CWinApp::CWinApp()中的操作,能够知道AfxGetApp事实上就是取得CMyWinApp对象指针。所以,AfxWinMain中这种操作:

CWinApp* pApp = AfxGetApp();

pApp->InitApplication();

pApp->InitInstance();

nReturnCode = pApp->Run;

事实上就相当于调用:

CMyWinApp::InitApplication();

CMyWinApp::InitInstance();

CMyWinApp::Run();

因而导致调用:

CWinApp::InitApplication();

CMyWinApp::InitInstance();//改写了父类的该方法,调用子类的

CWinApp::Run();

AfxWinInit——AFX内部初始化操作

AfxWinInit是继CWinApp构造函数之后的第一个操作。下面是它的操作摘要

BOOL AFXAPI AfxWinInit(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPTSTR lpCmdLine, int nCmdShow)

{

ASSERT(hPrevInstance == NULL);

//set resource handles

AFX_MODULE_STATE* pState = AfxGetModuleState();

pState->m_hCurrentInstanceHandle = hInstance;

pState->m_hCurrentResourceHandle = hInstance;

//fill in the initial state for the application

CWinApp* pApp = AfxGetApp();

if(pApp != NULL)

{

//windows spcific initialization

pApp->m_hInstance = hInstance;

pApp->m_hPrevInstance = hPrevInstance;

pApp->m_lpCmdLine = lpCmdLine;

pApp->m_nCmdShow = nCmdShow;

pApp->SetCurrentHandles();

}

//initialize thread specific data

if(!afxContexIsDLL)

{

AfxInitThread();

}

return TURE;

}

CWinApp::InitApplication.

BOOL CWinApp::InitApplication()

{

if(CDocManager::pStaticDocManager != NULL)

{

if(m_pDocManager == NULL)

{

m_pDocManager = CDocManager::pStaticDocManager;

}

CDocManager::pStaticDocManager = NULL;

}

if(m_pDocManager != NULL)

{

m_pDocManager->AddDocTemplate(NULL);

}

else

{

CDocManager::bStaticInit = FALSE;

}

return TRUE;

}

这些都是MFC为了内部管理而做的。

CMyWinApp::InitInstance

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" >

继InitApplication之后。调用InitInstance即调用CMyWinApp::InitInstance();

也就是调用我们重写后的InitInstance函数。

CFrameWnd::Create产生主窗体(并先注冊窗体类)

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" >

CMyWinApp::InitInstance一開始new了一个CMyFrameWnd对象,准备用作主框窗体的c++对象。

会调用CMyFrameWnd类的构造函数,从而调用Create函数它将产生一个窗体。在调用Create函数的过程中Create会调用CreateEx,CreateEx函数实现例如以下:

BOOL CWnd::CreateEx(DWORD dwExstyle, LPCTSTR lpszClassName,

LPCTSTR lpszWindowName, DWORD dwStyle,

int x,
int y, int nWidth,
int nHeight,

HWND hWndParent, HMENU nIDorHMenu, LPVOID lpParam)

{

//allow modification of several         common create parameters

CREATESTRUCT cs;

cs.dwExstyle = dwExStyle;

cs.lpszClass = lpszClassName;

cs.lpszName = lpszWindowName;

cs.style = dwStyle;

cs.x = x;

cs.y = y;

cs.cx = nWidth;

cs.cy = nHeight;

cs.hwndParent = hWndParent;

cs.hMenu = nIDorHMenu;

cs.hInstance = AfxGetInstanceHandle();

cs.lpCreateParams = lpParam;

PreCreateWindow(cs);

AfxHookWindowCreate(this);

HWND hWnd = ::CreateWindow(.....);

........

}

到这里可能熟悉SDK编程的都会问那么窗体类呢,事实上窗体类在Create函数调用时窗体类參数传的NULL代表将以MFC内建的窗体类产生一个标准的外框窗体。

窗体显示与更新

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" >

CMyFrameWnd::CMyFrameWnd结束后。窗体已经诞生出来;程序流程又回到了CmyWinApp::InitInstance。于是调用ShowWindow函数令窗体显示出来,并调用UpdateWindow函数令hello程序发送出WM_PAINT消息。

我们非常关心这个WM_PAINT消息是怎样送到窗体函数的手中。并且,窗体函数又在哪里?

MFC程序是不是也像SDK程序一样。有一个GetMessage/DispatchMesage循环?

CWinApp::Run

       程序执行到这,接下来将执行pApp->Run()即相当于调用CMyWinApp::Run();

Run函数是CWinApp的一个虚函数,并且我们没有改写它。所以上述操作相当于调用CWinApp::Run();通过研读Run函数实现代码它会调用PumpMessage()函数。在这个函数中就是真正处理消息循环函数。

三 整理

1.程序的诞生:

Application object 产生,内存于是获得配置,初值亦设立了。AfxWinMain

运行AfxWinInit,后者有调用AfxInitThread,把消息队列尽量加大到96。

AfxWinMain运行InitApplication。

这是CWinApp的虚函数,我们通常不改写它。

AfxWinMain运行InitInstance。

这是CWinApp的虚函数,我们必须改写它。

CMyWinApp::InitInstance new 了一个CMyFrameWnd对象。

CMyFrameWnd构造函数调用Create,产生主窗体。

回到InitInstance中继续运行ShowWindow。显示窗体。

运行UpdateWindow。于是发出WM_PAINT。

回到AfxWinMain。运行Run,进入消息循环。

2.程序開始执行:

程序获得WM_PAINT消息(藉由CWinApp::Run中的::GetMessage循环)。

WM_PAINT经由::DispatchMessage送到窗体函数CWnd::DefWindowProc

中。

CWnd::DefWindowProc将消息传递过消息映射表格(Message Map)。

传递过程中发现有相符项目,于是调用项目中相应的函数。此函数是应用程序利用BEGIN_MESSAGE_MAP和END_MESSAGE_MAP之间的宏设立起来的。

标准消息的处理程序亦有标准命名。比如WM_PAINT必定由OnPaint处理。

3.程序的死亡

使用者单击【File/Close】,于是发出WM_CLOS。

CMyFrameWnd并没有设置WM_CLOSE处理程序。于是交给默认的处理程序。

默认的处理函数对于WM_CLOSE的处理方式是调用::DestroyWindow,并因

而发出WM_DESTROY。

CWinApp::Run收到WM_QUIT后会结束其内部消息循环。然后调用

ExitInstance,这是CWinApp的一个虚拟函数。

最后回到AfxWinMain,运行AfxWinTerm,结束程序。

时间: 2024-10-11 01:54:53

MFC的执行过程分析的相关文章

Mapreduce执行过程分析(基于Hadoop2.4)——(三)

4.4 Reduce类 4.4.1 Reduce介绍 整完了Map,接下来就是Reduce了.YarnChild.main()—>ReduceTask.run().ReduceTask.run方法开始和MapTask类似,包括initialize()初始化,根据情况看是否调用runJobCleanupTask(),runTaskCleanupTask()等.之后进入正式的工作,主要有这么三个步骤:Copy.Sort.Reduce. 4.4.2 Copy Copy就是从执行各个Map任务的节点获取

Mapreduce执行过程分析(基于Hadoop2.4)——(一)

1 概述 该瞅瞅MapReduce的内部运行原理了,以前只知道个皮毛,再不搞搞,不然怎么死的都不晓得.下文会以2.4版本中的WordCount这个经典例子作为分析的切入点,一步步来看里面到底是个什么情况. 2 为什么要使用MapReduce Map/Reduce,是一种模式,适合解决并行计算的问题,比如TopN.贝叶斯分类等.注意,是并行计算,而非迭代计算,像涉及到层次聚类的问题就不太适合了. 从名字可以看出,这种模式有两个步骤,Map和Reduce.Map即数据的映射,用于把一组键值对映射成另

Mapreduce执行过程分析(基于Hadoop2.4)——(二)

4.3 Map类 创建Map类和map函数,map函数是org.apache.hadoop.mapreduce.Mapper类中的定义的,当处理每一个键值对的时候,都要调用一次map方法,用户需要覆写此方法.此外还有setup方法和cleanup方法.map方法是当map任务开始运行的时候调用一次,cleanup方法是整个map任务结束的时候运行一次. 4.3.1 Map介绍 Mapper类是一个泛型类,带有4个参数(输入的键,输入的值,输出的键,输出的值).在这里输入的键为Object(默认是

图库Gallery3D(Gallery2)分析(四) 菜单命令执行过程分析

该分析基于 Android4.2的Gallery2 1 菜单创建过程分析. Gallery的父类是AbstractGalleryActivity类,AbstractGalleryActivity的父类是Activity类.所以菜单创建是调用的AbstractGalleryActivity的菜单创建函数. public class AbstractGalleryActivity extends Activity implements GalleryContext { private static

Task的执行过程分析

Task的执行过程分析 Task的执行通过Worker启动时生成的Executor实例进行, caseRegisteredExecutor(sparkProperties)=> logInfo("Successfullyregistered with driver") //Make this host instead of hostPort ? executor= newExecutor(executorId, Utils.parseHostPort(hostPort)._1,s

ART运行时Semi-Space(SS)和Generational Semi-Space(GSS)GC执行过程分析

Semi-Space(SS)GC和Generational Semi-Space(GSS)GC是ART运行时引进的两个Compacting GC.它们的共同特点是都具有一个From Space和一个To Space.在GC执行期间,在From Space分配的还存活的对象会被依次拷贝到To Space中,这样就可以达到消除内存碎片的目的.本文就将SS GC和GSS GC的执行过程分析进行详细分析. 老罗的新浪微博:http://weibo.com/shengyangluo,欢迎关注! 与SS G

ART运行时Mark-Compact( MC)GC执行过程分析

除了Semi-Space(SS)GC和Generational Semi-Space(GSS)GC,ART运行时还引入了第三种Compacting GC:Mark-Compact(MC)GC.这三种GC虽然都是Compacting GC,不过它们的实现方式却有很大不同.SS GC和GSS GC需两个Space来压缩内存,而MC GC只需一个Space来压缩内存.本文就详细分析MC GC的执行过程. 老罗的新浪微博:http://weibo.com/shengyangluo,欢迎关注! 从前面AR

MFC程序执行过程剖析

一 MFC程序执行过程剖析 1)我们知道在WIN32API程序当中,程序的入口为WinMain函数,在这个函数当中我们完成注册窗口类,创建窗口,进入消息循环,最后由操作系统根据发送到程序窗口的消息调用程序的窗口函数.而在MFC程序当中我们不在能找到类似WinMain这样的程序入口,取而代之的是一系列派生类的声明和定义以及一个冲CWinApp类派生而来的类的全局对象.CWinApp类被称之为应用程序对象,在一个MFC程序当中只允许有一个应用程序对象.由于CWinApp的派生对象是全局的,因此这个对

mfc程序执行入口

一 MFC程序执行过程剖析 1)我们知道在WIN32API程序当中,程序的入口为WinMain函数,在这个函数当中我们完成注册窗口类,创建窗口,进入消息循环,最后由操作系统根据发送到程序窗口的消息调用程序的窗口函数.而在MFC程序当中我们不在能找到类似WinMain这样的程序入口,取而代之的是一系列派生类的声明和定义以及一个冲CWinApp类派生而来的类的全局对象.CWinApp类被称之为应用程序对象,在一个MFC程序当中只允许有一个应用程序对象.由于CWinApp的派生对象是全局的,因此这个对