class CDocView : public CView {

DECLARE_DYNCREATE ( CDocView ) public:

CDocView();

virtual -CDocView();

>;

IMPLEMENT_DYNCREATE( CDocView, CView )

CDocView::CDocView()

{

}

CDocView::-CDocView()

{

}

Кроме этого, я изменил метод lnitlnstance() класса CDocViewl:

BOOL CDocViewlApp::Initlnstance() {

#ifdef _AFXDLL

Enable3dControls(); #else

Enable3dControlsStatic(); #endif

LoadStdProfileSettings(); CDocTemplate* pDocTemplate;

pDocTemplate = new CMultiDocTemplate( IDR_DOCUMENT,

RUNTIME__CLASS ( CDoc ) , RUNTIME_CLASS( CMDIChildWnd ), RUNTIME_CLASS( CDocView ) ) ; AddDocTemplate( pDocTemplate ); CMainFrame* pMainFrame = new CMainFrame; pMainFrame->LoadFrame( IDR_RESOURCE ); m_pMainWnd = pMainFrame; pMainFrame->ShowWindow(m_nCmdShow ); pMainFrame->UpdateWindow();

return TRUE;

}

Когда я постарался откомпилировать эту программу, я получил сообщение о том, что у класса, наследуемого от CView, не опреде­лен метод OnDraw(). Ну, конечно же! Откуда же наш произвольный класс окна представления будет знать, каким образом ему необхо­димо перерисовываться? Давайте опять постараемся рассуждать логически. Какое сообщение получает окно, когда ему нужно пе­рерисовать себя? Правильно, WM_PAINT. Но для обработки со­общения WM_PAINT объекты MFC используют метод OnPaintQ.

Не является исключением и объекты класса CView и унаследо­ванных от него. Исходный код этого метода находится в файле viewcore.cpp:

void CView::OnPaint() {

// standard paint routine CPaintDC dc(this); OnPrepareDC(&dc); OnDraw(&dc);

}

Очевидно, что перерисовка осуществляется методом OnDraw(). Взглянем на исходный код этого метода, который также находится в файле viewcore.cpp:

void CView::OnDraw(CDC*)

{

}

To, что этот метод не делает ничего, подтверждает нашу догад­ку о том, что нам нужно переписать именно этот метод. Что ж опи­сание нашего класса CDocView придется немного изменить. Те­перь оно будет выглядеть так:

class CDocView : public CView {

DEСLARE_DYNCREATE ( CDocView ) public:

CDocView();

virtual ~CDocView(); void OnDraw( CDC* pDC );

};

Естественно, нам придется переопределить и добавить в про­грамму метод OnDravtr(). Пока этот метод нас не очень интересует, поэтому оставим его пустым:

void CDocView::OnDraw( CDC* pDC )

{

}

Наверное, отсюда можно сделать вывод, что класс CView пре­доставляет только базовые возможности для отображения данных. Надеюсь, у нас еще будет шанс разобраться с этим.

Любознательный читатель уже, наверное, приготовил мне во­прос: да, конечно, все что рассказывается, это верно, но каким же образом создается окно представления и как оно относится к окну фрейма и документу?

BOOL CDocViewlApp::Initlnstance () {

#ifdef _AFXDLL

Enable3dControls(); #else

Enable3dControlsStatic(); #endif

LoadStdProfileSettings(); CDocTemplate* pDocTemplate;

pDocTemplate = new CMultiDocTemplate( IDR_DOCUMENT,

RUNTIME_CLASS( CDoc ),^% RUNTIME_CLASS( CMDIChildWnd ),

NULL );

AddDocTemplate( pDocTemplate ); CMainFrame* pMainFrame = new CMainFrame; pMainFrame->LoadFrame( IDR_RESOURCE ); m_pMainWnd = pMainFrame; pMainFrame->ShowWindow(m_nCmdShow ); pMainFrame->UpdateWindow();

return TRUE;

}

создается фрейм этого документа. Нетрудно догадаться, что соз­дание фрейма происходит при вызове метода CDocTemplate:: CreateNewFrame():

CFrameWnd* CDocTemplate::CreateNewFrame(CDocument* pDoc,

CFrameWnd* pother)

{

if (pDoc != NULL)

ASSERT_VALID(pDoc); // create a frame wired to the specified document

ASSERT(m_nIDResource != 0); // must have a resource. ID

// to load from

CCreateContext context;

context,m_pCurrentFrame = pother;

context.m_pCurrentDoc = pDoc;

context,m_pNewViewClass = m_pViewClass;

context.m_pNewDocTemplate = this;

if (m_pFrameClass == NULL) ‘ {

TRACEO("Error: you must override

CDocTemplate::CreateNewFrame.\n") ;

ASSERT(FALSE); return NULL;

}

CFrameWnd* pFrame =

(CFrameWnd*)m_pFrameClass->CreateObject() ; if (pFrame == NULL) {

TRACE1("Warning: Dynamic create of frame %hs failed.\n",

m_pFrameClass->m_lpszClassName);

return NULL;

}

ASSERT_KINDOF(CFrameWnd, pFrame);

if (context.m_pNewViewClass == NULL)

TRACEO("Warning: creating frame with no default

view.\n");

// create new from resource

if (!pFrame->LoadFrame(m_nIDResource,

WS_OVERLAPPEDWINDOW | FWS_ADDTOTITLE, // default frame styles

NULL, &context))

{

TRACEO("Warning: CDocTemplate couldn’t create

a frame.\n"); // frame will be deleted in PostNcDestroy cleanup return NULL;

}

// it worked ! return pFrame;

}

Мне бы хотелось обратить внимание читателя на то, что в каче­стве аргументов методу передаются указатель на документ и ука­затель (пока нулевой), в который будет записан указатель на соз­данный фрейм. Мы уже однажды (при рассмотрении метода DoPromptFileName()) замечали, что методу передаются указате­ли, которые с первого взгляда совершенно не нужны для работы метода. Кажется, здесь тот же случай – ну зачем, скажите, пожа­луйста, при создании фрейма знать указатель на документ? То, что буквально в первых строках метода осуществляется проверка того, не равен ли идентификатор ресурсов нулю, говорит о том, что, вероятнее всего, при создании фрейма опять будут использо­ваться ресурсы. Но, как говорится, поживем – увидим.

IDRJDOCUMENT "\nExe-file\nExe-file\n

Executable files (*.exe)\n.exe\n\n"

Мне бы хотелось, чтобы в диалоговом окне мне предлагалось осуществить выбор из ехе-файлов. Естественно, мне необходимо указать идентификатор ресурса в методе lnitlnstance() моего при­ложения. После внесенных изменений он стал выглядеть следую­щим образом:

BOOL CDocViewlApp::Initlnstance () {

#ifdef _AFXDLL

Enable3dControls(); #else

Enable3dControlsStatic (); #endif

LoadStdProfileSettings(); CDocTemplate* pDocTemplate;

pDocTemplate = new CMultiDocTemplate( IDRJDOCUMENT,

NULL, NULL, NULL );

AddDocTemplate( pDocTemplate ); CMainFrame* pMainFrame = new CMainFrame; pMainFrame->LoadFrame( IDR_RESOURCE );

m_pMainWnd = pMainFrame; pMainFrame->ShowWindow(m_nCmdShow ) ; pMainFrame->UpdateWindow() ;

return TRUE;

}

Посмотрим, правильны ли мои рассуждения и сработает ли в данном случае моя программа. Итак, компилируем… Запуска­ем… Выбираем «File», «Ореп» и…

Окно, появившееся на отображении, вы видите на 13. © Очень надеюсь, что того материала, который мы только что изу­чили, достаточно для понимания того, что происходит при подго­товке стандартного диалога. Надеюсь, что и в этом случае мы ус­пешно решили все поставленные задачи – мы поняли «физику» процесса и осознали возможную степень влияния программиста на процесс создания диалогового окна. Конечно, я мог бы объяс­нять все мелочи, встречающиеся в исходном коде, например, ото­бражение диалогового окна при помощи метода DoModal(), но имеет ли это смысл?

BOOL CDocViewlApp::Initlnstance() {

#ifdef _AFXDLL

Enable3dControls (); #else

Enable3dControlsStatic(); #endif

LoadStdProfileSettings(); CDocTemplate* pDocTemplate; pDocTemplate = new CDocTemplate( 0,

NULL ),

NULL,

NULL );

AddDocTemplate( pDocTemplate ); CMainFrame* pMainFrame = new CMainFrame; pMainFrame->LoadFrame( IDR_RESOURCE ); m_pMainWnd = pMainFrame; pMainFrame->ShowWindow(m_nCmdShow ); pMainFrame->UpdateWindow();

return TRUE;

}

Если вы помните, уважаемый читатель, я ранее оговорился, что при описании MFC мною был принят за аксиому тот факт, что класс приложения должен быть унаследован от класса CWinApp, вклю­ченного в MFC. Что ж, напишем простейшую программу для MFC:

#include <afxwin.h>

class CEmpty : public CWinApp {

};

CEmpty theApp;

Следом за методом lnitApplication() вызывается метод lnitlnstance(). Предназначение этого метода как раз и заключается в том, чтобы произвести инициализацию приложения. Исходный код этого метода находится в файле аррсоге.срр:

BOOL CWinApp::InitInstance() {

return TRUE;

}

Очевидно, что по умолчанию метод не производит никаких дей­ствий, т. е. мы должны переопределить этот метод в своей про­грамме и вставить сюда операторы, обеспечивающие реальную инициализацию нашего приложения.

Сразу после завершения работы метода lnitlnstance() вызыва­ется метод Run(). Его исходный код находится в файле аррсоге.срр:

int CWinApp::Run()

{

if (m_pMainWnd == NULL && AfxOleGetUserCtrl()) {

// Not launched /Embedding or /Automation, // but has no main window!

TRACEO("Warning: m_pMainWnd is NULL in CWinApp::Run -

quitting application.\n");

AfxPostQuitMessage(0);

}

return CWinThread::Run();

}

CWnd* m_pMainWnd; // main window

//(usually same AfxGetApp()->m_pMainWnd)

Другими словами, поле m_pMainWnd должно хранить указатель на объект класса CWnd, который должен быть ассоциирован с ок­ном, являющимся ГЛАВНЫМ окном приложения. Но где должен быть создан этот объект? У нас есть две возможности – метод Ini-tApplicationQ и метод lnitlnstance(). Так как метод InitApplicationQ используется MFC для других целей (инициализация менеджера документов), то, чтобы не переписывать метод lnitApplication(), луч­ше всего будет создать объект класса CWnd в переопределенном методе lnitlnstance(). Отсюда делаем еще один вывод: объект клас­са CWnd, который будет ассоциирован с главным окном прило­жения, целесообразно создавать в переопределенном методе InitlnstanceQ приложения.

А теперь давайте еще немного порассуждаем. Если наши рассуждения верны, то объект класса CWnd будет создан во вре­мя отработки метода InitlnstanceQ приложения. Но объект приложения будет создан ранее, во время отработки startup-кода! Инициализацией полей класса, в том числе и поля m_pWinMain, должен, естественно, заниматься конструктор класса. Но кон­структор класса CWinThread отрабатывает раньше конструктора класса CWinApp и, тем более, раньше метода lnitlnstance() при­ложения. Следовательно, поле m_pMainWnd после создания объекта приложения остается неинициализированным или со­держит неверную информацию. Значит, после того, как в ме­тоде InitlnstanceQ будет создано главное окно приложения, полю m_pMainWnd необходимо присвоить значение указателя на ассоциированный с окном объект. В противном случае про­грамма, увы, работать не будет!

Что ж, попробуем немного изменить нашу программу и доба­вить в нее переопределенный метод lnitlnstance(), в котором будет создан объект класса CWnd. Текст измененной программы:

#include <afxwin.h>

class CExampleApp : public CWinApp {

BOOL Initlnstance() ;

};

class CMainWnd : public CWnd {

};

BOOL CExampleApp::Initlnstance() {

CMainWnd* pMainWnd = new CMainWnd; m_pMainWnd = pMainWnd; return TRUE;

}

CExampleApp theApp;

int CWinThread::Run() {

ASSERT_VALID(this);

// for tracking the idle time state BOOL bldle = TRUE; LONG HdleCount = 0;

// acquire and dispatch messages until a WM_QUIT message is received, for (;;) {

// phasel: check to see if we can do idle work while (bldle &&

! : eekMessage(&m_msgCur, NULL, NULL, NULL, PM_NOREMOVE)) {

// call Onldle while in bldle state

if (!0nldle (HdleCount++) )

bldle = FALSE; // assume "no idle" state

}

// phase2: pump messages while available

do

{

// pump message, but quit on WM_QUIT if (!PumpMessage())

return Exitlnstance ();

// reset "no idle" state after pumping "normal" message if (IsIdleMessage(&m_msgCur)) {

bldle = TRUE; HdleCount = 0;

}

} while (::PeekMessage(&m_msgCur,

NULL, NULL, NULL,

PM_NOREMOVE));

}

ASSERT(FALSE); // not reachable

}

wsprintf(IpszName,

_T("Afx:%x:%x") , (UINT)hlnst, nClassStyle);

Примером может служить имя Afx:400000:0. Первое число в име­ни класса обозначает хэндл текущей копии приложения, второе число – стиль окон регистрируемого класса.

Если не все параметры, переданные функции, равны NULL, то формируется полное имя класса в соответствии с функцией

wsprintf(IpszName,

_Т("Afх:%х:%х:%х:%х:%х"),

(UINT)hlnst, nClassStyle,

(UINT)hCursor,

(UINT)hbrBackground,

(UINT)hlcon);

Примером такого имени может служить Afx:400000:8:14c6:0:4687. При этом первое число в имени класса означает хэндл текущей копии приложения, вггорое число – стиль окон регистрируемого класса, третье число означает хэндл курсора, четвертое – хэндл фона, и, наконец, пятое – хэндл иконки окна.

После формирования имени класса функция производит запол­нение структуры типа WNDCLASS и регистрирует класс окон, при­чем в качестве имени класса используется только что сформиро­ванное функцией имя.

Зарегистрировав класс окна, можно создавать окно. А создав окно, нужно не забыть его отобразить, верно? Таким образом, мы

«вычислили» те несколько шагов, которые ОБЯЗАТЕЛЬНО нужно вы­полнить при написании программы с использованием MFC:

1. Описываем класс приложения, производный от класса CWinApp.

2. Описываем класс, к которому будет принадлежать главное окно приложения (обычно CFrameWnd или CMDIFrameWnd).

3. Переопределяем метод lnitlnstance() класса приложения.

4. В методе lnitlnstance() создаем новый объект класса, к которо­му будет принадлежать главное окно приложения.

5. Указатель на только что созданный объект записываем в поле m__pMainWnd.

6. Регистрируем класс окон, к которому будет принадлежать глав­ное окно приложения.

7. В методе lnitlnstance() создаем непосредственно окно только что зарегистрированного класса, которое будет являться главным окном приложения.

8. Создаем объект класса приложения.

Исходный текст демонстрационной программы, написанной в соответствии с определенной нами последовательностью шагов, приведен ниже:

#include <afxwin.h>

Вернемся к рассмотрению метода CWinThread::Run(). Обраща­ет на себя внимание тот факт, что метод позволяет производить какие-то действия в тот период, когда в очереди нет никаких сооб­щений. Другими словами, если переменная bldle равна TRUE и функция PeekMessage(), при помощи которой осуществляется выборка сообщений, вернула FALSE, то метод вызывает другой метод, Onldle().