Программирование на Visual C++. Архив рассылки - Алекс Jenter

Программирование всегда доставляло мне удовольствие. То есть, программирование на C. Кто может сказать, что C не может дать человеку все, что нужно для выполнения работы? Мне казалось, что вся эта рекламная шумиха вокруг C++ и MFC – не более чем старание хитрецов из отдела по маркетингу оправдать свою зарплату. Ведь как бы то ни было, а я и во сне мог писать подпрограммы для Windows. Мне нравились изящные, плавные отступы массивных операторов switch, которые могли позаботиться обо всем, и даже больше, что могло прийти в голову любому Windows-приложению. Я был полон решимости не попасть в водоворот. Черная дыра абстракции меня не получит. Нет уж.

Но я почувствовал, что я как будто был один. Создал в интернете группу для тех, кто интересуется C, – и был единственным, кто в нее записался! Все мои коллеги уже носили костюмчики C++ с завязками из MFC для работы. Когда я программировал, мне часто стали говорить: "В MFC это было бы гораздо проще". Но мне не нужно было "проще"! Мне был нужен полный контроль! А комбинация C++ и MFC уводила еще дальше от уже достаточно абстракного мира Windows на C. Меня стала мучить депрессия. Я начал задаваться вопросом о своей компетентности. (Не правда ли, это зашло достаточно далеко?)

Как раз тогда вмешался мой друг Найджел. Он попросил меня написать программу на основе MFC, использующую архитектуру документ/представление. Очень нехотя, я дал ему положительный ответ. И тут же его уточнил, сказав: "И зачем только я хочу заниматься этим скучным делом?"

Ниже следует отчет о процессе написания программы. А точнее, это обсуждение тех областей, где мне пришлось повозиться с некоторыми исследованиями, чтобы получить нужную для приложения функциональность. Можете считать это свидетельством в пользу способности MFC освободить программистов от той рутинной черновой работы, с которой нам приходилось иметь дело еще со времен Windows версии 1.0. Я немного запоздал? Возможно. Но я уверен, что многие из вас тоже задержались в пути.

Как я заметил выше, Найджел попросил меня написать программу, использующую архитектуру документ/представление в MFC. Конечной целью этого испытания было мое полное вовлечение в мир MFC. Как гласило техническое задание, это Win32 приложение должно было использовать расширенные метафайлы (enhanced metafiles) в качестве документа (более подробную иноформацию о расширенных метафайлах см. в статье "Enhanced Metafiles in Win32" в MSDN), и выводить документ на экран в различных представлениях: либо в виде изображения, либо в виде заголовка метафайла отображаемого как текст. Кроме того, программа должна была позаботиться о печати вместе с предварительным просмотром. Имея все это в виду, я приступил к работе. Как вы увидите, в процессе пришлось воспользоваться некоторыми искусственными приемами. Хотя они и не были неотъемлемой частью приложения, они помогли реализовать нужную функциональность. Можете считать их полезными советами.

Здесь нет ничего сверхсложного. Я просто воспользовался мастером AppWizard Microsoft Visual C++. Я выбрал многодокументный интерфейс (MDI), поставил галочку напротив опции панели инструментов (toolbar), строки состояния (status bar), и предварительного просмотра (print preview). В результирующем проекте были созданы класс документа и представления. Но погодите, я что, сказал "класс представления" вместо "классы представлений"? Почему AppWizard не создал второе представление? Если вы помните, программа должна осуществлять два представления одного документа. Но AppWizard создает только один класс представления. "Вот бездельник", подумал я. Очевидно, мне придется добавить второе представление самому. Ах, ну да, зато предварительный просмотр прилагается бесплатно. Но мы еще вернемся к этому второму представлению документа.

Хорошо, и где же в такой системе происходит открытие документа? Я неверно предположил, что это будет происходить в ответ на выбор пользователя команды Открыть из меню Файл. Ну и глупец же я. Это было бы слишком очевидно. В течение некоторого времени я шел этой дорогой, пока не понял, что фактически делаю всю работу сам. Я-то думал, что MFC будет мне помогать! "Неважно", подумал я, "просто спущусь в офис к Найджелу и спрошу его". Как оказалось, мне нужно было обрабатывать открытие файла в функции Serialize, принадлежащей классу документа. Следующий код иллюстрирует мою первую попытку сделать это.

void CMetavw1Doc::Serialize(CArchive& ar) {

 if (ar.IsStoring()) {}

 else {

  UINT uiSig;

  ar.Read(&uiSize, sizeof(UINT));

  if (uiSiz == EMR_HEADER) {

   m_hemf = GetEnhMetaFile(m_szPathName);

  }

 }

}

Интересующий нас код находится в блоке else. Этот код просто читает первые sizeof(UINT) байт из файла, чтобы убедиться что они являются сигнатурой расширенного метафайла. Если это так, данные загружаются с помощью GetEnhMetaFile. Так как я пока не сохраняю никаких документов, в ответ на IsStoring нет никакого кода.

А не правда ли, было бы неплохо просто вызвать что-то вроде Load(m_szPathName) чтобы загрузить файл? Ага! Эта будет наш первый хитрый прием! Я решил написать класс, который будет иметь дело непосредственно с метафайлами, загружать их и воспроизводить (об этом подробнее см. дальше). Использование этого класса уменьшило необходимый код загрузки до следующего:

void CMetavw1Doc::Serialize(CArchive& ar) {

 if (ar.IsStoring()) {}

 else {

  cemf.Load(m_szPathName);

 }

}

Заметьте, что в обоих фрагментах я использовал переменную m_szPathName как аргумент при вызове функций GetEnhMetaFile и Load. Поначалу я думал, что можно получить полное имя файла из параметра типа CArchive функции Serialize. Ведь CArchive содержит переменную-член m_pDocument, которая указывает на сериализуемый в данный момент объект типа CDocument. Отлично, у CDocument есть очень удобная переменная-член, которая выглядела как раз как то, что мне было нужно: m_strPathName. К сожалению, m_pDocument->strPathName инициализируется нулем при открытии файла. Так что я решил получить имя файла и путь к нему перекрыв фукцию OnOpenDocument. Путь напрямую передавался в OnOpenDocument, так что я просто сделал копию внутри класса CMetavw1Doc в той самой переменной, которая передавалась в качестве параметра функциям GetEnhMetaFile и Load.

BOOL CMetavw1Doc::OnOpenDocument(LPCTSTR lpszPathName) {

 m_szPathName = lpszPathName;

 if (!CDocument::OnOpenDocument(lpszPathName)) return FALSE;

 return TRUE;

}

Итак, что я получил практически ничего не делая? На этот вопрос легко ответить. Все, что перечислено в следующем списке (плюс многое другое, что я еще просто не успел оценить, я уверен) было предоставлено MFC:

• Стандартное диалоговое окно открытия файла

• Список недавно открытых файлов в меню Файл

• Возможность перетаскивать файлы из Проводника в мое приложение (они даже открываются!)

• Невообразимое ощущение легкости.

После заполнения моего класса представления (METAVVW.CPP) кодом, необходимым для успешной отрисовки расширенного метафайла, мне стало ясно что я возвращаюсь к своим старым привычкам неорганизованного кодирования на C. Так что я решил убрать весь этот код из класса представления и создать класс, который будет заниматься загрузкой и воспроизведением метафайлов.

Для целей моего маленького приложения, Load и Draw были самыми важными функциями этого класса. Полностью в духе C++, я также написал несколько дополнительных функций для доступа к различным атрибутам метафайла, таким как дескриптор (handle), строка описания, и указатель на заголовок. Следующий код (взятый из CEMF.H) дает хорошее представление о том, что я сделал из этого класса. Заметьте, что я унаследовал класс от CObject, а не от CDC или CMetaFileDC. CDC включает в себя функции PlayMetaFile и AddMetaFileComment, и в ретроспективе, возможно, было бы более удобно унаследовать класс от CDC. Наследование от CMetaFileDC казалось неправильным, потому что я не создавал метафайлы, а просто просматривал уже существующие. Тем не менее, полностью функциональный класс метафайла мог бы быть унаследован и от CMetaFileDC. Да, есть много способов содрать с кота шкуру (прошу прошения у любителей кошек!)

class CEMF : public CObject {

 // Операции

public:

 CEMF();

 ~CEMF();

 BOOL Load(const char *szFileName);

 BOOL Draw(CDC* pDC, RECT* pRect);

 LPENHMETAHEADER GetEMFHeader() {

  return ((m_pEMFHdr) ? m_pEMFHdr : NULL);

 }

 LPTSTR GetEMFDescString() {

  return ((m_pDescStr) ? m_pDescStr : NULL);

 }

 HENHMETAFILE GetEMFHandle() {

  return ((m_hemf) ? m_hemf : NULL);

 }

protected:

 BOOL GetEMFCoolStuff();

 BOOL LoadPalette();

 // Данные

protected:

 CString m_szPathName;

 HENHMETAFILE m_hemf;

 LPENHMETAHEADER m_pEMFHdr;

 LPTSTR m_pDescStr;