загрузка...
Перескочить к меню

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

- Программирование на Visual C++. Архив рассылки 2.48 Мб, 730с. (скачать fb2) - Алекс Jenter

Использовать online-читалку "Книгочей 0.2" (Не работает в Internet Explorer)


Настройки текста:



Программирование на Visual C++ Архив 

Программирование на Visual C++ Выпуск №1

Добрый день всем!

Итак, свершилось: вы видите перед собой первый выпуск рассылки.

Я понимаю, что ведение такой рассылки – это огромная ответственность, принимая во внимание огромное количество сайтов по этой теме (кстати, именно вопиющее отсутствие рассылки о Visual C++ на горкоте и подвигнуло меня на ее создание). Это мой первый опыт такого рода, так что пока я прошу вас не судить слишком строго. Я же со своей стороны постараюсь сделать все от меня зависящее, чтобы рассылка была интересной, занимательной и полезной.

Прежде всего, я хотел бы уточнить тематику наших бесед. А именно то, что вы здесь не найдете учебника по программированию типа "шаг-за-шагом". По этому принципу построено очень много разных книг, сайтов в Рунете и других источников. На мой взгляд, такие учебники учат только тому, что в них заложено. Они предлагают решение какой-то задачи, но если вам нужно решить задачу немного отличную от описанной, то начинаются проблемы. Ведь очень часто авторы для упрощения изложения выбирают самые тривиальные решения, не подходящие для большинства реальных задач. И приходится выкручиваться своими силами – штудируя help, делая методом "тыка". И, хочу заметить, гораздо чаще такие вот искания оказываются полезнее тупого выполнения шагов учебника, потому что в процессе поиска выдумаете и решаете сами.

С другой стороны, не поймите меня неверно – я вовсе не отрицаю право таких учебников на существование (думаю, что на какой-то стадии они могут быть даже очень полезны), я лишь подчеркиваю их ограниченную применимость.

Именно поэтому в рассылке не будет учебников типа "пишем свою записную книжку".

Хочу подчеркнуть, что все вышеизложенное является моим личным мнением и вы вправе быть с ним не согласны. По правде говоря, я на это рассчитываю ;) Пишите мне – и мы это обсудим.

Итак, что же будет освещено в рассылке?

Во-первых, некоторые теоретические сведения – знание теории никогда и никому не вредило. Причем основной упор будет делаться вовсе не на C++ как язык программирования (хотя это я тоже не исключаю), а на такие вещи, как MFC и WinAPI. Во-вторых, разные полезные приемы программирования и хитрости, советы и трюки. Еще, объяснение некоторых английских терминов по программированию. Потом, обзор некоторых книг по данной теме, перевод интересных статей из интернета и, конечно же, ваши письма, вопросы, мнения.

Но этим я не хотел бы жестко ограничиваться. Пишите, что интересно Вам лично?


Я долго думал, с чего лучше всего будет начать. Ведь уровень у каждого из вас совершенно разный. И решил, что для начала это должно быть что-то "легкое", понятное всем, но и не совсем бесполезное в то же время.

Поэтому следующий материал к программированию как таковому не относится, он лишь позволяет сделать его более комфортным.

Пробовали ли Вы хоть раз менять стандартную синтаксическую подсветку в Visual C++ IDE? Если да, то знаете, что, к сожалению, в настройках доступно только 16 возможных цветов. Какая жалость! Ведь можно было бы сделать очень приятную цветовую схему, ярко выражающую вашу индивидуальность… ну или просто более приятную для глаз.

Неужели ничего нельзя поделать? Оказывается, можно! Для исполнения этого желания нам придется воспользоваться стандартным виртуальным "ломом" для Windows. Нет, я не имею ввиду дизассемблирование – избави бог! ;) В качестве лома в данном случае будет выступать просто редактор реестра (regedit.exe).

Запустите RegEdit и откройте ветвь

HKEY_CURRENT_USER\Software\Microsoft\DevStudio\6.0\Format\Source Window

В окне просмотра появится список значений. Каждому синтаксическому элементу соответствует определенный набор шестнадцатеричных чисел. Первые три из них – это цвет самого элемента в виде RGB. Потом одно число пропускается (там, как правило, 0) и три следующие числа – это цвет фона. Т.е. формат такой: RGB-0-RGB-0 (остальные числа лучше не трогать).

Вот и все – теперь для любого элемента программы ( комментария, строки, ключевого слова или др.) вы можете назначить любой из 16 млн. доступных цветов!

ВОПРОС-ОТВЕТ

Q. Как изменить стили окон, создаваемых MFC AppWizard'ом по умолчанию?

A. Чтобы изменить стиль по умолчанию какого-нибудь окна, нужно перекрыть виртуальную функцию PreCreateWindow() класса этого окна. Эта функция позволяет приложению получить доступ к процессу созданию окна, который по умолчанию происходит в недрах MFC с помощью класса CDocTemplate. Библиотека вызывает PreCreateWindow() перед созданием окна. Этой функции передается параметр – указатель на структуру CREATESTRUCT. Путем изменения членов этой структуры вы можете влиять на стиль создаваемого окна.


Q. Как сделать так, чтобы положение элементов управления менялось, когда размер окна изменяется, т.е., например, чтобы они выравнивались по правому или нижнему краю?

А. Увы, это не так элементарно делается, как, скажем, в C++ Builder. Но и здесь есть свои плюсы – вы получаете больший контроль. Пусть, скажем, у Вас есть кнопка, которую Вам нужно выровнять по правому краю, и соответствующая переменная m_Btn типа CButton в классе вашего окна или вида. Тогда в функции обработки сообщения WM_SIZE – OnSize().

void CMyView::OnSize(UINT nType, int cx, int cy) {

 CFormView::OnSize(nType, cx, cy);

 .

 .

 // ... добавьте вот это:

 if (::IsWindow(m_Btn.m_hWnd)) // условие на корректность

  m_Btn.MoveWindow(cx - BtnWidth - 10, BtnY, cx - 10, BtnY + BtnHeight, 0); // двигаем кнопку

 // конец кода для добавления.

 .

 .

}

Здесь вместо BtnY вставьте желаемую Y-координату кнопки, BtnWidth и BtnHeight – соответственно целевые ширина и высота кнопки.

Параметр  cx,  передаваемый  в функцию - это новая ширина окна. Данный код изменяет положение кнопки, чтобы она оставалась ширины Btn_Width и отстояла  от  правого  края  окна  на  10 единиц. Функция MoveWindow() меняет размер и положение кнопки. Если вы не знаете BtnY|Width|Height, то  их  можно определить с помощью функции m_btn.GetClientRect(), ведь любой элемент управления - это, в принципе, тоже окно.

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


Ну вот, на сегодня пока все. Жду ваших писем с замечаниями, предложениями и пожеланиями. До скорого!

(C) 2000 by Алекс Jenter mailto:jenter@mail.ru.

Программирование на Visual C++ Выпуск №2 от 20/6/2000

Приветствую вас, уважаемые подписчики!

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

Сегодня мы немного поговорим об устройстве MFC, а также рассмотрим один интересный вопрос.

НЕМНОГО ТЕОРИИ

Как известно, основой всех основ в MFC является класс CObject. Основным назначением этого класса является предоставление некоторых базовых возможностей всем своим наследникам, а именно доступ к информации о классе во время выполнения и поддержка сериализации, т.е. сохраняемости объектов.

Однако уровень предоставляемых возможностей варьируется в зависимости от вашего выбора; он зависит от включения определенных макросов объявления и реализации при создании классов – наследников CObject. Без сомнения, вы с этими макросами уже сталкивались, например в коде, который генерируют Wizard'ы. Пришла пора разобраться с ними более детально.

Итак, на характер вашего класса, производного от CObject, вы можете влиять с помощью нескольких макросов. Существуют определенные пары макросов — один включается в объявление класса (имеет префикс DECLARE_), а соответствующий ему — в реализацию (префикс IMPLEMENT_).

Первая пара макросов — это DECLARE_DYNAMIC|IMPLEMENT_DYNAMIC. С помощью включения этих макросов в код вашего класса вы можете включить одну из базовых функций CObject — способность узнавать класс объекта прямо во время выполнения программы. Для этого вы можете пользоваться функцией IsKindOf() в связке с макросом RUNTIME_CLASS, который возвращает указатель на структуру CRuntimeClass (где хранится вся информация о классе: имя, размер, версия, информация о базовом классе, указатель на конструктор объекта и т.д.)

Следующая пара — DECLARE_DYNCREATE|IMPLEMENT_DYNCREATE аналогична первой, но к возможности получать информацию о классе добавляется еще и  возможность создавать объекты этого класса во время выполнения.

Объект создается функцией CreateObject структуры CRuntimeClass. Вот пример:

CRunTimeClasspClass = RUNTIME_CLASS(СMyObject);

 // получаем ук-ль на структуру CRunTimeClass

CObjectpNewObject= pClass->CreateObject();

 // создаем новый объект нужного класса

ASSERT(pNewObject->IsKindOf(RUNTIME_CLASS(CMyObject));

 // проверяем класс объекта

И, наконец, мы подошли к последней паре макросов DECLARE_SERIAL| IMPLEMENT_SERIAL.  Преобразование в последовательную форму и обратно — сериализация — дает программисту возможность сохранения и восстановления  объектов. Для того, чтобы воспользоваться этой возможностью, в классе-наследнике нужно перекрыть виртуальную функцию Serialize().

Из нее обязательно нужно сначала вызвать родительскую версию. Одна и та же функция используется как для сохранения, так и для восстановления объекта. Какую операцию нужно произвести, она определяет  из своего единственного параметра ar типа CArchive. Вот пример:

void CMyObject::Serialize(CArchive ar) {

 CObject::Serialize(ar); // вызываем версию базового класса

 if (ar.IsStoring()) // если сохраняем,

 {

  ar << something; // то сохранить что-то

 } else // а иначе

 {

  ar >> something; // восстановить

 }

}

Заметьте, что DECLARE_SERIAL|IMPLEMENT_SERIAL помимо сериализации включают и те возможности, которые дают две первые пары — это естественно, ведь если вы восстанавливаете объект, то вам понадобится возможность создать его во время выполнения программы. Например, приложению нужно сохранять и восстанавливать некоторый набор объектов различного типа. А для вызова соответствующего  конструктора при восстановлении  объекта нужно знать его тип. Механизм сериализации сохраняет информацию об объекте вместе с теми  данными, что вы записываете явно в функции Serialize().

ВОПРОС – ОТВЕТ

Следующий вопрос поступил от одного из подписчиков:

Q При программировании элементов ActiveX, в этой технологии есть возможность структурного хранения данных на диске, т.е. создание в файле так называемых хранилищ и потоков (использование интерфейсов IStream и IStorage), проще говоря – представление файла данных в виде иерархической системы внутренних каталогов и файлов, которые там (в данном файле данных) имеют свои строковые имена. Есть ли в MFC возможность структурного хранения, скажем, используя объект класса CArchive в переопределяемой функции Serialize(CArchive) класса, производного от CDocument, ну и так далее? Конечно, этого можно добиться, создав свои собственные наработки (а как хороша эта идея, я имею в виду использование потоков и хранилищ), но все таки хочется знать, есть ли такие возможности в MFC, чтобы не тратить зря время.

Броник (krivoruchko@nvrsk.ru)

A Насколько мне известно, поддержки такой иерархической системы в MFC нет. Во всяком случае, я ее не обнаружил. CArchive и Serialize для этой цели явно не предназначены: в них важную роль играет последовательность записи, т.е. в каком порядке вы что-то записали, в таком нужно это и прочитать. Так что, скорее всего, придется писать свой класс для этой цели. Конечно, это не слишком обнадеживает, но зато этот класс можно будет использовать во всех дальнейших программах, где потребуется такая форма хранения данных. Или – как вариант – можно сделать просто класс-обертку для интерфейсов IStorage и IStream. Конечно, в этом случае придется подключать библиотеку COM (которую в MFC-приложениях, в принципе, никто не запрещает использовать). Впрочем, если кто знает что-нибудь о существовании такого механизма в MFC – пожалуйста, поделитесь с нами.


Всего наилучшего и чтоб программы ваши не знали ошибок.

(C) Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №3 от 23/06/2000

Здравствуйте!

Да, это должно было произойти и это произошло! Рассылка получила официальный статус "обычной некоммерческой рассылки" (причем гораздо быстрее, чем я ожидал), с чем я себя и всех вас и поздравляю! 

Хочу извиниться перед подписчиками HTML-версии: во втором выпуске случилось некоторое искажение исходного кода (я упустил из виду, что при автоматической генерации HTML сервер Гор. Кота звездочки (*) интерпретирует как указание сделать шрифт жирным), в результате чего были потеряны указатели. Вот как этот код должен был выглядеть на самом деле:

CRunTimeClass *pClass = RUNTIME_CLASS(СMyObject);

 // получаем ук-ль на структуру CRunTimeClass

CObject *pNewObject = pClass->CreateObject();

 // создаем новый объект нужного класса

ASSERT(pNewObject->IsKindOf(RUNTIME_CLASS(CMyObject));

 // проверяем класс объекта

Меня удивило, что большинство из вас  подписывается именно на HTML – я думал, наши люди как никакие другие считают каждый килобайт. Но, видимо, времена меняются – в лучшую сторону. Дай бог! Так что по вышеописанным причинам я решил поднапрячься и сработать собственный HTML-вариант. То, что получилось, сейчас перед вами, уважаемые HTML-подписчики. Тех, кто выписывает текстовый вариант, уговаривать подписаться на HTML я не буду, потому что прекрасно их понимаю ;) Оба варианта я буду делать лично, никакой автоматической генерации. Enjoy.

ОБРАТНАЯ СВЯЗЬ

Мне пришло интересное письмо на тему предыдущего выпуска. Хочу предложить его вашему вниманию:

Приветствую!

Я только что обнаружил эту рассылку, подписался и 2 первых выпуска прочитал в архиве. Очень надеюсь, что смогу оказать посильную помощь автору и читателям рассылки, так как около 30 лет занимаюсь программированием и последние 3-4 года – Visual C++. На работе сейчас я программирую именно на этом [языке – AJ], Visual Studio 6.0

В отношении вопроса Броника. Конечно, система сериализации для ActiveX имеется. Для этого рекомендуется использовать класс COLEControl (порожденный из CWnd –>CCMDTarget->CObject).

Вот пример из MSDN (у меня есть этот хелп и на работе и дома)

void CMyCtrl::Serialize(CArchive& ar) {

 DWORD dwVersion = SerializeVersion(ar, MAKELONG(_wVerMinor, _wVerMajor));

 SerializeExtent(ar);

 SerializeStockProps(ar);

 if (ar.IsLoading()) {

  // загрузить свойства

 } else {

  // сохранить свойства

 }

}

Пару замечаний относительно сериализации. Вот пример, как можно поддерживать версию при сериализации. Это важная вещь, поскольку в классы регулярно заносятся новые данные, и чтение-сериализация должны поддерживать старые версии распространенных среди пользователей Вашей программы файлов.

IMPLEMENT_SERIAL(CMyClass, CObject, VERSIONABLE_SCHEMA | 2)

// 2- Номер текущей (новой) версии. 1 - номер старой версии


void CMyClass::Serialize(CArchive& ar) {

 if (ar.IsLoading()) {

  UINT Version;

  ar.ReadClass(RUNTIME_CLASS(CMyClass), &Version);

  switch(Version) {

  case 2:

   // чтение по-новому

   break;

  case 1:

   // чтение по-старому

   break;

  }

 }

 if (ar.IsStoring()) {

  ar.WriteClass( RUNTIME_CLASS(CMyClass));

  // запись по-новому

 }

}

Понятное дело, при продвижении версии номер в IMPLEMENT_SERIAL возрастает, и добавляется новый случай case только при чтении соответствующих версий.

Еще одно важное замечание. При использовании механизма сериализации мы платим некоторую цену: не допускается никаких абстрактных классов – забудьте, что это существует!

Boris Berdichevski

Что ж, огромное спасибо Борису за комментарии и дополнения. Я надеюсь, он и в будущем будет нам посильно помогать. Что касается вопроса Броника – думаю, он все-таки спрашивал не о том, как сделать сериализацию для ActiveX(хотя это тоже очень интересный момент), а как организовать структурированное хранение данных в файле , наподобие того, что присутствует в ActiveX. Ответа на этот вопрос, за исключением предложенного мной в предыдущем выпуске, пока нет.

Просьба: когда пишете мне, пожалуйста оговаривайте ваше отношение к публикации вашего e-mail адреса. Я оставляю за собой право решать, какие из ваших писем появятся в рассылке. По умолчанию адрес публиковаться не будет.   Если вы хотите связаться с человеком, письмо которого  вы прочитали в рассылке, но чей адрес не был указан, пишите мне с пометкой в subject'e для кого это письмо.

ВОПРОС – ОТВЕТ

Q. Идея рассылки и её тематика очень понравились, даже добавлять или изменять ничего не хочется, как по заказу. И даже уже вопрос созрел. При первом знакомстве с MFC помню была одна проблема. Никак не получалось сменить пиктограмку курсора во время выполнения программы. Т.е. последовательность стандартных действий LoadCursor и SetCursor не срабатывала, хотя при создании окна этих действий хватало. В связи с этим вопрос: Какие ещё действия надо выполнить для смены пиктограмки курсора во время работы приложения. Сейчас, к сожалению, интересы лежат не в области C++ и MFC. Поэтому на разрешение вопроса своими силами просто нет времени.

softmax

A. Спасибо за добрые слова о рассылке. По вопросу – проблема здесь в том, что система автоматически при каждом движении мыши восстанавливает тот курсор, который был указан при регистрации класса окна. Вообще я знаю три способа изменить курсор в MFC-приложении, причем два из них имеют некоторые ограничения: один используется, в самом деле, при создании окна, а второй работает только с одним курсором – стандартными песочными часами. Думаю, что стоит описать все три способа, для того, чтобы вы могли выбрать наиболее для вас подходящий. Итак:

Способ №1 (универсальный). Нужно перекрыть функцию OnSetCursor() класса CWnd, родителя вашего окна (вида). В ней необходимо сообщение обработать самому, устанавливая нужный курсор. Для тех, кто не знает, сообщение WM_SETCURSOR посылается окну тогда, когда курсор мыши двигается внутри окна, причем  мышь приложением  не захвачена (с помощью функции SetCapture()). Вот пример из MSDN:

BOOL CMyView::OnSetCursor(CWnd* pWnd, UINT nHitTest, UINT message) {

 if (m_ChangeCursor) {

  // устанавливаем стандартный курсор вида "I"

  ::SetCursor(AfxGetApp()->LoadStandardCursor(IDC_IBEAM));

  return TRUE;

 }

 return CView::OnSetCursor(pWnd, nHitTest, message);

}

Конечно, можно установить и ваш собственный курсор, только вместо LoadStandardCursor() нужно будет воспользоваться LoadCursor() или LoadOEMCursor(). С помощью параметра nHitTest можно определить область, в которой сейчас находится курсор. Вообще, этот способ лучше применять только тогда, когда вам в самом деле нужно динамически менять один курсор на другой (причем отличный от песочных часов), потому этот способ самый нерациональный (прикиньте-ка. сколько раз будет выполняться этот обработчик). Лучше все нужные курсоры загрузить заранее, а из функции– обработчика Load..Cursor() не вызывать. Хотя, в принципе, я для примера сделал такой обработчик – никакой разницы в скорости не заметил…но это уже зависит от конкретного компьютера, наверное. И потом, наверное не стали бы в MSDN это советовать, если бы не знали, что делали ;) 

Ну а тем, кому лишь надо видом курсора  показать пользователю, что компьютер сейчас занят какой-то операцией, идеально подходит

Способ №2 (песочные часы). Этот способ самый простой. Вызывайте функцию BeginWaitCursor() перед началом операции и EndWaitCursor() после ее завершения. Единственный нюанс здесь в том, что если эти два вызова должны находиться в разных функциях-обработчиках, то вам все же придется перекрыть OnSetCursor(), причем это выглядит примерно так:

BOOL CMyView::OnSetCursor(CWnd* pWnd, UINT nHitTest, UINT message) {

 if (m_ChangeCursor) {

  RestoreWaitCursor(); // восстанавливаем курсор-пес.часы

  return TRUE;

 }

 return CView::OnSetCursor(pWnd, nHitTest, message);

}

В этом случае перед вызовом BeginWaitCursor()  m_ChangeCursor нужно приравнять к TRUE, а после EndWaitCursor() – к FALSE.

Способ №3 (класс окна). Этот метод применяется, когда вам для какого-то окна нужно установить конкретный курсор, причем желательно на все время существования окна. Перекрываете PreCreateWindow() и регистрируете свой класс окна, изменяя поле lpszClass параметра cs типа CREATESTRUCT:

BOOL CMyView::PreCreateWindow(CREATESTRUCT& cs) {

 cs.lpszClass = AfxRegisterWndClass(

  CS_DBLCLKS | CS_HREDRAW | CS_VREDRAW, //стили окна

  AfxGetApp()->LoadCursor(IDC_MYCURSOR),// курсор

  (HBRUSH)(COLOR_WINDOW + 1));          // цвет фона окна

 return CView::PreCreateWindow(cs)

}

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


Ну вот и все на сегодня. Удачного вам программирования.

©Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №4 от 25/06/2000

Добрый день, уважаемые подписчики!

Мне приходит очень много ваших писем с вопросами, советами, комментариями, предложениями и т.д. Как повелось, самые интересные из них я публикую в рубриках "Обратная связь" и "Вопрос-ответ". Но, как вы наверное сами понимаете, я просто физически не в состоянии отвечать на такое количество вопросов, касающихся программирования. Я отвечаю быстро, когда сразу знаю ответ, но ведь чаще приходится самому сидеть и разбираться, а на это уходит много времени. От этого в первую очередь страдают другие рубрики рассылки – я не успеваю подготовить хороший материал для вас (кстати, я как раз хочу сделать несколько новых рубрик… но пусть лучше это будет сюрприз). Моя задача как автора рассылки состоит в том, чтобы готовить и публиковать интересную информацию по обозначенной тематике. Я же в последнее время больше сам занимаюсь  программированием. Для меня, это, конечно, полезно ;) но вот как насчет вас? На многие вопросы я уже ответил, хотя они не появятся в рассылке, т.к. довольно узко направлены и вряд ли интересны для "широкой общественности". Ответы на другие или слишком обширны и тянут на тему отдельного выпуска, или попросту элементарны.

Решив, что так дальше дело все-таки не пойдет, я придумал новую схему. Мне пришло несколько писем с предложениями помощи от программистов, выписывающих рассылку (огромное спасибо им!), так что теперь лишь на некоторые (самые интересные ;) вопросы я буду отвечать лично (в рубрике "Вопрос-ответ"), а другие просто опубликую отдельно.  В дальнейшем эти вопросы (вкратце) уже вместе с ответами на них появятся в рубрике "Вопрос-ответ" (мне, кстати, предлагали расширить эту рубрику – вот хороший повод). Я надеюсь, наше с вами мнение совпадет и вы тоже посчитаете, что так будет лучше. Еще я очень полагаюсь на ваше сотрудничество – если знаете ответ на вопрос, не поленитесь и напишите! Человек будет вам благодарен, да и не только он, а все читатели, которые узнают что-то новое. А я лично преобладающую свою роль программиста-консультанта сменю на роль ведущего рассылки.

С другой стороны, я ни в коем случае не хочу рассылку превращать в тривиальную дискуссионную группу. Будет несколько новых рубрик! Поэтому количество вопросов, рассматриваемых в выпуске, будет  ограничиваться (в среднем) двумя-тремя вопросами в рубрике "Вопрос-ответ" плюс два-три вопроса, ожидающие ответа. 

Кстати, могу дать очень хороший совет для тех, кто отчаялся найти решение своей проблемы: попробуйте, действительно, задать вопрос в дискуссионной группе, например на news.microsoft.com, в microsoft.public.ru.vc или microsoft.public.russian.programming, а если знаете английский, лучше в одну из многочисленных microsoft.public.vc.* Там отвечают действительно быстро, сам не раз прибегал к этому! И не забудьте порекомендовать подписаться на рассылку :)

Очень многие спрашивают, где можно прочитать предыдущие выпуски рассылки. Отвечу лучше здесь: смотрите на http://subscribe.ru/archive/comp.prog.visualc/


Да, и еще. Выпуски, скорее всего, станут выходить чаще, до 3-4 раз в неделю, иначе размер каждого заметно увеличится. А я сам знаю, как неприятно забирать 30-40 Кб письма, когда постоянно рвется связь (да простят меня читатели с хорошей связью;)  В каждом выпуске помимо обсуждений и вопросов я постараюсь публиковать что-то  интересное. Have fun.

ОБРАТНАЯ СВЯЗЬ

По поводу вопроса смены курсора в MFC-приложении (выпуск No.3) пришло несколько дополнений и замечаний (некоторые несущественные моменты я опустил, вместо них поставил знак "[…]", свои комментарии в теле письма я также привожу в квадратных скобках):

Подобно третьему случаю, но не только в PreCreateWindow().

В тот момент, когда хотим поменять курсор (для всего приложения) проделываем следующие действия:

::SetClassLong(theApp.m_pMainWnd->m_hWnd, GCL_HCURSOR, ::LoadCursor(theApp.m_hInstance, MAKEINTRESOURCE(IDC_MY_CURSOR)));

Немного длинная строчка кода :)) […]

Как обычно встречается такая проблема: theApp, хоть и объявлена глобально (объявляется если проект создается стандартным Wizard-ом), не видна в других файлах проекта. Чтобы обойти это просто в файле объявления класса вашего приложения (производного от CWinApp) сразу после объявления класса добавьте следующую строчку:

extern CMyApp theApp;

где CMyApp – имя класса вашего приложения.

Andrew Gromyko

Замечу, что theApp так объявлять необязательно, так как многие, и я в том числе, пользуются вместо этого стандартными функциями MFC AfxGetApp() и AfxGetMainWnd(), которые возвращают указатель на объект-приложение и главное окно соответственно. 

Вот еще одно письмо на эту тему:

Проблема смены курсора меня настигла еще на раннем этапе моего программистского становления. Поэтому хочу предложить тот вариант, который является по-моему наиболее адекватно подходящим с точки зрения скорости и идеологии Win32 API. Способ три конечно хорош и его можно расширить на все время существования окна. Вот как происходит вызов в классе окна:

::SetClassLong(m_hWnd,GCL_HCURSOR, (long)AfxGetApp()->LoadCursor(IDC_MY_CURSOR));

При этом курсор меняется перманентно, т.е. например при вызове SetCursor() вид курсора меняется при начале движения мыши. А так меняется просто класс окна. Работает быстро и надежно. […]

Alex (seaside@i.com.ua)

Спасибо Андрею и Алексу за это дополнение, теперь мы с вами знаем четыре способа изменить курсор;).  Должен признаться, в предыдущем выпуске я допустил оплошность , ляпнув что первый параметр у AfxRegisterWndClass() можно заменить на cs.style, причем, как назло, понял свою ошибку как раз в тот момент, когда отправлял рассылку "в эфир". Мне не преминули на эту ошибку указать, и я очень рад этому. Пожалуйста, будьте бдительны!!! Я тоже человек! Подробности читайте ниже…

Спасибо Вам за создание действительно нужной рассылки. [Мерси за комплимент ;) – AJ]

Я не так давно начал использовать MFC, и информация, ответы на вопросы мне очень пригодятся. Интересно, что уже в первом прочитанном мной выпуске обсуждался вопрос о курсоре, решение которого я буквально только что искал сам. Поэтому я решил написать этот отзыв в виде нескольких замечаний. На всякий случай оговорю, что все ниже написанное не более чем мое humble opinion :-))

1) Мне не кажется, что описанный Вами универсальный способ изменения курсора нерационален. Не этот обработчик, так CWnd::OnSetCursor() все равно вызывается при каждом движении мыши. Поэтому разнице в скорости практически неоткуда взяться. Хотя, LoadCursor() действительно лучше вызвать один раз (когда этот курсор впервые устанавливается), сохранить дескриптор нового курсора, который и передавать системной функции SetCursor() в обработчике. Мне кажется, это будет по сути то же самое, что делается при обработке события WM_SETCURSOR по умолчанию.

2) О "песочных часах". Если операция, на время которой высвечиваются часики, относительно невелика по времени, и при ее выполнении приложение может не реагировать на другие события, проще всего выделить блок обработки и определить в этом блоке локальный объект CWaitCursor. Все необходимые операции по установке и удалению курсора будут сделаны конструктором и деструктором этого объекта. Именно так, например, в MFC реализованы часики при открытии и сохранении документа. Если же во время операции система реагирует на другие события, то удобнее применять Begin/Restore/EndWaitCursor() [Итак, способов уже пять! – AJ]

3) Вы показываете пример с переопределением precreatewindow(), в котором регистрируется новый класс окна, и в конце пишете: "В качестве первого параметра для AfxRegisterWndClass() можно указать "cs.style", чтобы установить стиль окна по умолчанию." По-моему, это некорректно. Ведь cs.style есть комбинация стилей для окна , а не для класса окна , что требуется при регистрации класса. [Виновен, Ваша честь! – AJ]  Мне пришлось столкнуться с этой проблемой, когда я хотел для своего класса CMyView добавить стиль CS_OWNDC, не меняя ничего больше. Дело в том, что при самом первом вызове CMyView::PreCreateWindow() класс окна просмотра еще не существует, так как он регистрируется в CView::PreCreateWindow(). Поэтому пришлось вызывать родительскую функцию дважды. Вот мое решение, которое, быть может, будет кому-то полезно: 

//h-файл

class CMyView :public CView {

public:

 virtual BOOL PreCreateWindow(CREATESTRUCT& cs);

protected:

 static LPCTSTR lpszViewClassName;

}


//cpp-файл

LPCTSTR CMyView::lpszViewClassName = NULL;

BOOL CMyView::PreCreateWindow(CREATESTRUCT& cs) {

 if (lpszViewClassName == NULL) {

  CView::PreCreateWindow(cs);

  WNDCLASS wc;

  //пытаемся получить информацию о классе

  //если не удается, выходим с ошибкой

  if (!::GetClassInfo(AfxGetInstanceHandle(), cs.lpszClass, &wc)) return FALSE;

  // теперь изменяем в wc все, что нужно

  // например, стиль класса

  wc.style |= CS_OWNDC;

  // регистрируем класс

  lpszViewClassName = AfxRegisterWndClass(wc.style, wc.hCursor, wc.hbrBackground, wc.hIcon);

 }

 // изменяем класс окна на созданный нами:

 cs.lpszClass = lpszViewClassName;

 return CView::PreCreateWindow(cs);

}

[Я немножко подправил код и добавил комментарии. Надеюсь, автор на меня не обидится – AJ]

Есть у меня и вопросы, ответы на которые, возможно, будут интересны не только мне.

Q1) В приложении есть операция, которая требует, скажем, больше пяти минут времени, причем по некоторым причинам дальнейшее выполнение не может быть продолжено до завершения этой операции. Хотелось бы, чтобы при этом окно приложения нормально обновлялось, могло быть свернуто-развернуто и т.п. Я нашел некоторое решение, но оно требует создания второго цикла обработки сообщений и потому мне не очень нравится, хотелось бы сделать более естественно.

Q2) Можно ли переопределенный обработчик событий сделать подставляемым (inline)?

Куканов Алексей (as_katos@mail.ru)

Очень хорошее, обстоятельное письмо. Хотя оно и содержит вопросы, я все же решил поместить его в "обратную связь", т.к. по большей части относится к теме, ну а разбивать письмо на две части – это было бы варварство. Если кто-нибудь знает ответы на заданные вопросы – очень прошу поделиться ! Вопросы действительно интересные.

Если у вас есть еще какие-либо комментарии на тему смены курсора мыши, пишите лучше сейчас. После следующего выпуска тема будет считаться закрытой.

ВОПРОС – ОТВЕТ

Вопросы прислал IvanPouzyrevsky. И хотя у некоторых из вас они могут вызвать улыбку, я решил опубликовать их в рассылке вместо личного ответа, т.к. все-таки довольно большое число начинающих программистов на VC далеко не сразу понимает, как работать с диалогами в концепции MFC. 

Q. Создаю кнопку About. В MFC Class Wizard создаю функцию: IDS_ABOUT->BN_CLICKED. А какой код на открытие окна About?

A. Чтобы вызвать модальный (т.е. не разрешающий переключаться куда-то еще в приложении, пока  пользователь не закрыл его) диалог, следует воспользоваться ф-цией DoModal(): 

CAboutDlg aboutDlg;

aboutDlg.DoModal();

AppWizard генерирует такой код сам на команду ID_APP_ABOUT. Так что проще всего, если вы при создании приложения попросили AppWizard создать окно About, назначить Вашей кнопке идентификатор ID_APP_ABOUT. Тогда больше ничего делать не надо.

А вообще, таким образом можно вызвать не только диалоговое окно About, но и любое другое. Кому не совсем ясно, как обеспечить обмен данными с диалогом, присылайте заявки . В случае наличия интереса это станет одной из следующих тем выпуска. 

Господа опытные программисты, прошу не тратить силы на ворчание – я не могу угодить всем! Для вас тоже будет кое-что интересное.

Q. У меня в программе при написании слова выполняется функция. Например:

if (UpperValue==CALCULATOR) {

 system("calc.exe");

 m_TestEdit="";

 UpdateData(FALSE);

}

Но тут вопрос: как пользователю без изменения кода добавлять в базу данных слова?

Например диал. окно

Слово=

Файл Запуска=

И как указывать путь к файлу, а то при system("d:\unrealtournament\system\unrealtournament.exe") пишет, что файл не найден?

A. Попробуйте сделать два массива (или списка) CString – один для слов, другой для файлов. Добавляйте в массивы данные по мере ввода их пользователем. При запуске вызывайте нужный файл. Это можно более эффективно сделать с использованием ассоциативного списка (СMap), но сейчас, пожалуй, лучше не забивайте этим голову.

В C++ в строках символ "\" воспринимается как управляющий, чтобы представлять такие вещи, как "\n" – Enter, "\b"– звонок, "\0" – "косой ноль" и др. В частности, управляющая последовательность "\\" сама представляет символ "\", поэтому  в строке его надо удвоить,  а т.к. используются длинные имена, то лучше еще заключить строку в дополнительные кавычки с помощью управляющей посл-ти  \"  (хотя у меня работало и без них):

system("\"D:\\UnrealTournament\\System\\unrealtournament.exe\"");

Да, надо сказать, уважаемый Ivan, что мне дико нравится файл, который Вы запускаете ;)

В ПОИСКАХ ИСТИНЫ

Ну вот, как я и обещал – новая рубрика. Ваши вопросы, на которые я надеюсь от вас же получить ответы. Ну, поехали: 

Q. При вылизывании проекта под MS Visual C++ 5.0 была произведена замена операции заполнения служебных переменных данными из файла на диске на операцию заполнения из строковых ресурсов проекта (файл .rc). Используется ф-ция LoadString() MFC класса CString с использованием в качестве аргумента ф-ции числового идентификатора ресурса (передается не IDS_XXXX, а его числовое значение). Файл "resource.h" в необходимые файлы включен. Под VC++ 6.0 – картина аналогичная :(. Компиляция проекта при этом происходит без ошибок и предупреждений. При выполнении проекта в Debug-версии на этапе выполнения указанной выше ф-ции возникает "Debug Assertion Failed" в файле afxwin1.inl на строке 22. Этот блок из себя представляет следующее:

_AFX_WININLINE HINSTANCE AFXAPI AfxGetResourceHandle() {

 ASSERT(afxCurrentResourceHandle != NULL);  //строка 22

 return afxCurrentResourceHandle;

}

При нажатии на клавишу "Пропустить" программа идет дальше и вываливается на следующей операции загрузки строки с теми же симптомами и так до тех пор, пока не будут загружены все строки. После этого выполнение программы продолжается в нормальном режиме и все остальное работает как надо (строки все-таки загружаются!). В Release-версии программа пролетает это место без спотыканий.

Ясно, что можно не обращать на это внимание и сделать условную компиляцию, но дело в принципе! Не могу разобраться в чем тут закавыка.

Евгений

По-моему, вопрос несложный, и имей я лишнее время – разобрался бы сам. Что-то тут с инициализацией, попытка использования раньше времени (как мне кажется)… Но я рассчитываю на тех, кто, прочитав это, воскликнет "ну это ж элементарно!" и сразу начнет писать ответ;) 

Те, кто задал вопрос, но пока его не увидел в рассылке и не получил личного ответа – не отчаивайтесь, ждите новых выпусков.

АНОНС

Читайте в следующих выпусках рассылки:

• Что дядя Билли нам готовит, или Visual Studio Next Generation

• WinAPI: не запутайтесь в типах


Ну вот, видите какой большой получился выпуск, хотя в нем, фактически, не было ничего кроме ваших писем. Думаю, это служит доказательством целесообразности нового режима выхода рассылки. Не бойтесь, что рассылка станет просто большой конференцией – я постараюсь этого не допустить! ;) Все хорошо в меру. Все ваши замечания и предложения с благодарностью принимаются.

До новых встреч. Всего хорошего!

©Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №5 от 28/06/2000

Приветствую!

Итак, рассылка снова с вами, уважаемые подписчики, и вы видите сейчас уже пятый выпуск. Сегодня мы поговорим о типах данных и рассмотрим ваши вопросы и ответы.

WINAPI

WinAPI – это одна из обещанных мной новых рубрик. Как следует из ее названия, в ней мы будем рассматривать вопросы, посвященные Windows API.

WinAPI: НЕ ЗАПУТАЙТЕСЬ В ТИПАХ 

Вы когда-нибудь попадали на страницу Win32 Simple Data Types в Help? В переводе с английского simple означает "простой", т.е. Microsoft хочет сказать, что это "простые типы". В C++ простыми типами были int, double и другие. При программировании для Windows эти типы никуда не деваются, но появляется очень много новых. Они, конечно, не входят в стандарт C++ и не являются его ключевыми словами (ведь на C++ программируют не только под Windows), но любой Windows-программист должен эти типы хорошо знать. И краткого описания типа, приведенного на вышеуказанной странице MSDN, часто бывает недостаточно, так что иногда приходится лезть в исходники и смотреть, что же из себя представляет тип на самом деле. Я вам предлагаю обзор самых основных и важных типов.

Типы Win32 гораздо легче понять, если знать некоторые соглашения. Например, названия типов, по своей природе являющихся указателями, начинается с префикса P или LP. Кстати, LP означает Long Pointer (дальний указатель) и остался в наследие от Windows 3.1, когда указатели еще делились на ближние (содержащие только смещение в сегменте) и дальние (содержащие как сегмент, так и смещение). Префикс H означает HANDLE — это типы, используемые для описания различных объектов, а префикс U —  что тип беззнаковый.

С типами INT, UINT, LONG, ULONG, WORD, DWORD, VOID, SHORT, USHORT, CHAR, FLOAT.  BYTE, BOOL(BOOLEAN), у вас не должно быть никаких проблем, и было бы глупо их тут расписывать. Эти типы дублируют встроенные типы C++, и единственное, на что здесь нужно обращать пристальное внимание — это размер типа. Эти типы рекомендуется использовать вместо встроенных в C++ для улучшения переносимости приложения, т.к. в разных системах встроенные типы имеют различные размеры.

Очень интересен тип WINAPI. По-хорошему это все-таки не тип. Если вы посмотрите в файл windef.h, то увидите следующую строку: "#define WINAPI __stdcall". __stdcall – это ключевое слово языка C++, оно, в частности,  влияет на механизм передачи параметров функции. Суть механизма, определяемого __stdcall состоит в том, что  1) аргументы передаются справа налево; 2) аргументы из стека выбирает вызываемая функция; 3) аргументы передаются по значению (by value), а не по ссылке (by reference), т.е. функции передаются копии переменных; 4) определяет соглашение по декорированию имени функции, т.е. включению в имя дополнительной информации, используемой компоновщиком; 5) регистр символов не изменяется.

То есть оказалось, что WINAPI – это не вовсе тип, а указание о том, что функция использует соглашение __stdcall. Кстати, имейте в виду, что описатель PASCAL и __pascal — это то же самое, что и WINAPI. Но этот описатель является устаревшим, оставлен лишь для совместимости, и Microsoft рекомендует повсеместно использовать вместо него WINAPI.

Использование соглашения __сdecl вместо __stdcall иногда оправданно, но приводит к увеличению размера исполняемого модуля из-за того, что имя функции декорируется в этих соглашениях по-разному.

…продолжение следует…   

ВОПРОС – ОТВЕТ

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

Q. В приложении есть операция, которая требует, скажем, больше пяти минут времени, причем по некоторым причинам дальнейшее выполнение не может быть продолжено до завершения этой операции. Хотелось бы, чтобы при этом окно приложения нормально обновлялось, могло быть свернуто-развернуто и т.п.

Куканов Алексей (as_katos@mail.ru)

A1. А в чем проблема? Внутри, допустим цикла иногда добавляется цикл:

for( ; GetMessage(lpMsg, hWnd, 0, 0); DispatchMessage(lpmsg));

И для красоты на все "запрещенные" действия ставим флаг (который взводим/гасим по необходимости). Вот и весь велосипед.

Сергей Бойко

Мне вот только не совсем понятно, что значит "иногда добавляется"… Время от времени добавляется, что ли? ;)

A2. Я решил написать ответ на вопрос Куканова Алексея, о корректной прорисовке окна во время какого-то процесса. С MFC это решается элементарно. Пусть есть функция   LRESULT Calculation (LPVOID pParam); Не обращайте внимание на параметры объясню позже. Так вот вместо того чтобы в теле какого-то обработчика запускать эту функцию

CMyDlg::OnButtonClick() {

 Calculation();

}

и ждать когда она закончит лучше сделать так 

CMyDlg::OnButtonClick() {

 AfxBeginThread(Calculation, (LPVOID)m_hWnd,THREAD_PRIORITY_LOWEST);

}

По сути MFC запускает параллельную нить, которая никак не влияет на перерисовку всего остального. Обычно можно в качестве  pParam передать HWND окна. Потому как узнать когда закончится процесс можно только при помощи сообщений. Например в теле Calculation  

::SendMessage((HWND)pParam, WM_STOP, 0, 0);

А кто хочет узнать побольше читайте MSDN – "Worker threads".

Alex (seaside@i.com.ua)

Кстати, Alex пишет нам уже второй раз, хочу поблагодарить его за активность.

В принципе такой же, но более обстоятельный ответ на этот вопрос  пришел чуть позже:

A3. Самый оптимальный по-моему способ: Это запустить worker thread – второй поток (если пока только один :)) ) апликации. В качестве параметра передать туда структуру с необходимыми данными, а можно и ничего не передавать. Если все данные хранятся в наследнике CWinApp (дальше – CMyApp) , то получить доступ к объекту апликации можно с помощью функции AfxGetApp(). Единственное замечание по передаче данных из одного потока в другой заключается в том, что надо доступаться ТОЛЬКО к мемберам класса – нельзя вызывать функции класса из другого потока (вернее, можно, если они не изменяют данных класса или не обращаются к оконным функциям класса (относиться к наследникам CWnd)). В итоге имеем схему: 

1. Создается worker thread (поток одной функции, при ее завершении завершается и поток). В качестве параметра функции AfxBeginThread передается указатель на необходимые данные.

2. В основном потоке создается собственное сообщение, сигнализирующее о завершении потока. Оно будет брошено рабочим потоком перед своим завершением с помощью PostMessage (при работе с потоками я предпочитаю PostMessage для обмена такого рода сообщениями, ведь SendMessage ждет завершения работы обработчика события, что часто просто не нужно).

3. Запущенный поток выполняет всю черновую работу, в то время как основной поток апликации занимается важными делами, а именно – ничего не делает, знай крутит себе цикл обработки сообщений и не жужжит.

4. По завершении работы, worker thread посылает основному потоку мессагу, мол я закончил, выкладывает результаты так, чтобы основной знал где они (как это сделать – миллионы способов :)), в частности, передать в завершающем сообщении указатель на данные результата. )

Примерный код таков.

UINT WorkerThreadFunction(WPARAM, LPARAM lpData) {

 // тутачки работаем с lpData и выполняем

 // всю необходимую работу

 // результат запихиваем в память,

 // а адрес на нее – в lpResult

 AfxGetMainWnd()->PostMessage(IID_WORKER_THREAD_END, 0, lpResult);

 // возвращаем код успеха (а вообще это на ваш вкус)

 return 0;

}


void CMyApp::OnStartExecution() {

 // заполняем lpData нужными данными, и вызываем ..

 CWinThread *pThread = AfxBeginThread(WorkerThreadFunction, lpData);

 if (!pThread) {

  // Не смогли запустить поток.

  // Правда обычно этот код не выполняется :)).

  // Я до сих пор не знаю ситуации, когда поток

  // может не запуститься, кроме low memory.

  AfxMessageBox(_T("Can't start thread."));

 }

}


LRESULT CMyApp::OnWorkerThreadEnd(WPARAM wParam, LPARAM lpResult) {

 // тутачки обрабатываем завершение расчетов.

}

Замечания:

1. Объявлять обработчик сообщения ID_WORKER_THREAD_END надо через ON_MESSAGE макрос 

2. Потоков запускать можно сколько душе угодно (если хватает памяти :)) ).

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

Oleg Tselobyonok, Applied systems, Ltd.

A4. Самым естественным способом решения задачи n1 является создание дополнительного потока в процессе, который собственно и будет выполнять ту самую длительную операцию. С другой стороны – основной поток должен ожидать завершения операции. Для этого в Win32 существует функция WaitForSingleObject, одним из параметров которой задается описатель ожидаемого потока. Но в этом случае ждущий поток не может обрабатывать сообщения своего окна, так как ему система перестает выделять процессорное время. Здесь можно придумать много разных способов: во-первых, совсем можно обойтись и без функции WaitForSingleObject, создав глобальную переменную, которая при запуске потока инициализируется в false, а по его завершении – в true (или наоборот); можно, кроме того, используя функцию WaitForSingleObject, задавать ей вместо INFINITE лимит времени, по истечении которого будет возобновлено исполнение потока – вся байда проводится в цикле, при каждой итерации которого производится обработка сообщений окна;

Епрст

Ну вот, на вопрос получены очень хорошие ответы. А о  многозадачности мы еще обязательно поговорим в одном из выпусков. Главное понять – это не так сложно , как кажется! ;)

Q. Можно ли переопределенный обработчик событий сделать подставляемым (inline)? (автор тот же)

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

A. Естественно, нельзя. Дело в том, что инлайновые функции не имеют собственного указателя – они похожи на макросы в этом смысле. А диспетчеру обработчиков (если так можно выразиться) надо давать адрес обработчика.

Q. Вопрос про ресурсные строки: "…при нажатии на клавишу "Пропустить" программа идет дальше и вываливается на следующей операции загрузки строки с теми же симптомами и так до тех пор, пока не будут загружены все строки. После этого выполнение программы продолжается в нормальном режиме и все остальное работает как надо (строки все-таки загружаются!). В Release-версии программа пролетает это место без спотыканий."

Евгений

(Полностью  вопрос Евгения см. в предыдущем выпуске, который можно найти по адресу http://subscribe.ru/archive/comp.prog.visualc)

A1. Скорее всего, приложение преобразовано из обычного в MFC и преобразовано некорректно. Нельзя использовать ресурсные функции CString в не-MFC приложении, потому что они требуют специальной инициализации. Другие функции будут работать, а эти нет. Инициализация всех внутренних переменных происходит при инициализации приложения в вызовах AfxWinInit() и прочих служебных функций в AfxWinMain(). Можно посоветовать или сгенерировать приложение заново или использовать код вида:

CString s;

::LoadString(g_hInstance, 12345, s.GetBuffer(256), 256);

s.ReleaseBuffer();

Дмитрий Дулепов, MCSE

A2. По вопросу о CString::LoadString: Скорее всего, эта функция вызывается до статической инициализации библиотеки MFC. Например, это может произойти в конструкторе объекта, объявленного статическим. Все тот же пресловутый theApp…. :-) Микрософт рекомендует переносить все действия по инициализации в InitInstance, собственно для чего эта ф-ция и предназначена.

Sergey Emantayev

A3. А по поводу вопроса в рубрике "В поисках истины" – похоже, что зачитка данных идет в конструкторе CMyApp, а не в InitInstance. Предположение насчет некорректной инициализации похоже правильно.

Oleg Tselobyonok, Applied systems, Ltd.

Огромное всем, кто не поленился  написать ответ, особенно  Олегу – он у нас сегодня рекордсмен!

Ну вот, кажется на все вопросы получены ответы. Полная идиллия… только вот уже поступили новые вопросы… ;)

В ПОИСКАХ ИСТИНЫ

Q. Просто кульно, что ты взялся за эту рассылку, а то, как ты и говорил, в инете нет рассылок по MSVC++. Сам я за ним сижу уже два года, и всё более углубляясь внутрь, возникают всё новые вопросы ;) Но я ещё маленький ;) Хочу задать тебе вопрос: как делать окна нестандартной формы? Например, круг (как у диска Компьютерры – там окно обычное, но с помощью прозрачности виден только круг, так?)

eFi

Если никто не ответит на этот вопрос, я отвечу сам в следующем выпуске. Но от этого может пострадать тема выпуска – я все не успеваю, а по этому вопросу мне надо будет еще кое-что уточнить – поэтому кто знает или делал такие окна, напишите! 

Должен констатировать, что проблема курсоров не закрыта – пришел еще один вопрос:

Q. Хочу поблагодарить за прекрасную рассылку, надеюсь почерпнуть много интересной и полезной информации. Хочу задать несколько вопросов:

1.Что касается курсоров – как все-таки загружать 256-цветный курсор в приложении? Т.е. проблема в том что в редакторе ресурсов можно сделать либо только черно-белый курсов, либо еще и цветной, но при этом LoadCursor загружет только ч.б. Скорее всего ларчик просто открывается, но все же?

2. Еще вопрос, скорее всего тоже очень популярный. Версия Debug работает без проблем, а при запуске версии Release появляется сообщение о недопустимой операции. Хотелось бы знать в чем проблема и пути ее решения.

George V. Samodumov

А вот по второму вопросу хочу порекомендовать посмотреть ответ на вопрос Евгения – чуть выше. Как правило, отказ работать debug-версии значит, что все-таки что-то у вас не так, и для вас же  будет лучше выяснить, в чем именно проблема. Это может быть связано, например, с инициализацией, с памятью и еще с уймой других вещей.

Q. Спасибо за рассылку – наконец-то свершилось! А то по VB их уже несколько, а по VC++ не было до недавнего времени ни одной. У меня есть вопрос по обработке события WM_KEYUP. Играя с диалогом, обнаружил, что он сам никак не реагирует на нажатия клавы. Как решение, использовал следующий способ: для каждого типа контрола делал свой класс, который реагирует на WM_KEYUP, и в обработчике этого события пересылал сообщение окну диалога. Например, для кнопок создал класс CMyButton, наследуемый от CButton, и в функции CMyButton::OnKeyDown() пересылаю сообщение родительскому окну как GetParent()->SendMessage(…). То же самое для других типов контролов по аналогии.

Но такой способ отдаёт некоторой горбатостью, может быть существует какое-то более элегантное решение?

Роман Коновалов

Жду ваших писем с ответами!

Пока все.

Всего вам доброго!

©Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №6 от 02/07/2000

Здравствуйте, уважаемые подписчики!

НОВОСТИ
Вышел Service Pack 4

Фирма Microsoft  недавно выпустила очередной, четвертый пакет исправлений для Visual Studio 6.0 – Service Pack 4. Он устраняет некоторые ошибки в продуктах VS, а также производит ряд  обновлений.

В Visual C++ 6 исправления касаются STL, MFC, CRT, IDE, самого компилятора, отладчика, и многих других частей, т.е. практически всего.

Следует заметить, что среди исправленных ошибок встречаются действительно критические, которые могут помешать работе. Например, частое использование realloc на маленьких блоках памяти вызывало memory access violation (конфликт при попытке доступа к памяти), а DllMain выбрасывала unhandled exception, если в течение DLL_THREAD_DETACH возникала нехватка памяти. MFC AppWizard неправильно связывал данные с программой при использовании OLE DB ODBC provider и Access.

Помимо исправления ошибок, в SP4 включены все предыдущие Service Pack'и, плюс новые версии таких компонентов, как:

• Microsoft Data Access Objects

• Microsoft HTML Help

• Microsoft Data Access Components (MDAC)

• Microsoft Scripting

• Microsoft OLE Automation

Также внесены исправления, необходимые для новых версий Office, SQL Server и  Windows, включая Internet Explorer.

К сожалению, SP4 не включает самые последние заголовки и библиотеки для Internet Explorer5 или Windows 2000. Их нужно загружать отдельно в виде SDK.

Visual Studio Service Pack 4 занимает около 130Мб и доступен для свободного скачивания на сайте Microsoft по адресу http://msdn.microsoft.com/vstudio/sp/vs6sp4 (13 файлов, приблизительно по 10 Мб каждый).

Имеется возможность обновить только некоторые продукты, например Visual Basic. Для Visual C++, однако,  придется скачивать полную версию. Или подождать, пока она появится на пиратских CD.

ОБРАТНАЯ СВЯЗЬ
Из входящей почты

Публикация "WinAPI: Не запутайтесь в типах", вышедшая в предыдущем выпуске (и которая, кстати, будет продолжена в следующем) вызвала некоторый резонанс из-за допущенных там двух неточностей.

Здравствуйте, Алекс!

Встретил в Вашей рассылке "Программирование на Visual C++" за No.5 следующее утверждение: 

"Кстати, имейте в виду, что описатель PASCAL и pascal – это то же самое, что и WINAPI. Но этот описатель является устаревшим, оставлен лишь для совместимости, и Microsoft рекомендует повсеместно использовать вместо него WINAPI."

Это распространенное мнение, которое вызвано переходом Microsoft с pascal на stdcall при переходе с Win16 на Win32. При этом Microsoft в MSDN утверждает, что: "Use WINAPI where you previously used PASCAL or far pascal." Но это означает всего лишь то, что стандартный способ вызова API функций изменился, а не то, что pascal эквивалентен stdcall. Проиллюстрируем это первоисточниками.

MSDN:

"The stdcall calling convention is used to call Win32 API functions. Argument-passing order Right to left. Argument-passing convention By value, unless a pointer or reference type is passed. Stack-maintenance responsibility Called function pops its own arguments from the stack. "

Borland C++ Builder Help:

"In addition, pascal declares Pascal-style parameter-passing conventions when applied to a function header (parameters pushed left to right; the called function cleans up the stack)."

Справка от Борландовского продукта в последнем случае выбрана потому, что MSDN вообще умалчивает о том, кто такой этот pascal, ограничиваясь тем, что он is now obsolete. Из вышеприведенных выдержек мы можем видеть, что stdcall отличается от pascal порядком передачи параметров. И просто так подменять один способ другим нельзя. Это легко продемонстрировать, попытавшись вызвать функцию с модификатором pascal из Visual Basic. Access Violation Вам гарантирован.

Sergey Shapovalov
Software Security Belarus

Mea culpa. Действительно, иногда не вредно вспоминать, что кроме MSDN существует кое-что еще. Спасибо, Сергей!

Привет

"Использование соглашения сdecl вместо stdcall иногда оправданно, но приводит к увеличению размера>исполняемого модуля из-за того, что имя функции декорируется в этих соглашениях по-разному."

Не понял я этой фразы… cdecl делает больше код потому что надо стек чистить каждый раз после вызова рутины, а не изза decoration. Names decoration влияет только на представление имён до линкера, в выходной код они не включаются.

Причём, cdecl – стандартный тип вызова для C/C++ изза возможности использования varargs, в то время как в stdcall вызове такое невозможно. Как правило, stdcall юзают в dll (в Win32API в том числе) и для присобачивания чужих lib, собранных с использованием этого типа вызова.

Ivan Nevraev

В самом деле, декорирование имени функции тут не причем. Благодарю Ивана за помощь. В дальнейшем буду стараться публиковать только перепроверенные данные. 

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

[…] Чтобы рассылка действительно не превращалась в дискуссионную группу, можно дать еще пару ссылочек. Вы уже упомянули news-группы. Можно посоветовать также еще один, правда англоязычный ресурс: http://codeguru.developer.com. Это один из (если не самый) крупнейших сайтов для разработчиков на C++ и большей своей частью на Visual C++.

Также там есть discussion board: http://codeguru.developer.com/bbs/wt/wwwthreads.pl,   где можно задать любой интересующий вопрос (естественно на английском языке). Обычно ответ приходит довольно быстро. Причем это либо исходный код, либо ссылка на что-либо подобное. Короче очень рекомендую.

Andrew, Gromyko (gao2000@iname.com)

Андрей, кстати, уже не в первый раз пишет. Ссылки хорошие – сам на CodeGuru захожу очень часто. Так что уверен, многим эта информация придется кстати. 

Да, если вы знаете какие-нибудь стоящие внимания ресурсы по VC – присылайте ссылочки!

Большое спасибо за рассылку! Большой ее положительной спирали! ;) (Bill Gates "The Road Ahead") [ Может, "ей"?… – AJ]

Как насчет новости от Microsoft? Я имею в виду http://msdn.microsoft.com/vstudio/nextgen/technology/csharpintro.asp.

C# (pronounced "C sharp"). 

В связи с этим:

а) не переименовать ли рассылку сразу в VisualC# ? :)

б) не объявить ли конкурс на лучшее объяснение значка # в новом названии; какова связь # со словом sharp?

Маленькое пожелание напоследок – не забывать, что "VisualC++" != "MFC"; "VisualC++"> "MFC";

Надеюсь еще не раз побеспокоить вас своими письмами.

С уважением, 

Александр Тумель.

Ну, первое пожелание я уже выполнил – появилась рубрика "Новости". Она, конечно, будет появляться не в каждом выпуске, но самые важные события в мире VisualC++ будут освещаться именно там. 

О VS NextGen я как раз готовлю материал, даже уже был анонс ("Что дядя Билли нам готовит…") – статья выйдет через выпуск, или , в крайнем случае, через два-три.

А вот насчет произношения "C sharp", гадать, увы, не придется ;) Знак "#" в музыке обозначает диез, т.е. повышение звука на полтона (здесь Microsoft, скорее всего, проводит аналогию с операцией инкрементирования "++"). А "диез" по-английски как раз и будет "sharp" (можете посмотреть в словаре). Все-таки 8 лет муз. школы не прошли для меня даром!;) Так что конкурс отменяется.

Про переименование рассылки в Visual C# подумаем, когда a) прочитаем про этот C# –  здесь же;) и  б) Microsoft выпустит продукт под таким названием.

А  по поводу пожелания – так ведь так оно и есть! Рубрика WinAPI на что? А вот ActiveX и СOM  действительно рассылкой не освещаются. Про COM/DCOM кажется, есть отдельная рассылка.


На заданные в прошлом выпуске вопросы пришло очень много ответов, так что я, скорее всего, похожие ответы сгруппирую в один, а потом просто укажу, кто такой ответ прислал. Иначе объем выпуска не выдержит ни один почтовый ящик ;) Постараюсь никого не забыть!

Да, и еще. Ради бога, прошу извинить меня тех, кто написал мне и не получил пока ответа. Писем приходит очень много, и я не могу отвечать всем.

На сегодня пока все. Рубрики "WinAPI" и "Вопрос-Ответ" – в следующем выпуске. 

Будьте здоровы!

©Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №7 от 06/07/2000

Добрый день!

Сегодня я представляю вам обещанное продолжение публикации о типах WinAPI, а также ответы на заданные в 5-ом выпуске вопросы.

WINAPI
WinAPI: НЕ ЗАПУТАЙТЕСЬ В ТИПАХ 
(Продолжение. Начало см. выпуск No.5)

Очень часто вами будет использоваться тип HANDLE — дескриптор, предназначенный для описания различных объектов. На самом деле этот тип представляет собой ни что иное, как указатель на void, т.е. как бы на любой тип. 

Объекты Windows обычно представлены своими дескрипторами. Например, HWND —  дескриптор окна. Что он из себя представляет? Давайте посмотрим:

В файле windef.h можно обнаружить такую строчку:

DECLARE_HANDLE(HWND);

Эта строка при определенной опции STRICT разворачивается в 

struct HWND__ {int unused;};

typedef struct HWND__ *HWNDж

То есть HWND есть указатель на структуру HWND__. Если же опция STRICT не определена, то HWND везде заменяется на HANDLE.

Идентификатор STRICT указывает на необходимость проводить более строгую проверку типов. Как вы уже убедились, без этой опции все HWND, а также описатели других объектов Windows — HPEN, HBITMAP, HFONT, HMENU, HDC и др. будут фактически представлять собой один тип — HANDLE. Если же вы включите определение STRICT, тогда они будут трактоваться как разные типы (благодаря макросу DECLARE_HANDLE), и при их несоответствии компилятор будет выдавать сообщение об ошибке. Использование STRICT рекомендуется для того, чтобы было легче находить возможные ошибки в программе.

В заключение давайте рассмотрим очень часто используемый тип COLORREF. По сути это unsigned long. Этот тип представляет возможность задать цвет набором его RED, GREEN и BLUE составляющих, для этого используйте макрос RGB:

COLORREF color=RGB(0,255,255);

Результат этого выражения – длинное целое число, самый младший байт которого содержит интенсивность красного, второй – зеленого и третий байт – синего. В этом случае color будет содержать голубой цвет. Сам макрос RGB(r,g,b) при обработке препроцессором  расширяется до ((COLORREF)((BYTE)(r) | ((WORD)(g) <<8)) | (((DWORD)(BYTE)(b))<<16))).

ВОПРОС – ОТВЕТ

Q.  …Как делать окна нестандартной формы? Например, круг (как у диска Компьютерры — там окно обычное, но с помощью прозрачности виден только круг, так?)

eFi

A. На этот вопрос пришло довольно много фактически одинаковых ответов, и я сейчас постараюсь объяснить самую суть.

В Windows существует понятие регионов — областей. Каждое окно имеет свою область, которая по умолчанию создается прямоугольной. В WinAPI (и в классе CWnd) существует функция SetWindowRgn(), которая позволяет задать форму этой области. То есть сначала вы создаете область, потом устанавливаете его как форму для окна (это можно сделать, например, в OnInitDialog()). Создать область можно с помощью функций Create…Rgn(). Например, чтобы сделать круглое окно, можно воспользоваться CreateEllipticRgn(). Подробно параметры я описывать не буду – смотрите пример. Замечу только, что регионы можно создавать сложные, составленные из нескольких примитивов. Они образуются путем комбинирования областей (CombineRgn()).

Пример (прислал Sergey Melnikov):

CRect Rect;

GetWindowRect(&Rect);

HRGN hRgn = CreateEllipticRgn(0, 0, Rect.Width(), Rect.Height());

SetWindowRgn(hRgn, TRUE);

А если добавить такой код, получим окно с "прорезью" в виде эллипса:

HRGN hRgn1 = CreateRectRgn(0, 0, Rect.Width(), Rect.Height());

HRGN hRgn2 = CreateEllipticRgn(0, 0, Rect.Width(), Rect.Height());

HRGN hRgn3 = CreateRectRgn(0, 0, Rect.Width(), Rect.Height());

CombineRgn(hRgn3, hRgn1, hRgn2, RGN_DIFF);

SetWindowRgn(hRgn3, TRUE);

Ответ на этот вопрос прислали (в порядке получения): Андрей Колчанов, Ренат Васиков, Ilgar Mashayev, Sergey Skornyakov, LiMar, Sergey Melnikov, Igor Kurilov, Michael Stepanenkov.

Q. …Как загружать 256-цветный курсор в приложении? Т.е. проблема в том что в редакторе ресурсов можно сделать либо только черно-белый курсор, либо еще и цветной, но при этом LoadCursor загружет только ч.б…

George V. Samodumov

A. Ответ на этот вопрос часто сводится к рекомендации воспользоваться LoadImage() вместо LoadCursor(). Вот самый полный и интересный ответ из присланных:

Дело в том, что файл курсора имеет схожий формат с файлом иконки, т.е. в одном файле могут находиться несколько изображений разных форматов, например: 16×16×16, 32×32×256 и т.д. При добавлении нового курсора редактор ресурсов VC автоматически создает курсор формата 32×32×2, который вероятно и грузится первым даже если добавлены еще несколько изображений. Поэтому нужно сделать так, чтобы курсор содержал только одно изображение. В редакторе ресурсов выполняем Insert|Cursor, потом открываем его для редактирования и в появившемся меню Image выбираем "New Device Image", а там "Custom" и задаем параметры изображения, например 48×48×256. Редактируем курсор, а потом переключаемся на монохромное изображение и удаляем его: "Image|Open Device Image –> Monochrome32×32", "Image|Delete Device Image". Теперь мы избавились от монохромного изображения и можем грузить курсор функциями: LoadCursor(), LoadCursorFromFile(), LoadImage():

BOOL CSampleDlg::OnInitDialog() {

 CDialog::OnInitDialog();

 ::SetClassLong(m_hWnd, GCL_HCURSOR, (LONG)(HCURSOR)AfxGetApp()->LoadCursor(IDC_CURSOR1));

 // Грузим анимационный курсор

 (LONG)(HCURSOR)::LoadCursorFromFile("Appstart.ani"));

 return TRUE;

}

Alex Hin

Ответ прислали (в порядке получения): Azanov Max, Dmitri A. Doulepov, Alex Hin, Igor Kurilov.

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


Предлагаю подписаться на дружественную рассылку:

Visual Basic — Трюки и Хитрости, советы и ответы на вопросы

Всего хорошего!

© Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №8 от 08/07/2000

Здравствуйте!

НОВОСТИ
Что дядя Билли нам готовит, или Visual Studio Next Generation

Многие из вас наверняка гадали – а что дальше? Какой он будет, новый Visual C++? Какие планы на этот счет у Microsoft? Ну что ж, сейчас завеса тайны более-менее приоткрылась, и можно уже о чем-то говорить.

Прежде всего  следует заметить, что Visual Studio 7.0 будет больше ориентирована на разработку Web-приложений. Дело в том, что Microsoft недавно представила свою новую платформу .NET (читается "dot net"), предназначенную для еще большей интеграции интернета в операционную систему. Уже следующая ОС Windows, пока известная под кодовым названием Whistler и ожидаемая только к 2001 году, будет основана на этой платформе. Новая версия Visual Studio должна значительно упростить разработку программ для интернета.

На конференции VC-разработчиков фирмой Microsoft были заявлены основные планируемые изменения и улучшения, которые коснутся Visual C++. Итак, стало известно следующее:

1) Планируется ввести унифицированную среду разработчика (IDE) – теперь VC и VB будут одной средой. Хорошо это или плохо, покажет только время. Я не берусь сейчас давать оценку этому нововведению, потому что очень много будет зависеть от того, как именно это будет реализовано. Из плюсов такого подхода следует отметить то, что теперь независимо от того, на каком языке вы собираетесь программировать, вам нужно освоить только одну среду, а если в будущем вам придется воспользоваться другим языком, изучать другую IDE будет уже не нужно. Тем более это актуально, если вы планируете использовать оба языка. 

2) Следующий релиз vs будет включать в себя технологию, называемую "ATL-сервер". Эта технология предложит набор классов-расширений для Active Template Library (ATL) и будет обеспечивать доступ ко всем функциям Internet Information Server (IIS). Microsoft полагает, что это значительно упростит и ускорит процесс создания масштабируемых Web-приложений.

3) Расширение для языка – "attributed programming" – (Я бы перевел как "описательное программирование", программирование за счет свойств). Оно призвано уменьшить объем кода, который программисты должны писать для создания COM+ компонентов.  Свойства инкапсулируют доменные понятия (такие, как Data, COM, Web Services) в простые объявления, которые вставляются прямо в исходный код. Эти объявления предоставляют компилятору Visual C++ всю необходимую контекстную информацию, что раньше требовало сотни строк кода. 

Следует также отметить, что все новые продукты Microsoft, спроектированные для платформы .NET, будут иметь расширенную поддержку XML. 

И, наконец, самое интересное. Microsoft анонсирует новый язык программирования, который будет называться "C#" (читается как "C  sharp". Мы, кстати, уже обсуждали связь знака "#" со словом sharp в выпуске №6).

C# — это новый объектно-ориентированный язык программирования, который позволит разработчикам быстро создавать широкий диапазон приложений для новой платформы .NET.

Новый язык будет конкурировать скорее с Java, чем с C++. Естественно, Microsoft совершенно не устраивает Java, прежде всего потому, что Java – это детище Sun Microsystems. Еще одна причина создать альтернативу Java – патологически малая производительность последнего, большей частью обусловленная его мультиплатформенностью. Как и Java, новый язык будет основан на C++. В C# будет встроена поддержка COM и XML, причем последний будет стандартным форматом структурированных данных для посылки через интернет.

В C# любой объект – это COM-объект. Разработчикам больше не придется явно реализовывать IUnknown и другие COM-интерфейсы. Программы на C# также смогут легко использовать любой COM-объект, независимо от того, на каком языке он был написан. 

Новый язык спроектирован таким образом, чтобы исключить частые ошибки программистов. Например, "сборка мусора" позволит разрешить главную проблему C++ – неправильно используемые указатели; переменные в C# будут инициализироваться автоматически, а cам язык будет обладать повышенной типовой безопасностью.

Описание языка в формате MS Word (на английском языке, естественно) все интересующиеся могут скачать отсюда.

ВОПРОС – ОТВЕТ

Прошу прощения у Александра Панченко, который также прислал ответ на вопрос о 256-цветных курсорах, но не был мной упомянут в прошлом выпуске, и у Ивана Невраева (Ivan Nevraev), который также написал ответ на вопрос о нестандартной форме окна.

Сейчас рассмотрим ответы на два оставшихся вопроса из выпуска №5:

Q. Версия Debug работает без проблем, а при запуске версии Release появляется сообщение о недопустимой операции. Хотелось бы знать в чем проблема и пути ее решения.

George V. Samodumov

A1. VC++ порой глючит и не делает перекомпиляцию файлов, либо не линкует исправленные файлы при incremental link-е. Если выполнить build-all то иногда можно обнаружить что-нибудь вроде синтаксической ошибки, хотя до этого компиляция проходила без проблем.

Igor Kurilov

A2. Это явно что-то с указателями. Причём как при их использовании, так и при повторном освобождении. В debug-версии MFC помечают память, на которую указывают освобождаемые указатели символами 0xСD. Соответственно, в отладчике Вы сразу поймёте, что что-то не так, если увидите такое значение. При этом может невозникать исключений. Если работать под WinNT они возникнут почти наверняка, а вот Win9x ведёт себя в этом отношении проще: никаких исключений не возбуждается. При использовании release-версии объекты инициализируются по-умолчанию в NULL. Попытка использования такого указателя вызовет исключение как в WinNT, так и в Win9x. Всё это проверено не раз на практике…

Dmitri A. Doulepov, MCSE

A3. […] При проблеме с release-версией рекомендую следующее: 

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

2. После локализации ошибки проанализировать соответствие ассемблерного кода (Ctrl+F7 в MSVC) исходному коду.

Типичные причины подобных ошибок:

1. Оптимизатор дооптимизировался до маразма

2. В отладочном режиме свободные области памяти заполняются определенным значением. В релизе этого не происходит. Выплывают огрехи с отсутствием инициализации переменных 

3. Время выполнения участков кода становится другим. Могут всплыть ошибки, связанные с некачественной синхронизацией различных ниток и т.п.[…]

Nikita Zeemin

A4.  Могу сказать только одно – ЕЩЕ РАЗ проверьте свой код. У меня такие ситуации были на заре моей практики. Это было ужасно… Часы проведенные в Debuge – куча MessageBox в Release – и ничего – ошибка не исчезала. А было на самом деле вот что. Под Debug компайлер напихивает кучу разных вещей которых нет в Release версии – как например обнуление указателей, проверку на выделение памяти и т.д. Я приведу здесь один глюк который реально у меня встретился и привел к вышеупомянутым последствиям. Был какой-то класс и какая структура данных

struct MyStruct  { …  };

class MyClass {

 MyStruct* pStruct;

 …

}

И мне надо было в конструкторе класса выделить память под pStruct – но я этого НЕ СДЕЛАЛ. И было вот что под Debug  обращение типа pStruct[0] не вызывало никаких осложнений – а под Release вылетало тут же. Поэтому следите за  УКАЗАТЕЛЯМИ. Это самая кульная вещь в С/C++ но и самая геморройная (может быть грубовато – но это так)

Alexey Merkulov

A5. По поводу скрытых ошибок в программах, не ленитесь в критических местах использовать TRACE0, а перед использованием указателей проверяйте содержимое 

HRESULT AnyMethod(MyClass* pPointer) {

 if(pPointer != NULL) {

  // и только здесь начинайте с ним работать!

 } else {

  TRACE0("Получен пустой указатель");

  return S_FALSE;

 }

}

Alexei A. Zanine, System Engineer

Q. У меня есть вопрос по обработке события WM_KEYUP. Играя с диалогом, обнаружил, что он сам никак не реагирует на нажатия клавы. Как решение, использовал следующий способ: для каждого типа контрола делал свой класс, который реагирует на WM_KEYUP, и в обработчике этого события пересылал сообщение окну диалога. […] Но такой способ отдаeт некоторой горбатостью, может быть существует какое-то более элегантное решение?

Роман Коновалов

A. На этот вопрос пришли похожие ответы, суть которых сводится к совету перекрыть функцию PreTraslateMessage() и все нажатия обрабатывать там. Такие ответы прислали Igor Sorokin , Дмитрий Елюсеев и Alex Hin.

Dmitri A. Doulepov советует также обратить внимание на функцию IsDialogMessage( ). 

Я поясню – эта функция вызывается из CWnd::PreTranslateMessage( ) для того, чтобы определить, предназначено ли сообщение для диалога. Если да, то она обрабатывает это сообщение, проверяет клавиатурные сообщения и конвертирует их в команды диалогового окна (например, TAB преобразуется в команду перехода к следующему элементу управления.) 

Пример:

BOOL CAboutDlg::PreTranslateMessage(MSG* pMsg) {

 // TODO: Add your specialized code here and/or call the base class

 if (pMsg->message==WM_KEYUP && pMsg->wParam==VK_DOWN) {

  MessageBox("DOWN KEY WAS RELEASED!");

  return TRUE; // уберите это, если хотите, чтобы

  // сообщение еще обработалось и стандартным образом

 }

 // вызываем стандартную обработку, оттуда будет 

 // вызвана PreTranslateInput(), откуда, в свою

 // очередь, вызывается IsDialogMessage()

 return CDialog::PreTranslateMessage(pMsg); 

}

В ПОИСКАХ ИСТИНЫ

Я решил, что будет лучше публиковать по одному вопросу в выпуске. Так и размер выпусков будет меньше (повторюсь, меня не раз укоряли за то, что выпуски получаются слишком "тяжелые"), да и проще ссылаться на вопросы – по номеру выпуска. 

Вопрос сегодняшнего выпуска:

Q. Нужно изменить шрифт у одного элемента типа CStatic. Делаю это функцией SetFont(CFont font). Фонт меняется у элемента … и у всего окна :(. Включая кнопки и другие элементы типа static. Мне его надо было толстым сделать, так у меня такие кнопки стали — загляденье:)) Кто-нибудь знает в чем дело и как решить?

LiMar

Предлагаю подписаться на дружественную рассылку:

COM/DCOM - вокруг да около

Все на сегодня. Пока!

©Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №9 от 11/07/2000

Здравствуйте, уважаемые подписчики!

ОБРАТНАЯ СВЯЗЬ

Из входящей почты

Мы с вами уже разобрали ответы на вопрос о том, почему в Debug-версии все иногда работает нормально, а в Release появляются большие проблемы (этот вопрос был задан в выпуске №5). Уже после того, как вышел выпуск с ответами на этот вопрос, пришли еще несколько писем на эту тему. Большинство сожалеет о том, что такой "элементарный" нюанс – а именно, чреватость использования макроса ASSERT, – остался вне обсуждения.

Для тех, кто не понял, в чем здесь дело: макрос ASSERT(<условие>), в отличие от сходного макроса VERIFY(<усл>),  работает только в Debug-версии, а в Release-версии этот макрос просто заменяется пустой строкой, следовательно условие, которое указывается в скобках, не проверяется. Таким образом, если ваша программа нашпигована такими вот макросами, и вы компилируете ее как Release, проверка всех условий совершенно незаметно для вас исчезает.

А теперь у меня вопрос к авторам таких ответов: Каким образом в Debug-версии все может быть нормально, если исчезновение ASSERT'ов оказалось критичным для работы Release-версии? (Хотя, если честно, один такой способ существует, и именно его, скорее всего. имели ввиду авторы писем. Но я просто никогда  еще не встречал таких оригиналов, которые в условие  макроса ASSERT умудрятся впихнуть что-нибудь помимо самого условия,  выделение памяти или инициализацию объекта, например. Никогда так не делайте! Впрочем, уверен, что большинство до такого все-таки не додумалось ;) 

Итак, выходит в Debug-версии программа должна была вылетать на "Assertion failed", а это вряд ли можно назвать "нормальным выполнением". Напоминаю, в самом вопросе утверждалось, что в Debug программа работает без проблем.

Вообще, макрос ASSERT предназначен как раз для того, чтобы именно Debug-версия и не работала , если у вас что-то в программе не в порядке! Таким образом, программист сможет сразу понять, что и где у него не так (это, конечно, в идеале ;).

Но замечу, что сам по себе нюанс этот достаточно интересный. Итак, люди – обратите внимание на макросы ASSERT и VERIFY! Напоминаю: VERIFY, в отличие от ASSERT, сохраняется и в Release-версии, хотя в последнем случае он не прерывает программу даже если условие не выполняется.

Читателей, поднявшим этот вопрос, благодарю, а это: Alexander Dymerets, Alexey "Locky" B.R.  и Serge Zakharchuk.

В отличие от большинства, Olga Zamkovaya предложила другой способ выяснить, в чем дело:

…К вопросу о недопустимой операции в Release версии программы из выпуска #5: в числе полезных советов "проверьте свой код", "build all может помочь" и т.п. не было предложено воспользоваться опцией компилятора /GZ (catch Release-build errors in Debug build), что, мне кажется, может быть полезно в данной ситуации.)

Olga Zamkovaya

Что ж, думаю, и это кому-то поможет – ловить Release-ошибки в Debug. По крайней мере можно будет обнаруживать ошибки на стадии, которая как раз предназначена для отлова ошибок;) Thank you, Olga.


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

Здравствуйте, Алекс!

Решил попробовать свои силы во внесении посильного вклада в понимание не самых понятных вещей, которые касаются каким-либо образом MS VCPP.

Итак, в выпуске №5 промелькнул вопрос об обработке клавиш в диалоге. Я в свое время столкнулся с точно таким же вопросом и даже собирался его решать способом, которым решил автор вопроса, но меня не хватило: я ленивый. Я нашел очень полезную вещь: использование акселераторов (горячих клавиш) – accelerators – в диалогах. Пользуюсь этим способом регулярно и до сих пор. Идея, в принципе, та же: перегрузить PreTranslateMessage.

Код для этой функции:

BOOL CSomeDialog::PreTranslateMessage(MSG* pMsg) {

 if (pMsg->message>= WM_KEYFIRST && pMsg->message <= WM_KEYLAST) 

  if (m_hAccel)

   if (::TranslateAccelerator(m_hWnd, m_hAccel, pMsg)) return TRUE;

 return CDialog::PreTranslateMessage(pMsg);

}

Здесь m_hAccel — переменная-член класса CSomeDialog типа HACCEL, инициализированная в OnInitDialog таким, например, способом: m_hAccel = ::LoadAccelerators(AfxGetInstanceHandle(), MAKEINTRESOURCE(m_lpszTemplateName)); Если ее инициализировать таким образом, то будет произведена попытка найти ресурс акселератора с тем же ID, что и ID диалога (например, IDD_SOMEDIALOG), в котором можно прописать какие только душа пожелает клавиши и их комбинации. Если же ресурс найден не будет, то ничего страшного не произойдет.

Обрабатывать команды от акселератора можно стандартным способом — ON_COMMAND в MESSAGE_MAP'е. Я их прописываю руками, без ClassWizard'а. Да, кстати, можно запросто лепить в таблицу акселератора IDшки кнопок (push buttons). Хэндлер для обработки кнопки, объявленный с помощью ON_BN_CLICKED, будет вызван автоматически (это связано с тем, что ON_COMMAND и ON_BN_CLICKED на самом деле — одно и то же).

[…]

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

Спасибо за вашу работу и за ее результат.

--

Пишите письма…

(адрес может быть опубликован, но не продан спаммерам :)

Чепкий Николай (mailto:alterego@a-teleport.com)

Адрес я опубликовал, но спаммерам не продавал  – так что моя совесть на этот счет чиста. ;)  Если это сделает кто-нибудь из читателей – это будет на его, а не моей, совести.

Вопрос этот обсуждался в прошлом выпуске.  Преимущество способа, предложенного Николаем, заключается в автоматизации обработки нажатий клавиш. Так что вместо неуклюжего switch'a в случае большого количества клавиш мы получаем удобный списочек – и минимум кода. 


Один из читателей прислал интересный совет, предлагаю его вашему вниманию:

Привет!

Хочу обратить внимание на то, что изменение формы окон при помощи SetWindowRgn() не всегда правильно работает в старых версиях Windows – в частности, такая ситуация наблюдалась под Windows 95 (PLUS) не OSR 2.

Зато совершенно точно это работает под '98, NT, 2000.

-------

Хочу предложить полезную уловку, позволяющую при использовании MFC-шаблонов документов управлять MDI-окнами из приложения. Этот трюк можно использовать при отображении разных категорий данных в различных окнах. При этом можно, в частности, автоматически переключать активные MDI-окна при обновлении данных в них.

Представьте библиотеку (класс), следующего вида:

class TReg {

public: 

 static CMapStringToPtr map;

 static BOOL RegisterTemplate(CString strName, CDocTemplate * ptr);

 static BOOL HasOpenViews(CString strName);

 static BOOL PostForAllViews(CString strName, UINT msg, WPARAM w, LPARAM p);

 static BOOL SendForAllViews(CString strName, UINT msg, WPARAM w, LPARAM p);

 static CDocTemplate * GetTemplate(CString strName);

 ... 

};

Зачем все элементы статические – легко понять, ведь у нас только один MDI-фрейм.

Далее, в методе WinApp::InitInstance() при порождении шаблонов документов  вместо (или вместе с) AddDocTemplate( CDocTemplate * )  записываем TReg::RegisterTemplate( "MyName", CDocTemplate * );

Здесь мы просто добавляем указатели шаблонов в словарь map.

С помощью метода GetTemplate() мы можем извлечь указатель на шаблон из словаря по имени. Используя этот указатель, мы можем: 

– открыть новое окно при помощи DocTemplate::OpenDocumentFile();

– закрыть все окна, относящиеся к данному шаблону;

– отправить сообщение всем окнам данного шаблона:

for (POSITION pos= pTempl->GetFirstDocPosition(); pos != NULL; ) {

 CDocument * pDoc= pTempl->GetNextDoc(pos);

 if (msg == NULL) pDoc->UpdateAllViews(NULL);

 else

  for (POSITION p1= pDoc->GetFirstViewPosition(); p1 != NULL; ) {

   CView * pView= pDoc->GetNextView (p1);

   pView->PostMessage (msg, w, l);

  }

}

– проверить, имеются ли открытые окна, относящиеся к данному шаблону:

for (POSITION pos = pTempl->GetFirstDocPosition(); pos != NULL; ) {

 CDocument * pDoc= pTempl->GetNextDoc(pos);

 for (POSITION p1 = pDoc->GetFirstViewPosition(); p1 != NULL; ) {

  CView * pView = pDoc->GetNextView(p1);

  if (pView != NULL) return TRUE;

 }

}

return FALSE;

и т.д.

Активизация (всплывание наверх) MDI-окна в программе проще всего реализуется добавлением примерно такого метода класса CView:

void CMyView::DoActivate() {

 CMDIChildWnd * pFrm = (CMDIChildWnd *)(GetParent());

 if (pFrm != NULL && IsWindow(pFrm->m_hWnd)) pFrm->MDIActivate();

}

Victor Yakovlev

Да, это может быть полезно, особенно для тех, кто сталкивался (или кому еще только предстоит столкнуться) с разработкой сложных MDI-приложений – они знают, как трудно добиться правильной совместной работы всех дочерних окон. 

ВОПРОС-ОТВЕТ

Q. Нужно изменить шрифт у одного элемента типа CStatic. Делаю это функцией SetFont(CFont font). Фонт меняется у элемента … и у всего окна :(. Включая кнопки и другие элементы типа static. Мне его надо было толстым сделать, так у меня такие кнопки стали — загляденье:)) Кто-нибудь знает в чем дело и как решить ?

LiMar

A. Присланные ответы на этот вопрос сводились к двум следующим: 

1) сделать класс-наследник от CStatic и перекрыть функцию прорисовки – OnPaint();

2) вызывать метод SetFont() именно объекта CStatic (или указателя на этот контрол), а не всего диалога.

Порекомендовавшие первый способ явно забыли правило "бритвы" Оккама: не множить сущностей без нужды. (Кстати, нам, программистам, это правило особенно полезно.) Если для того, чтобы поменять шрифт, нужно создавать новый класс, ну уж извините… Этим способом, конечно, можно пользоваться, но я думаю, только в тех случаях, когда без этого не обойтись.

Итак, второй ответ был больше всего похож на искомую истину. Но "похож" – это еще не значит "есть", так что я решил проверить. Сделал простое SDI-приложение, и попробовал в окне About у одной из надписей поменять шрифт. 

Как же я был рад, когда он в самом деле изменился!!!

…Правда, на совершенно не тот, который я хотел. Да и размерчик прежний остался… Это было весело – в любом случае он ставил шрифт System, хотя (у меня много шрифтов!) я прописывал разные. Никакого результата. Способ No.2 у меня не работал. Либо он был неправильный, либо, как впоследствии оказалось, правильный не до конца.

Через некоторое время мне это надоело, и я решил, что раз уж не оказалось пророков среди читателей, пророком придется стать самому (это метафора;)

Самое обидное то, что ответ даже не пришлось искать ! Он лежал на самом видном месте в MSDN. Я ввел "SetFont" в строке поиска и мгновенно обнаружил интереснейшую статью с говорящим само за себя названием – "Correct Use of the SetFont() Function in MFC". 

Суть статьи сводилась к следующему:

Обычно в SetFont передают указатель на шрифт – объект CFont. Так вот, обязательно нужно проследить , чтобы этот объект не уничтожился раньше, чем тот контрол, для которого он создается!

Итак, как было у меня раньше (или "способ №2"):

BOOL CAboutDlg::OnInitDialog() {

 CDialog::OnInitDialog();

 CFont times;

 times.CreatePointFont(100, "Times New Roman");

 m_Static.SetFont(×);

 times.DeleteObject();

 return TRUE; 

}

m_Static — переменная, представляющая соответствующий Static-контрол. Вместо нее можно воспользоваться указателем, возвращаемым ф-цией GetDlgItem().  Как вы видите, объект CFont уничтожается сразу же после вызова SetFont().

А вот как надо было сделать:

class CAboutDlg : public CDialog {

 …

private:

 CStatic m_Static;

 CFont m_fntTahoma; // добавляем шрифт в диалог

}


BOOL CAboutDlg::OnInitDialog() {

 CDialog::OnInitDialog();

 m_fntTahoma.CreatePointFont(100, "Tahoma");

 m_Static.SetFont(&m_fntTahoma);

 return TRUE; 

}


BOOL CAboutDlg::DestroyWindow() {

 m_fntTahoma.DeleteObject();

 return CDialog::DestroyWindow();

}

Здесь все работает как надо. Вскоре, когда надоела Tahoma,  я уже наслаждался отлично выглядевшей готической надписью. (Кстати, тут возникает еще вопрос – получается, чтобы нужный шрифт был всегда доступен, нужно распространять его вместе с приложением? Конечно, это не относится к стандартным Windows-шрифтам, типа Arial, Times, Tahoma или Courier. Лучше все-таки обходиться ими, когда возможно).

Тех, кто хочет получить больший контроль над шрифтом – сделать его жирным, курсивом и т.д., отправляю прямиком к той же статье, да еще к функции CFont::CreateFontIndirect().

Я прошу прощения, что, возможно, слишком подробно расписал ответ на этот вопрос (хотя не исключаю, что кому-то это было интересно прочитать). Я преследовал еще одну цель – сказать всем: "Люди, учитесь пользоваться MSDN! На многие ваши вопросы там уже отвечено!"

Ответ на этот вопрос прислали: Николай Чепкий , Igor Sorokin, Alexander Dymerets, Pavel Vasev.

В ПОИСКАХ ИСТИНЫ

Q. Как получить доступ к ресурсам DLL в самой DLL? Задача сводилась к следующему – нужно было сделать диалоговое окно в функции, которая находилась в DLL.

declspec(dllexport)

int MyDllFunction() {

 CDialog dlg ;

 int ret = dlg.DoModal();

 return ret ;

}

DLL имела ресурс Dialog для этого диалогового окна, но работать напрочь отказывалась – этот ресурс не обнаруживался и окно не создавалось. DLL собиралась как со статически линкуемой библиотекой MFC, так и с динамически линкуемой библиотекой MFC.

Igor Sorokin

За сим откланиваюсь. 

Будьте здоровы!

©Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №10 от 18/07/2000

Здравствуйте!

Прошу прощения за небольшую задержку этого выпуска. 

Между прочим, со дня создания рассылки уже прошел целый месяц. За это время на нее подписалось более 5000 человек, причем чуть меньше 4000  из них – на  HTML версию.

WEBзор

Недавно мне пришло письмо от одного человека с предложением рассказать в рассылке об их сайте, часть которого посвящена как раз программированию на Visual C++. Тогда у меня появилась идея сделать эту рубрику, где я мог бы рассказывать об интересных ресурсах  по теме рассылки, которые можно обнаружить на просторах интернета. Я уже, правда, рассказывал про CodeGuru – но это не было вынесено в отдельную рубрику… да и те, кто не очень дружит с английским, могли задаться вопросом, а нет ли в Сети чего-нибудь интересного по VC на русском языке?

Итак, сегодня, по специальному предложению одного из авторов, мы с вами рассмотрим сайт "ПЕРВЫЕ ШАГИ" (http://www.mjk.msk.ru/~dron/)

Прежде всего, стоит отметить широкий диапазон тем, охватываемых этим сайтом –  это MFC, WinAPI, OpenGL, ActiveX, а также VBA, SQL, HTML, CGI, Perl, форматы файлов, алгоритмы и многое другое.

Содержание оформлено в виде "шагов" – отсюда, в частности, и название – маленьких порций информации, которые легко читать и усваивать. Обычно каждый шаг ставит и выполняет определенную задачу, так что легко можно найти решение какой-то конкретной проблемы. 

Все описанное мной далее относится к разделу "Visual C++".

Есть материал как для начинающих, так и для более продвинутых программистов. Раздел, посвященный MFC, содержит более 200 "шагов". Темы шагов в большинстве своем подобраны интересные и нужные, а для новичков, не имеющих возможности свободно читать MSDN,  вообще незаменимые.

Из недостатков хочу отметить некоторую сухость и краткость изложения (хотя последняя, конечно, сестра таланта), иногда все выливается в "нажми туда-то, напиши то-то". Также мне не совсем по вкусу местами чересчур неофициальный и немного непоследовательный стиль автора, но это кому как, наверное. 

ОЧЕНЬ СИЛЬНО портит впечатление обилие опечаток и орфографических ошибок (не говоря уже о пунктуационных) … во многих  из "шагов" я мог насчитать не меньше двух. Обидно! В крайнем случае – вроде спел-чекеры уже не редкость… 

Не знаю, как сейчас, но раньше, помню, сайт не позволял себя скачивать целиком программами типа Teleport Pro. Мне это казалось совершенно неоправданным и ненужным ограничением – в конце концов, у нас ведь не Америка, где неограниченный доступ стоит 15-20 долларов в месяц. В гостевой книге 90% записей были посвящены этому вопиющему безобразию… Авторам сайта, наверно, это надоело, и они гостевую книгу убрали совсем… ;)

Хотя выполнять свое предназначение сайту все это, конечно, не мешает. Да и критиковать легко…

Зайдите, посмотрите, –  скорее всего, найдете что-нибудь интересное и для себя.

ВОПРОС-ОТВЕТ

Q. Как получить доступ к ресурсам DLL в самой DLL? Задача сводилась к следующему – нужно было сделать диалоговое окно в функции, которая находилась в DLL

declspec(dllexport)

int MyDllFunction() {

 CDialog dlg;

 int ret = dlg.DoModal();

 return ret;

}

DLL имела ресурс Dialog для этого диалогового окна, но работать напрочь отказывалась – этот ресурс не обнаруживался и окно не создавалось. DLL собиралась как со статически линкуемой библиотекой MFC, так и с динамически линкуемой библиотекой MFC.

Igor Sorokin

A1. В вопросе приводился пример функции, с помощью которого предполагалось вызвать диалог. В MSDN я нашёл статью TN058, рассказывающую о том, как реализовано управление модулями в MFC.

Для того, чтобы получить доступ к любому объекту MFC из экспортируемой функции, необходимо в самом начале функции поставить AFX_MANAGE_STATE(AfxGetStaticModuleState()) ;

Таким образом, будут корректно реализована связь дескрипторов (HANDLE) с объектами MFC и , в частности, ресурсы, хранимые в DLL будут корректно задействованы:

declspec(dllexport)

int MyDllFunction() {

 AFX_MANAGE_STATE(AfxGetStaticModuleState());

 CDialog dlg(IDD_TESTDLG);

 return dlg.DoModal();

}

Алексей Селезнев

A2. Вообще говоря, доступ к ресурсам DLL из самой DLL получать не надо – он и  так дан. Но пример, указанный в вопросе, по-моему, чуть-чуть не правильный, и работать никогда не будет, потому как "CDialog dlg" не проинициализирован как следует. Пусть в DLL-проекте создан ресурс-диалог, с идентификатором (например) IDD_RTNDIALOG. Для того, показать этот ресурс-диалог (в модальном режиме), надо выполнить:

CDialog dlg(IDD_RTNDIALOG);

dlg.DoModal();

Здесь конструктору объекта dlg передаём ID ресурса – нашего диалога. Можно  еще указать родительское окно. Чтобы показывать этот диалог немодально, следует использовать Create/[ShowWindow/WS_VISIBLE].

Однако, если мы хотим, чтобы диалог содержал всякие контролы, помимо OK и Cancel, то нужно на основе ресурса-диалога создать класс-наследник CDialog'a. (в MFC – например с даблкликнув на форму шаблона). Пусть мы создали класс с именем CRtnDlg. Он и будет реализовывать всякие обработчики контролов.

Показать модально проще простого:

CRtnDlg dlg;

dlg.DoModal();

Немодально – use ShowWindow(…);

Кстати, в описании CRtnDlg.h нужно не забыть вставить #include "resource.h" – а то компилятор тоже ресурса не увидит :)))

Кстати, на счет примера – Игоря я обидеть не хотел, может он его так, для пояснения сути написал.

3. Вопрос:

Недавно я писал курсовую – рисует всякие дифуры. А каждое конкретное диф.ур-ие реализуется в отдельной DLL'ке (по типу plugins). А т.к. мои DLL с дифурами имели единый интерфейс(не COM), для них я сделал шаблон. А потом случилось страшное – DLL-проекты, созданные по шаблону, не компилировались, с дурацкими ошибками. Короче, через сутки я выяснил, что почему-то в проекте, созданном по шаблону, директива компилятора _AFXEXT заменяется на _USRDLL (в результате мой DLL плавно превращается из MFC extension в Regular DLL). Шаблон создавал по существующему проекту. Ни в исходном проекте, ни в шаблоне ничего в опциях не путал. Приходилось потом вручную каждый раз изменять директивы. А в чем же дело? Может знает кто?

4. Алекс, и ещё – на счет ответов на вопрос в №8. Я там между прочим указывал, что объект CFont нужно сделать членом класса окна, т.к. передаётся указатель.

Pavel Vasev

Насчет пункта 4 Павел совершенно прав, я просто не обратил внимания на это его замечание (тогда я не знал, что это имеет ключевое значение, а потом не вспомнил). Он, кажется, единственный, кто на  это указал.

Благодарю также авторов всех остальных ответов на этот вопрос. Их прислали: Ivan Nevraev, Alexander N. Dovzhikov, Alex Hin.

В ПОИСКАХ ИСТИНЫ

Q. Не подскажете как в tray выводить текст, как например сделаны часы в Windows?

Dmitriy

Как выводить в tray иконку, надеюсь, все знают ;) 

Shell_NotifyIcon() есть, а вот Shell_NotifyText(), к сожалению, не существует… ;)

У меня просьба (в связи с небольшими неполадками) – прошу тех, кто не получил от меня ответа в течение недели или больше, послать письмо еще раз.

Желаю всем программировать с удовольствием!

©Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №11 от 22/07/2000

Добрый день всем!

В ответ на публикацию вопроса Дмитрия о System Tray в предыдущем выпуске помимо прямых ответов пришло еще несколько просьб рассказать о том, как в системный tray вообще помещать иконки. Я, видимо, был излишне оптимистичен, когда посчитал, что это все знают ;) Так что я решил поведать уважаемым читателям об этом в данном выпуске, в рубрике "WINAPI", в расчете на то, что эта информация будет полезна многим. Получается, сегодняшний выпуск целиком посвящен system tray ;)

WINAPI

Итак, задача у нас следующая: поместить в системный tray свою иконку, причем заставить ее функционировать стандартным образом – чтобы при наведении на нее появлялась подсказка, при нажатии на правую кнопку мыши выскакивало меню, на левую – производилось какое-нибудь действие.

Начнем с начала – нужно поместить иконку в tray. Сами вы это вряд ли сделаете – да это и не нужно. За вас это сделает Windows, вам нужно только сообщить операционной системе о своем намерении. Для этого служит функция Shell_NotifyIcon( ), которая позволяет создавать, изменять и удалять такие иконки.

Первый аргумент этой функции — это код операции, которую вам нужно осуществить. Он имеет три возможных значения — NIM_ADD, NIM_DELETE и NIM_MODIFY. В пояснениях, по-моему, не нуждается. Второй параметр – указатель на структуру NOTIFYICONDATA. Вот как эта структура выглядит:

typedef struct _NOTIFYICONDATA {

 DWORD cbSize; // размер, обязательно указывать

 HWND hWnd;    // HWND для посылки уведомлений

 UINT uID;     // идентификатор иконки в tray, не имеет отношения к ресурсам

 UINT uFlags;  // см. ниже

 UINT uCallbackMessage; // посылается вашей функции окна

 HICON hIcon;    // дескриптор иконки

 CHAR szTip[64]; // строка с подсказкой

} NOTIFYICONDATA;


// uFlags

#define NIF_MESSAGE 0x1 // uCallbackMessage содержит информацию

#define NIF_ICON 0x2    // hIcon содержит информацию

#define NIF_TIP 0x4     // szTip содержит информацию

В принципе, назначение каждого члена этой структуры довольно прозрачно. Замечу только, что uID – это не идентификатор ресурса иконки, как можно было бы подумать, а вами определенный идентификатор для tray icon вашего приложения. Иконка, которую выводит в tray приложение, может меняться в процессе работы, но этот идентификатор остается постоянным.

Также вам нужно в uCallbackMessage записать сообщение, которое вы хотите чтобы система вам посылала в качестве уведомления о событиях, происходящих с вашей иконкой. Для этого в программе определите какое-нибудь user-defined сообщение,  например так: #define WM_TRAYNOTIFY (WM_APP+100).

WM_APP используется как раз для того, чтобы именно в таком виде и определять нужные вам сообщения.

Теперь, предположим у вас подготовлена иконка для tray:  IDI_MYTRAYICON. Нам нужно ее вывести в tray. Вот что мы делаем:

// уведомляющее сообщение

#define WM_TRAYNOTIFY (WM_APP+100)

// идентификатор иконки

#define ID_TRAYICON 1000

CString sNotifyTip = "Название вашей программы или другая подсказка";

NOTIFYICONDATA nid;

memset(&nid, 0, sizeof(nid)); // обнулять структуру перед использованием – хорошая привычка

nid.cbSize = sizeof(nid);

nid.hWnd = hWnd;

nid.uID = ID_TRAYICON;

nid.uFlags = NIF_MESSAGE | NIF_ICON | NIF_TIP;

nid.uCallbackMessage = WM_TRAYNOTIFY;

nid.hIcon = ::LoadIcon(hInstance, MAKEINTRESOURCE(IDR_MAINFRAME));

lstrcpyn(nid.szTip, sNotifyTip, sizeof(nid.szTip));

Shell_NotifyIcon(NIM_ADD, &nid);

Этот код вставьте в функцию инициализации, причем окно  вашего приложения уже должно быть создано, hWnd и hInstance должны быть определены. hWnd вы получаете при создании окна, а hInstance вам передают прямо в WinMain. Если у вас MFC-приложение, поставьте вместо них соответственно AfxGetMainWnd()->m_hWnd и AfxGetApp()->m_hInstance.

Ну вот, иконку мы вывели, и даже подсказка у нас выводится. Для своевременного удаления иконки в функцию, обрабатывающую выход из программы, поставьте примерно такую же конструкцию, но с NIM_DELETE: 

NOTIFYICONDATA nid;

memset(&nid, 0, sizeof(nid)); 

nid.cbSize = sizeof(nid);

nid.hWnd = hWnd;

nid.uID = ID_TRAYICON;

Shell_NotifyIcon(NIM_DELETE, &nid); 

(в структуре nid достаточно теперь определить только cbSize, hWnd и  uID).

Но иконка бесполезна, если она ничего не делает. Давайте добавим немного функциональности. Система посылает нам сообщение WM_TRAYNOTIFY каждый раз, когда с иконкой что-то происходит. Все, что мы должны сделать –  обработать это сообщение и отреагировать должным образом. 

Добавьте в программу обработчик события WM_TRAYNOTIFY. В этом сообщении wParam – это ID иконки, а lParam – код сообщения от мыши, например WM_RBUTTONDOWN. Если у вас не MFC-приложение, просто добавьте один case в функцию окна.  Если же вы имеете дело с MFC, то сделайте следующее: в класс главного окна(диалога) добавьте функцию  afxmsg void OnTrayNotify(WPARAM wParam, LPARAM lParam);

В карту сообщений класса добавьте следующую строку: ON_MESSAGE(WM_TRAYNOTIFY, OnTrayNotify)

Таким образом обрабатываются пользовательские сообщения. Эта строка свяжет наше сообщение WM_TRAYNOTIFY с функцией его обработки OnTrayNotify().

В этой функции проверяйте значение lParam и делайте то, что вам нужно, например, выводите меню. Как именно это делать – уже совсем другая история…

void CMyDlg::OnTrayNotify(WPARAM wParam, LPARAM lParam) {

 if (lParam==WM_LBUTTONDOWN) {

  ::SetForegroundWindow(m_hWnd); // активизируем наше приложение

  AfxMessageBox("Была нажата левая кнопка");

 } else if (lParam==WM_RBUTTONDOWN) {

  ::SetForegroundWindow(m_hWnd);

  AfxMessageBox("Была нажата правая кнопка");

 }

}

ВОПРОС-ОТВЕТ

Q. Не подскажете как в tray выводить текст, как например сделаны часы в windows?

Dmitriy

A1. Copy from ListSOFT от 18.07.2000

"…Если хочешь, чтобы рядом с системными часами располагалась надпись, например, твое имя, то в HKEY_CURRENT_USER\Control panel\ International\ в первые два параметра запиши его (не более 8 символов), а в третий запиши "HH:mm:ss tt". Кстати, если изменить формат времени таким способом, то строка, записанная в первые два параметра будет фигурировать во всех программах, запрашивающих время, например, в Outlook Express в графе Отправлено и Получено."

Grigori Zagarski

Я попробовал так сделать – не получилось. У меня в этом разделе вообще всего один параметр  – "Locale". Что-то автор напутал… Может, путь указан неправильно? Хоть результат и отрицательный, я решил все же на всякий случай опубликовать этот ответ – может, тут действительно дело во мне (я проверял в Windows 98SE), ведь на ListSOFT действительно была такая публикация. А может, кто и подскажет, в чем дело.

A2. Я предлагаю набирать текст из иконок, которые должны создаваться динамически.

Подобный подход я видел в нескольких программах, где tray-иконки используются для индикации уровня занятости CPU и т.п.

Пример вывода текста в tray приаттачен. Сам вывод делается в классе CShellNotifyText. Тестовая программка организует в tray'е что-то типа таймера.

Может быть это не самый простой вариант, но пусть кто-нибудь предложит лучше :))

Хочу высказать свое положительное мнение о рассылке. Единственное, что смущает в свете последних известий от Microsoft: Кому будут нужны знания по MFC, когда все начнут программировать на Си-диез (C#)?

Сергей Цивин

Пример я посмотрел, он работает. Но, к сожалению, у такого подхода есть один очень существенный недостаток: если TaskBar в высоту имеет больше одной полосы, никто не гарантирует, что у вас не произойдет переноса на самом  неподходящем для этого символе. Я сам смоделировал такую ситуацию, это было сделать легко и выглядело совершенно неприемлемо. Если кто-нибудь знает вдруг, как эту дилемму разрешить – пишите.

А насчет C# – вынужден повториться, он не позиционируется как конкурент VC и MFC. Microsoft полагает, что это Java-киллер. Так, в следующую версии VisualStudio известный продукт Visual J++, скорее всего, не войдет, а вместо него будет сами догадайтесь что…


Успехов!

©Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №12 от 24/07/2000

Приветствую!

MFC

Недавно мне пришло письмо с просьбой рассказать о таком элементе управления, как CTabCtrl. После того, как я отправил ответ, я подумал, что это могло бы быть интересно многим. Так что я немного переработал материал, кое-что добавил и – читайте!

CTabCtrl: Закладки как средство продуманного интерфейса

Очень часто так бывает, что все нужные элементы управления в диалог не помещаются. Или помещаются, но смотрятся очень неважно: хаотично и не всякий сразу поймет, что к чему. Правилами хорошего интерфейса в таких случаях принято делить элементы управления на логические группы, и каждую логическую группу помещать отдельно. Но что если эти логические группы сами по себе не такие уж маленькие? Тогда лучше всего сами логические группы помещать на разных страницах диалога… а откуда взять эти разные страницы, если диалог-то всего один?

Во тут-то нам и приходят на помощь закладки. Они позволяют иметь несколько страничек, и легко между ними переключаться. Посмотрите – в Windows очень много примеров применения такого подхода. Наверняка вы с ним уже встречались, и не раз. 

Итак, какие же средства предоставляет нам MFC для работы с закладками? Можно назвать три класса: CPropertySheet (вместе с CPropertyPage) и CTabCtrl. 

Первый класс (CPropertySheet) представляет собой более сложное образование, позволяющее создавать так наз. страницы свойств, готовые диалоги со стандартными кнопками и набором закладок, где вы размещаете свои элементы управления. В качестве примера можете посмотреть диалог Tools|Options в интегрированной среде Visual C++. Это полезно, если вам нужно создать именно такой диалог, например для изменения конфигурации программы. CPropertySheet представляет набор страниц, CPropertyPage – отдельную страницу такого набора. 

Но что если вам нужно получить больший контроль над закладками? Что если вам нужны только закладки, а не готовый диалог? А еще если вы хотите кроме текста в заголовках закладок рисовать иконки?

Вот тогда вам нужно воспользоваться CTabCtrl, классом более низкого уровня, чем CPropertySheet. Замечу, что сам класс CPropertySheet использует CTabCtrl, причем его можно  попросить дать вам указатель на этот объект.  Таким образом, Узная, как работать с CTabCtrl, вы одновременно узнаете, как можно на низком уровне работать с CPropertySheet. А про CPropertySheet я расскажу как-нибудь в другой раз.

Пусть вам нужно сделать закладки в существующем диалоге. Создать элемент типа CTabCtrl можно двумя способами: динамически (в программе) и в редакторе ресурсов. Для примера воспользуемся вторым способом. 

В палитре элементов найдите  "Tab Control" и поместите его в ваш диалог. Теперь два раза кликните по нему мышкой при нажатой клавише Ctrl. Вам будет предложено создать переменную класса, соглашайтесь. Введите m_Tab  в качестве имени и CTabCtrl в качестве типа. По умолчанию наш объект пока не содержит ни одной закладки. Чтобы они появились, их необходимо создать с помощью функции InsertItem(). Это можно сделать в OnInitDialog():

BOOL CTabDlg::OnInitDialog() {

 TC_ITEM tci; // в нее записываются параметры создаваемой закладки

 memset(&tci,0,sizeof(tci));

 tci.mask = TCIF_TEXT; // у закладки будет только текст

 tci.pszText = "Закладка 1"; // название закладки

 m_Tab.InsertItem(0, &tci); // первая закладка имеет индекс 0

 tci.pszText = "Закладка 2";

 m_Tab.InsertItem(1, &tci); // вставляем вторую закладку

 return TRUE;

}

Ну вот, у нас есть две закладки. Теперь нам нужно поместить что-нибудь внутрь. 

Прежде всего, для каждой из закладок нужно создать диалог, который будет отображаться при выборе этой закладки. Например, создайте для начала два диалога – IDD_TABPAGE1 и IDD_TABPAGE2. В свойствах каждому поставьте тип "Child" – "дочерний" (properties|styles|style:Child) и "Без рамки" (properties|styles|border:None). Для каждого диалога нужно создать соответствующий класс. Это можно сделать, два раза кликнув по поверхности диалога в редакторе. У меня получились классы CTabPage1 и CTabPage2.

Нужные контролы и обработчики в диалоги можно поместить на данном этапе, а можно и потом (хотя для оценки размеров лучше все-таки это сделать сейчас. Потом можно будет внести любые изменения). Но для тестирования какие-нибудь отличительные знаки в них поставить нужно обязательно , а то вы просто не узнаете, какие диалоги где у вас выводятся – все будут одинаковые.

В классе вашего диалога, кому принадлежит TabCtrl (в примере — CTabDlg) добавьте переменную-указатель на текущий диалог:

protected:

 CTabCtrl m_Tabs;

 CDialog* m_pTabDialog; // <--- добавить

В конструкторе класса проинициализируйте ее в 0:

CTabDlg::CTabDlg(CWnd* pParent /*=NULL*/)

 : CDialog(CTabDlg::IDD, pParent) {

 m_pTabDialog=0;

}

Зайдите в ClassWizard и для TabCtrl добавьте обработчик TCN_SELCHANGE (изменение закладки). 

Теперь мы будем динамически удалять прошлый диалог/создавать новый и выводить его в TabControl.

Вот как это выглядит:

void CTabDlg::OnSelchangeTab1(NMHDR* pNMHDR, LRESULT* pResult) {

 int id; // ID диалога

 // надо сначала удалить предыдущий диалог в Tab Control'е:

 if ((m_pTabDialog) {

  m_pTabDialog->DestroyWindow();

  delete m_pTabDialog;

 }

 // теперь в зависимости от того, какая закладка выбрана, 

 // выбираем соотв. диалог

 switch(m_Tab.GetCurSel()+1) // +1 для того, чтобы порядковые номера закладок

 // и диалогов совпадали с номерами в case

 {

 // первая закладка

 case 1:

  id = IDD_TABPAGE1;

  m_pTabDialog = new CTabPage1;

  // тип указателя соответствует нужному диалогу,

  // иначе добавленный в диалог код не будет функционировать

  break;

 // вторая закладка

 case 2:

  id = IDD_TABPAGE2;

  m_pTabDialog = new CTabPage2;

  break;

  // все остальные закладки, если они есть,

  // будут здесь тоже представлены, каждая – отдельным case

  // а если обработка такого номера не предусмотрена

 default:

  m_pTabDialog = new CDialog; // новый пустой диалог

  return;

 } // end switch

 // создаем диалог

 m_pTabDialog->Create(id, (CWnd*)&m_Tabs); //параметры: ресурс диалога и родитель

 CRect rc; 

 m_Tab.GetWindowRect(&rc); // получаем "рабочую область"

 m_Tab.ScreenToClient(&rc); // преобразуем в относительные координаты

 // исключаем область, где отображаются названия закладок:

 m_Tab.AdjustRect(FALSE, &rc); 

 // помещаем диалог на место...

 m_pTabDialog->MoveWindow(&rc);

 // и показываем:

 m_pTabDialog->ShowWindow(SW_SHOWNORMAL);

 m_pTabDialog->UpdateWindow();

 *pResult = 0;

}

Теперь последний штрих: в OnInitDialog() нужно добавить следующий код:

 m_Tab.InsertItem(1, &tci); 

 //-----------------

 // добавить:

 NMHDR hdr;

 hdr.code = TCN_SELCHANGE;

 hdr.hwndFrom = m_Tab.m_hWnd;

 SendMessage(WM_NOTIFY, m_Tab.GetDlgCtrlID(), (LPARAM)&hdr);

 //-----------------

 return TRUE;

}

Это необходимо для того, чтобы отобразить самую первую закладку.

Как вариант можно просто вызвать OnSelchangeTab1(0,0); но тогда из OnSelchangeTab1 нужно удалить последнюю строку (*pResult=0).

Можете вволю поэксперементировать со свойствами и стилями CTabCtrl. Мне, например, очень нравятся закладки, надписи на которых подсвечиваются при наведении курсора мыши, кстати это имеет место в MS Access 97 (стиль TCS_HOTTRACK).

И еще: не забудьте, если диалог у вас немодальный, вы должны обеспечить корректный обмен данными между активным диалогом в Tab Control и вашим приложением. Это делается точно так же, как и обычный обмен данными с немодальным диалогом.

ОБРАТНАЯ СВЯЗЬ 

Небезызвестный вам Борис Бердичевский (см. выпуск №3) делится своим решением часто возникающей проблемы с сериализацией.

Приветствую!

Случилось так, что мне пришлось потратить целый рабочий день на поиск одного решения в области сериализации; готов поделиться.

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

Способ, который я приводил (ReadClass/WriteClass), вполне хорош. Но закавыка-то в том, что в предыдущей версии я по какой-то причине (просто по неопытности) сохранял без WriteClass! А имплементация сериализации была описана как IMPLEMENT_SERIAL(MyClass, CObject, 0)

Итак, подобным образом сериализованный класс надо было успешно прочитать. Понятное дело, ReadClass на такую сериализацию вызывает CArchiveException с кодом CArchiveException::badIndex (=5, для справки)

Казалось бы, лови CArchiveException и обрабатывай себе, но не тут-то было! Вроде незначительная проблема: указатель архива продвигается, и невозможно уже прочитать данные из-за смещения. Никакого средства для возврата указателя на место для CArchive не существует! (Я бы мог попросить уважаемых читателей порыться, но заранее заявляю: бессмысленно! Говорите, можно манипулировать с функцией Seek принадлежащего

CArchive классу CFile? – пробовал, не работает.)

По счастью, нашлась недокументированная возможность. Выяснилось, и это очень важный нюанс, который не разъяснен в MSDN: У функции CReadClass есть 3 параметра, 2 последних имеют умолчание NULL:

CRuntimeClass* ReadClass(const CRuntimeClass* pClassRefRequested = NULL, UINT* pSchema = NULL, DWORD* obTag = NULL);

throw CArchiveException;

throw CNotSupportedException;

Первый параметр – RuntimeClass для проверки на соответствие загружаемого класса.

Второй параметр – поинтер на UINT – версию сериализуемого класса.

Третий параметр, и это самое интересное (кстати, в MSDN записано, что, он предназначен для внутреннего использования в функции ReadClass и обычно задается как NULL) – если не задан нулем, возвращает в младших 2-х байтах значение, сериализованное из архива, а CArchiveException при этом не вырабатывается! Версия при этом не заполняется.

Отсюда решение, которое проиллюстрировано во фрагменте кода:

#define BASE_DATA_VERSION 0x100


IMPLEMENT_SERIAL(MyClass, CObject, VERSIONABLE_SCHEMA | BASE_DATA_VERSION)


void MyClass::Serialize(CArchive& ar) {

 UINT Version=NULL;

 CObject::Serialize(ar);

 DWORD Tag;

 if(ar.IsLoading()) {

  TRY {

   ar.ReadClass(RUNTIME_CLASS(MyClass), &Version, &Tag);

   if (Version == BASE_DATA_VERSION)

    ar >> dwValue; // описано в классе DWORD dwValue;

   else {

    WORD HighW;

    ar >> HighW;

    dwValue = MAKELONG(Tag, HighW);

   }

   ar.Read( title, sizeof(title)); // описано в классе

   // char title[LEN_TITLE];

   ar>> val1;

   ar>> val2; // нормальная сериализация

Борис Бердичевский

Здравствуйте Алекс!

Только что подписался на вашу рассылку, и прочитал все выпуски из архива. Мне показался интересным вопрос из выпуска N2 про возможность структурного сохранения данных в MFC.

На мой взгляд опубликованные ответы были не очень точны, т.к. в MFC все-таки имеются некоторые способы такого хранения, хотя конечно не совсем до конца доделанные.

Прежде всего существует класс COleDocument, который позволяет хранить данные в compound file – в которых как раз и хранятся иерархические данные.

У этого класса есть, к сожалению не документированный, член m_lpRootStg который представляет из себя корневой storage документа.  К сожалению в MFC нет стандартных средств работы со storage, но никто не мешает пользоваться его собственным интерфейсом.

Зато есть класс COleStreamFile который инкапсулируют в себе IStream являясь в то же время потомком CFile, что делает возможным его использования для CArchive и соответственно serialize.

И наконец последнее замечание. К сожалению, модель MFC такова, что при использовании своих IStorage объектов, их НЕОБХОДИМО записывать в функции  serialize, иначе они могут потеряться при команде Save As.

Вот и все что я хотел напистаь. Может немного сумбурно и поздновато, но может кому-нибудь пригодиться.

С уважением,

Nick Pisanov

Спасибо Нику за ответ и полезную информацию. Я  просто хочу заметить, что все-таки вместо "недоделанных" способов чаще предпочитаю использовать свои, хоть с потом и кровью созданные, но доделанные, удобные, не основывающиеся на недокументированных возможностях, досконально известные и работающие на все 100%. 

Но это вопрос философский, конечно… Иногда действительно это приводит к изобретению велосипеда. Программирование – это все-таки больше искусство, чем наука ;) Каждый творит по-своему.


Пришло дополнение к прошлому выпуску:

Hello!

Маленькое замечание. После Shell_NotifyIcon( NIM_ADD, &nid); надо еще добавить ::DestroyIcon(nid.hIcon);

Я как-то делал анимацию иконки в трэе (типа как TheBat крылышками там машет) и долго не мог понять, почему после нескольких часов работы прога вешает всю систему, а никакой утечки памяти нет.

Андрей, Норильск

Огромное спасибо, Андрей! Действительно, если делать такие анимации в tray, то своевременное уничтожение иконки становится критичным. 

И еще на тему прошлого выпуска:

В 11 выпуске был вопрос, касаемо часов и реестра. Дело не в тебе, а в авторе сообщения. Дело в том, что windoza ставит в  этот ключ что-то только если user что-то поменял в разделе "язык и стандарты". Если же там всё по умолчанию, то в реестре у  тебя будет по этому пути только параметр Locale, указывающий код страны, правила записи даты, времени и т.п. которой  используются для вывода системной даты.

Пригожев Александр (alexproger)

Что ж, видимо так оно и есть. Я дописал нужные параметры и все заработало. Но только после того, как я изменил региональный стандарт с русского на английский(США). Те два параметра, в которых вы записывали свое имя – на самом деле это метки "до полудня" и "после полудня", по умолчанию равные "AM" и "PM". В русском стандарте эти метки не используются.

ПРОШУ ВНИМАНИЯ:

Это последний выпуск рассылки в этом сезоне. К сожалению, я не знаю никого, кому мог бы доверить вести рассылку на время моего отпуска (и кто бы горел желанием это делать), поэтому рассылка также уходит в отпуск до конца лета . 

Большая просьба не ждать от меня ответа на свои письма  раньше сентября – я буду отсутствовать физически. Прошу прощения у тех, на чьи письма и вопросы не успел ответить.

Надеюсь, что рассылка для вас является интересной и познавательной. Также уверен, что после выхода из отпуска она станет еще полезнее, так как я собираюсь воплотить несколько новый идей.  А еще осенью должен открыться официальный сайт рассылки. Так что

до встречи в новом сезоне! Оставайтесь с нами!
©Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №13 от 7 сентября 2000 г.

Здравствуйте, дорогие подписчики!

Чрезвычайно рад приветсвовать вас после чуть более чем месячного отдыха. Как вы уже наверное сами догадались, рассылка вышла из отпуска и снова будет периодически радовать вас всяческой полезной информацией о мощнейшем современном инструменте разработки, а именно Microsoft Visual C++, ну а также о всем, что с ним связано. Начинается новый сезон выпусков, и начинается он с весьма счастливого номера – тринадцатого ;) Впрочем, я никогда не был особенно суеверным, так что пропускать это замечательное число никак не намерен.

Я взял на себя смелость немного изменить оформление рассылки – спасибо ребятам с subscribe.ru, они наконец-то догадались, что далеко не все пребывают в диком восторге от их цвета для фона страницы HTML-варианта, который мне почему-то всегда напоминал цвет известного сельскохозяйственного удобрения. Теперь это можно изменить, что я, особо не мешкая, и сделал.  Впрочем, как говорится, на вкус и цвет товарища нет, так что будем условно считать возможную дискуссию на эту тему несостоявшейся.

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

Есть, к сожалению, и не очень приятные новости. Сейчас у меня будет оставаться не так много времени на рассылку, как раньше. Выпуски будут выходить так же регулярно, но, возможно, самую малость пореже. И еще: я не буду делать отдельную текстовую версию, придется положиться на конвертер сервера. Прошу прощения у подписчиков текстового варианта. Понимаю, что звучит банально (я такие утверждения встречал почти в каждой рассылке, а теперь дошел до того, что пишу это сам) но HTML-вариант ДЕЙСТВИТЕЛЬНО гораздо лучше выглядит и занимает ненамного больше времени для загрузки.

MFC

Начать всегда труднее всего, так что, облегчая себе задачу, я решил не начинать все заново и строить "новый мир" на обломках "старого", а просто продолжить с того места, на котором остановился. Итак, если вы помните, в предыдущем (двенадцатом) выпуске, я вам рассказывал о том, как с помощью MFC организовать набор закладок, без которых, замечу, просто немыслим удобный и структурированный интерфейс для диалога с большим количеством различных опций (вновьподписавшимся рекомендую обратиться к архиву рассылки, ссылка на него есть в конце этого выпуска). Кстати, в некоторых книгах закладки называют "вкладками", и некоторые считают, что так правильнее, хотя суть от этого, конечно же, не меняется.

Набор закладок: пара замечаний

Описанный мной в #12 способ организации закладок в принципе работает, но имеет два существенных недостатка, на которые обратил внимание мой хороший друг, программист Bad Sector. Одновременно он подсказал пути их устранения.

Недостаток первый: в фокусе ввода закладки, при нажатии  клавиши "Enter" не происходит передача сообщения родительскому окну, содержащему набор, а идет его обработка "на месте". Это может, в худшем случае, привести к удалению содержимого текущей закладки с экрана, а кнопка по умолчанию родительского диалога не сработает. Сразу скажу, что проблема разрешается перекрыванием PreTranslateMessage(), но есть способ проще и лучше, который я опишу чуть ниже.

Второй недостаток гораздо серьезнее: из-за того, что объекты-страницы закладок у меня создаются и удаляются динамически  во время переключения, состояние их элементов не сохраняется. Это не имеет значения, если у вас там одни кнопки ;) но чаще всего бывает как раз наоборот.

Помните, я вам обещал рассказать про классы CPropertySheet и CPropertyPage? Время первого еще не пришло, а вторым мы сейчас как раз и займемся. Потому как использование его вместо CDialog в качестве родительского класса для наших страниц-закладок МОМЕНТАЛЬНО снимает первую проблему. Сообщение будет передаваться куда надо и как надо. Отметьте, что CProperyPage сама наследует от CDialog, и своим поведением отличается от него  в таких вот ситуациях. А еще обычно как-то упускается из виду, что CPropertyPage можно использовать отдельно, а не в связке с СPropertySheet. 

Таким образом, первый недостаток устранен, перейдем ко второму. Здесь тоже все несложно: необходимо выбрать – либо вы будете хранить настройки каждой из закладок в содержащем их диалоге, и при переключении каждый раз их сохранять/загружать (путь мазохиста). Либо же вы все нужные закладки создадите заранее (в массиве, например), при открытии содержащего их диалога. При его же закрытии, вы, если это необходимо, все нужные данные из классов закладок можете скопировать в отдельные переменные, а затем со спокойной совестью удалить весь набор. В таком случае переключение закладок будет выглядеть следующим образом:

CPropertyPage *m_Pages[];

CTabCtrl m_Tabs;

int m_iLastPage=-1;

...

void CMyDlg::OnSelChangeTab(NMHDR* pNMHDR, LRESULT* pResult) {

 if (m_LastPage != -1) m_Pages[m_iLastPage]->ShowWindow(SW_HIDE);

 int c = m_Tabs.GetCurSel();

 m_Pages[c]->ShowWindow(SW_SHOW);

 m_Pages[c]->UpdateWindow();

 m_iLastPage = c;

 *pResult = 0;

}

ОБРАТНАЯ СВЯЗЬ

Еще письмо на тему отказа работать release-версии программы. И прошу не ворчать, потому что когда сами с такой проблемой встретитесь (скорее всего, когда программу показывать нужно уже через несколько дней), скажете этому человеку спасибо! 

Сам недавно столкнулся с "проблемой Release билда". Естественно, 95% всех подобных багов – это баги с памятью. Проблемы с NULL указателями ещё менее-более отслеживаются, а вот с "перетиранием" памяти – сложнее. 

Я решил эту проблему с помощью _CrtCheckMemory(). Вообще, в Windows есть минимальный набор механизмов для отладки, они все описаны в MSDN 'Debug Routines'. 

Т.е. сначала определяем с помощью внутреннего логгинга примерное место вылета проги – это нужно делать не в Debug build (там-то всё работает :), а в Release. Простой лог можно за полчаса набросать. Если прога не использует DirectX или OGL, то можно (наверное), использовать даже MessageBox. Главное – локализовать место появление бага. Надо сразу заметить, что, как правило, место, где прога вылетает, совсем не то же самое место, где есть баг. В моём случае баг был в инициализации, а валилась функция уже во время работы. Потом работаем с помощью assert(_CrtCheckMemory()); уже в Debug build, где есть дебаггер и всё такое. 

Если программа менее-более линейна и не сильно здоровая, то можно вставить assert( _CrtCheckMemory()); прямо по ходу выполнения, перед и после каждого подозрительного вызова. Он сработает, как только обнаружит поврежденный heap – мы сразу можем видеть где это происходит, и делать выводы. Надеюсь это хоть кому то поможет.

Иван Невраев

Ну вот и все на сегодня. До новых встреч и будьте здоровы!


©Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №14 от 14 сентября 2000 г.

Приветствую вас!

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

ОБРАТНАЯ СВЯЗЬ

Предлагаю вашему вниманию интересное письмо, пришедшее пока я был в отпуске.  В нем затрагивается очень больная тема для всех MFC-программистов:

Я только что подписался на Вашу рассылку и прочитал весь архив. В первую очередь хочу присоединиться ко всеобщим поздравлениям (хоть и с нескольким опозданием) и поблагодарить Вас за то что принялись за столь нелегкий и, насколько я понимаю, практически бесприбыльный труд. Так уж получилось, что в этой области работает очень много профессионалов и любителей, поэтому вопросов накопилось очень много. Я крайне рекомендую Вам почаще направлять вопрошающих на microsoft.public.ru.vc и microsoft.public.ru.russian.programming, где подобные вещи более уместны. Хоть это и самые активные русскоязычные конференции на тему, но они недотягивают то своих западных конкурентов, поэтому свежая кровь им явно не повредит.

[…] К делу: Может я и ошибаюсь, но насколько я знаком с психологией Microsoft, можно судить, что MFC доживает свои последние дни. Она морально устарела, скорее всего эта библиотека уйдет в небытие "оставлено для совместимости" уже со следующей версией VS. Я очень хочу, чтобы Вы в своей рассылке обратили внимание на WTL (Windows Template Library) – это библиотека шаблонов похожая на ATL, способная частично (или полностью) заменить MFC. Она входит в Platform SDK начиная с Jan'2000. Пока это пробный камень, поэтому практически недокументирована. Microsoft не слишком афиширует ее появление, и те немногие программисты, которые ее используют, вынуждены разбираться во всем самостоятельно. А выгод при ее использовании очень много. Например она значительно дружественнее к WinAPI, который активно рассматривается в рассылке, чем MFC. Возможно с выходом следующей версии VS WTL будет дополнена или даже изменена и выставлена как основное средство разработки приложений в VC, так как больше отвечает предназначению C++ – созданию компактных, быстрых и эффективных приложений. Именно по этим причинам я считаю очень полезным рассмотреть эту библиотеку в рассылке, а в будущем, возможно, уделить ей больше внимания чем MFC.

Ярослав Говорунов

Итак, есть два вопроса. Вопрос первый – что будет с MFC в будущем?  Вопрос второй : что это еще за зверь – WTL?

На первый этих двух вопросов не существует однозначного ответа. Если я разверну дискуссию на эту тему в рассылке, то наверное вы не скоро дождетесь ее окончания, настолько это острый вопрос. Скорую смерть MFC предсказывали не раз и не два, но почему-то эта смерть все никак не наступит. Даже наоборот, сейчас трудно найти объявление о найме программиста на C++ под Windows, где не требовалось бы знание MFC (и чаще всего еще и ActiveX/COM). Работодатели задают тон, и поэтому MFC и сейчас так же популярен, несмотря на всю свою нелогичность, неудобство, малонадежность и множество других недостатков. Наверное, пока что его доствоиства (а они, надо признать, все-таки есть) плюс усилия всемогущей Microsoft по его поддержке перевешивают. Да и в обозримом будущем, скорее всего, ситуация мало изменится – в следующую версию Visual Studio (о которой я писал в выпуске №8) MFC, вне всякого сомнения, войдет. Будет ли это в виде "оставлено для совместимости"? Я думаю, вряд ли. MFC cлишком уж широко используемая библиотека. Хотя это, конечно, не более чем мое личное мнение.

А вот второй вопрос действительно интересен. Неужели появилась достойная альтернатива MFC? Чтобы каждый из вас сам ответил для себя на этот вопрос, хочу предложить вашему вниманию статью Ричарда Граймса, на которую я наткнулся в интернете, и она мне настолько понравилась, что я решил специально для вас ее перевести и опубликовать. Что я и делаю с любезного разрешения автора статьи.

СТАТЬЯ ЧТО ТАКОЕ WTL?

Автор: Ричард Граймс
Источник: iDevResource.com Ltd.
Оригинал: "What is WTL?" by Richard Grimes
Пер. с англ. Алекс Jenter
Вступление 

О WTL шепчут уже более года, и был даже пущен слух, что эта библиотека используется внутри самой Microsoft, и что она базируется на ATL. Конечно же, это привлекло внимание сообщества ATL-разработчиков, которые создавали пользовательский интерфейс для элементов управления ATL еще со времени появления ATL 1.1, и обнаруживали, что код, который они писали, был большей частью чистым кодом Win32 GDI. Я могу кое-что вам сообщить: WTL построен по такому же принципу.

Является ли это разочарованием? Нет, потому что сама ATL – всего лишь тонкая обертка COM, и в этом-то и заключается ее сила. Конечно, вам необходимо знать COM для того, чтобы использовать ATL, но дополнительные усилия, затраченные на изучение ATL пренебрежимо малы по сравнению с теми, которые нужны для освоения COM. Сравните это с другими библиотеками классов, где основной упор делается на изучение самой библиотеки, а что вы фактически будете знать по окончании обучения? Не так уж много о COM, это определенно.

С WTL все в принципе так же. Вы должны уметь программировать, используя Win32 и GDI. Но если вы это знаете, тогда WTL для вас – не более чем глоток свежего воздуха. Если же вы не имеете представления о Win32 и GDI, тогда лучше вам писать пользовательский интерфейс на VB.

Что включает в себя WTL? 

Библиотека имеет основной набор классов для приложения. Заметьте, что хотя у вас нет классов-документов (documents), как в MFC, у вас все еще есть классы-представления (views). В WTL очень много кода, предназначенного для того, чтобы позволить вам манипулировать представлениями, а также легко добавлять ваш собственный код. Существует свой мастер AppWizard, с помощью которого можно легко создавать каркасы SDI-, MDI– и многопоточных SDI-приложений (т.н. Multi-SDI-приложение выглядит, как будто открыто много экземпляров обычного SDI-приложения, но на самом деле это разные окна одного и того же процесса. Примером такого приложения может служить IE или Windows Explorer). Плюс к этому, ваша программа может быть приложением на основе диалога (dialog-based) или на основе представления (view-based). Сами представления могут быть основаны на классе CWindowImpl, на каком-либо элементе управления, или даже на HTML-странице. Вы также можете выбирать, будет ли ваше приложение иметь панель инструментов в стиле IE (rebar), в стиле Windows CE (command bar), или простую (toolbar); можно добавить строку статуса (status bar). Ваше приложение может внедрять элементы управления ActiveX и может быть COM-сервером.

Есть выбор среди нескольких видов классов-представлений, которые вы можете использовать. WTL представляет классы окон с разделителями (splitter-window), так что вы можете иметь два окна в одном представлении, и классы окон с прокруткой (scroller-window), где окно может быть меньшего размера, чем представление, которое оно отбражает. Существует также некий аналог UpdateUI из MFC, хотя в WTL он работает немного по-другому – основное отличие в том, что вы сами указываете, какие элементы могут обновляться посредством карты сообщений (message map), и вы должны добавить код в ваш класс, чтобы выполнить UpdateUI. Библиотека поддерживает технологии DDX/DDV, которые, опять же, очень похожи на их аналоги из MFC, с той только разницей, что у вас есть карта сообщений, которая реализует DoDataExchange и вам нужно добавлять код для осуществления этой операции.

Присутствуют теперь и классы GDI. Класс-оболочка HDC очень похож на CWindow в том, что очень тонок, – добавляет мало новой функциональности. Тем не менее, в нем есть поддержка метафайлов и OpenGL. Я думаю, основное применение будут иметь классы-наследники для работы с принтерными контекстами устройства – в WTL есть поддержка печати и даже предварительного просмотра (print preview). Имеются также классы-обертки для GDI-объектов, кистей (brushes), перьев (pens), регионов (regions), и т.д.

Еще в библиотеке можно обнаружить классы для всех стандартных Win32 и W2K (Windows 2000) диалогов (common dialogs), опять же, хотя эти обертки довольно тонки, они делают задачу выбора шрифта или, скажем, файла действительно простой.

Старый файл AtlControls.h  был включен из ATL в WTL, и содержит несколько новых классов для элементов управления W2K, наряду с некоторыми классами для элементов управления, не относящихся к Win32, таких как клон панели команд (command bar clone), кнопка с изображением (bitmap button), гиперссылка (hyperlink) и курсор "песочные часы" (wait cursor). […]

И, наконец, в библиотеке имеются служебные классы, самым значимым из которых является CString. Да, это клон класса CString из MFC, который реализует (насколько я знаю) все его методы. Еще есть класс-оболочка для поиска файлов (find file API) и классы-аналоги CRect, CSize и CPoint.

Резюме 

Если вы собираетесь писать Win32-приложение с пользовательским интерфейсом, я рекомендую вам попробовать WTL прежде чем думать об MFC. Если вы пишете код в WTL, он будет меньше в объеме и более эффективен, и вы будете иметь все преимущества поддержки COM в ATL, которая, увы, отсутствует в MFC. 


Итак, WTL – очень перспективная библиотека на основе ATL, которая, однако, НЕ ИЗБАВЛЯЕТ вас, как программиста, от необходимости знания WinAPI. И я могу привести кучу доводов в пользу такой архитектуры, многие из которых достаточно очевидны. Но, как всегда, есть и аргументы contra. MFC намного мощнее, и имеет намного больше возможностей. Из них, в частности, модель "документ/представление", поддержка документов OLE, автоматизированный обмен данными, пристыковывающиеся панели/диалоги и многое другое.

Объем кода, который вам приходится писать самому, в WTL больше.

Не думайте также, что в WTL нет ошибок: как показывает практика, их там тоже полным-полно (я видел список известных на данный момент багов). Библиотека еще сыровата. Так что не следует переоценивать WTL, но и спускать со счетов тоже не стоит. Конечно, она пока не стала стандартом и официально Microsoft не поддерживается. Но, как говорят на западе, things can change. В нашей профессии всегда приходится держать ухо востро на все инновации, т.к. они имеют неприятную особенность становиться стандартами.

А что касается рассмотрения WTL в рассылке: в принципе я не против, если вы не против. Смущает меня только одно: тем для рассылки становиться настолько много, что впору было бы создавать несколько рассылок, – одну про WinAPI, другую про MFC, третью про WTL, и т.д. Знаю, многие сочтут это просто отличной идеей, т.к. смогут подписаться именно на то, что их интересует. Но, к сожалению, я один, и физически не смогу все эти рассылки готовить, а помощников нет. Конечно, я буду стараться осветить самое важное и интересное. Как кто-то сказал, "нельзя объять необъятное… а если и можно, то только по частям и не сразу" ;) Так что давайте договоримся: пока будем придерживаться общепринятого стандарта – C++, WinAPI и MFC. А WTL (или C#, или чем-то другим) займемся, когда ее название будет фигурировать в объявлениях типа "требуется программист" чаще, чем MFC.

АНОНС 

Читайте в следующем выпуске рассылки:

• Как правильно писать программы на C++: некоторые правила, которые помогут вам писать легко читаемый код.

• Рубрики "Вопрос-ответ" и "В поисках истины".

Также планируется в последующих выпусках:

• CPropertySheet: создание окон свойств и мастеров.

• Массивы, списки и ассоциативные списки. Общие положения и реализация в MFC.

• Решение проблемы с OnIdle в dialog-based приложениях.

• Работа с панелью инструментов. Задание вида кнопок и размещение отличных от кнопок элементов.

• Постоянные рубрики "Вопрос-ответ", "В поисках истины" и "Обратная связь". 


До встречи!

©Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №15 от 18 сентября 2000 г.

Доброе время суток!

Сегодня мы с вами поговорим о такой вещи, как стиль программирования.

Легко читаемый код  и надежность программ

Если вам когда-нибудь приходилось разбираться в чужой программе, или даже в своей собственной, но написанной несколько лет назад, да еще когда поджимает время, вы скорее всего знаете, какая это неприятная и сложная задача. Порой бывает легче весь код написать заново (а многие так и делают). Конечно, существует поговорка "настоящие программисты не пишут комментарии: если программу было трудно написать, в ней должно быть трудно что-то понять и еще труднее что-либо изменить". О комментариях мы еще поговорим, печально то, что очень многие следуют этому принципу в самой программе. "Неважно", думают они, "как это написано, главное побыстрее проверить, работает ли это вообще". Самые прилежные из них впоследствии переписывают отдельные куски кода, но таких единицы. Большинство же, убедившись в работоспособности алгоритма, оставляют все как есть и переходят к новым задачам.

Как показывает многолетняя практика, это большая ошибка. Усилия, потраченные на "причесывание" кода, окупаются с лихвой. Но по-настоящему ценится умение писать сразу такой код, который не нуждается в причесывании. Это умение не приходит само по себе, а вырабатывается постепенно, в нем надо постоянно практиковаться. И когда вы говорите себе "а, это ведь просто небольшая утилитка для удобства, вот когда получу настоящий заказ – буду писать красиво", вы тем самым приучаете себя к неправильному стилю написания программ.

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

Вот несколько практических советов и рекомендаций. Профессионалам многие из них покажутся очевидными, но для новичков, я считаю, будут очень полезны.

1. Обязательно соблюдайте отступы. Хотя Visual C++ и делает отступы автоматически, иногда они все же нарушаются. С их помощью сразу видна структура программы.

Кстати, многие знают, что для того, чтобы подвинуть блок текста вправо, нужно выделить его и нажать Tab, но почему-то даже не догадываются, что если нажать Shift-Tab, текст сдвинется влево! Попробуйте, это очень удобно. Лучше вместо символа табуляции использовать пробелы (Tools|Options|Tabs|Insert Spaces). Тогда ваши программы в любом редакторе будут с корректными отступами.

2. Про комментарии в коде я ничего говорить не буду… ну, почти ничего. Все, что можно было сказать, уже сказано до меня. Все равно лень людям их писать. Одно только вам посоветую: если уж сильно неохота сочинять комментарии 50/50 с кодом – все-таки постарайтесь самые ключевые и/или неочевидные моменты отмечать.

И запомните: неряшливый и запутанный код нужно не комментировать, а переписывать!

3. Именованные константы пишите в верхнем регистре, чтобы можно было мгновенно отличить их от переменных. Например, MAX_ELEMENTS и BORDER_WIDTH, а не Max_Elements и border_width.

4. Имена переменных начинайте с маленькой буквы, названия типов – с заглавной.

5. Глобальные переменные по написанию должны отличаться от обычных. Как правило, для этого используют префикс "g_": g_RefCount, g_BaseDir. Вообще, их количество следует минимизировать. Статические переменные можно обозначать суффиксом "s_", члены классов- "m_".

6. Переменным, имеющим длительный период существования, следует давать длинные имена. Локальным и временным переменным можно давать имена покороче.

7. Помните, что объект всегда подразумевается, т.е. не нужно повторять имя объекта в его методе. Например, MyObject->GetObjectColor() – эту функцию следует назвать просто GetColor().

8. Вкладывайте смысл в имена функций. Используйте слово "find" когда где-то что-то ищется, "get" когда что-то хотите получить, "set" — установить. "Initialize" или "init" – инициализация, "compute" – вычисление, "open/close" – открытие/закрытие, и т.д.  Также в паре следует использовать следующие имена: add/remove, create/destroy, start/stop, insert/delete, increment/decrement, old/new, begin/end, first/last, up/down, min/max, next/previous, old/new, open/close, show/hide. Т.е. если вы одну функцию назвали AddTitle(), то противоположную по действию надо назвать не DestroyTitle() или DeleteTitle(), а RemoveTitle().

9. Перед именами переменных, представляющих количество чего-то, ставьте префикс "n": nColors, nItems. Переменные, обозначающие порядковый номер чего-то, дополняйте суффиком "No": RecordNo, LineNo.

10. Не злоупотребляйте сокращениями. Согласитесь, что, например, смысл GetListAverage() гораздо легче понять, чем GetLstAvg() (ведь это, в принципе, может обозначать и GetLastAvenger() ;-).

11. Избегайте логических переменных, обозначающих отрицание. Found, а не notFound; Good, а не notGood. Вообще, хорошим стилем считается дополнять логические переменные префиксом "is": isFound, isGood. Это же относится к функциям, возвращающим значение true/false, напр. IsKindOf().

12. Константы из типов-перечислений (enum) должны содержать имя типа. COLOR_BLUE, а не BLUE; FILE_ERROR_ALREADY_EXISTS, а не ALREADY_EXISTS.

13. Всегда приводите типы к нужным явно, не полагаясь на автоматику.

14. Переменные, связанные между собой по смыслу, можно объявлять одной строкой:

int x, y, z; 

Record first, last, next, previous;

Никак не связанные переменные лучше объявлять на разных строках, даже если они одного типа.

15. В пустых циклах хорошо явно прописывать continue. Этим вы показываете, что оставили цикл пустым нарочно, а не по ошибке. Пример: while (*p++ = *q++) continue;

Ну, хватит пожалуй. Если кто-то особенно заинтересовался этим вопросом, он может посмотреть более чем 70 подобных правил в Geosoft's C++ Programming Style Guidelines.

Должен заметить, что далеко не со всеми положениями этого документа я согласен. Например, я не считаю нужным обязательно начинать имена функций с маленькой буквы, – действительно важно различать переменные и типы, а функцию от типа отличить гораздо легче. Или еще, например, правило всем private-членам классов давать суффикс "_" — ну вот не нравится и все тут…  Я здесь привел самые, на мой взгляд, нужные и, прошу прощения за тавтологию, "правильные" правила; те, которые встречаются практически во всех документах такого типа.

Так что дам еще один, последний, совет: подходите ко всем правилам, необходимость которых для вас не очевидна, с некоторой толикой здравого смысла.

ВОПРОС-ОТВЕТ

Q. Как в VC++ 6.0 можно сделать окно, которое не будет видно на Taskbar'e?

Kirill

A. Самый простой способ – это создать основное окно с расширеным стилем окна WS_EX_TOOLWINDOW:

hWnd = CreateWindowEx(WS_EX_TOOLWINDOW, szWindowClass, szTitle,  WS_OVERLAPPEDWINDOW, 0, 0, 100, 100, NULL, 0, hInstance, NULL);

При использовании MFC следует перекрыть метод PreCreateWindow():

BOOL CMainFrame::PreCreateWindow(CREATESTRUCT& cs) {

 if (!CMDIFrameWnd::PreCreateWindow(cs)) return FALSE;

 cs.dwExStyle=WS_EX_TOOLWINDOW;

 return TRUE;

}

Но такое решение не всегда приемлемо – у созданного таким образом окна на тайтлбаре может находится только кнопка закрытия, и его заголовок отличается от заголовков других окон (он меньше). Для того, чтобы исправить эти недостатки, сначала создаем невидимое окно со стилем WS_EX_TOOLWINDOW, а затем дочернее окно, которое будет выполнять роль основного окна приложения. Это будет выглядеть следующим образом:

//…

HWND hWnd1,hWnd2;

hInst = hInstance;

hWnd1 = CreateWindowEx(WS_EX_TOOLWINDOW, szWindowClass1, szTitle, 0, 0, 0, 100, 100, NULL, 0, hInstance, NULL); // cоздаем невидимое окно

// создаем окно, которое будет основным; указываем hWnd1 в кач.родителя:

hWnd2 = CreateWindowEx(0, szWindowClass2, szTitle, WS_OVERLAPPEDWINDOW, 0, 0, 100, 100, hWnd1, 0, hInstance, NULL);

ShowWindow(hWnd1, FALSE); // скрываем 1-ое окно

UpdateWindow(hWnd1);

ShowWindow(hWnd2, nCmdShow); // делаем дочернее окно видимым

UpdateWindow(hWnd2);

Bad Sector

Небольшое дополнение: Если вам нужно убирать кнопку с таскбара только тогда, когда ваше приложение минимизировано (например, чтобы реализовать функцию "минимизировать в системный трей"), то все становится гораздо проще. Достаточно в обработчике OnSysCommand поставить реакцию на минимизацию окна (т.е. когда параметр nID равен SC_MINIMIZE вызывать ShowWindow(hWnd, SW_HIDE)). А при получении соответствующего сообщения от иконки в трее, не забывать восстановить окно. (про работу с системным треем см. выпуск №11).

В ПОИСКАХ ИСТИНЫ

Q. В Visual C++ 6.0  создаётся ImageList с помощью ImageList_LoadImage. Потом две загруженные картинки рисуются в окошке – сначала одна, потом поверх неё другая (используется маска) – функция ImageList_Draw. Проблема в том, что рисуется только в 16 стандартных цветах. Картинка 24-битная. Пробовал и с 256 и 16-цветными, с использованием палитры – эффект тот же. Если не сложно, подскажи, как её нарисовать в 16M цвете (использую только API, без MFC)?

Дрон

Всего вам доброго и не скучайте!

©Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №16 от 23 сентября 2000 г.

Здравствуйте!

Э-э-х, непростая у нас, программистов, профессия! Иногда просто откровенно завидуешь медикам, лингвистам, архитекторам, ученым и всем остальным, которые отучились в институте – и могут спать спокойно: если что-то принципиально новое и появляется в их области, то не слишком часто и точно не слишком помногу. 

У нас же в одночасье, иногда по хотению и велению только ОДНОЙ фирмы, все может перевернуться с головы на ноги (чаще наоборот), и вот ты обнаруживаешь, что никакой ты не специалист, – тебе надо еще учиться, учиться и учиться (не помню кто сказал ;)

Когда смотришь объявления о работе для программистов, частенько кружится голова от всяких аббревиатур и названий на английском языке – MFC, ATL, COM, ASP, PHP, SQL, HTML, DHTML, XML, UML, VB, VBA, VBScript, C++, Java, JavaScript, Perl, CGI, TCP/IP, OpenGL, DirectX и пр. и пр. Кстати, я в парочке объявлений уже заметил C# , хотя он еще даже не вышел!

И вот видишь в объявлении совершенно непредсказуемую комбинацию из четырех-пяти вышеперечисленных названий, и думаешь – неужели есть кто-то, кто это все знает? Да еще имеет 2-3 года опыта работы с этим? 

А вот в том-то и дело, что таких людей не слишком много. Есть один практический совет: если вы хотя бы на 60% удовлетворяете требованиям работодателя, посылайте резюме!

Мне могут возразить, что мол старые технологии остаются востребованными всегда, наряду с новыми. Я скажу одно: когда вы последний раз видели, чтобы требовался программист под MS-DOS? А я помню время, когда под Windows (тогда еще 3.1) программировали считанные единицы (и то все считали это недостойным занятием), а большинство работало именно в DOS.

Утешить может только одно: постигая что-то конкретное, мы также постигаем общий принцип, по которому это конкретное сделано. А вот знание общих принципов, господа – действительно помогает. Уже зная пару-тройку языков, новый язык программирования вполне реально изучить за две недели, за месяц – писать на нем сносные программы, за полгода – стать профессионалом. Только через полгода обязательно появится еще что-нибудь новое…;) Поэтому люди сейчас поступают умнее: они осваивают новое еще ДО того, как это новое появится. Нет, они вовсе не путешествуют во времени…

Статья про WTL в 14-ом выпуске не осталась незамеченной. Некоторые заитересовались этой темой, некоторые захотели высказать свое мнение. Вот одно из таких писем:

Добрый день (вечер, ночь, утро) Алекс и подписчики "Программирование на Visual C++" (в случае, если мое письмо опубликуют в рассылке).

После прочтения выпуска No.14 у меня появилась пара мыслей по поводу будущего MFC и WTL. Точнее, мысли эти у меня есть давно (месяца два-три), возможно, вы об этом тоже знаете. То, что MFC умирает – это факт. С самого начала она была мертворожденной. Постоянные баги, внутренняя сложность, обилие недокументированных внутренних структур и функций – все это не делает библиотеку хорошей. Я уже не говорю о ее монстрообразности. Да, с ней удобно работать. Но стоят ли проблемы удобства? Можно говорить очень долго о достоинствах и недостатках MFC, но факт остается фактом: будущего у нее нет.

Что касается WTL, то здесь тоже все непросто. Точнее, если верить одному из мэнэджеров Майкрософт (к сожалению, не помню кто), то все очень просто: у WTL будущего тоже нет. В одном из выступлений он заметил, что WTL не будет поддерживаться Майкрософт. Правда, не исключено, что WTL получит свое развитие.

Ну и последнее. Я думаю, все слышали о проекте Майкрософт .NET. Я занимаюсь им в свободное время и могу сказать одно: это действительно отличная вещь. Пока еще сырая, нет даже беты, но уже в следующем обновлении MSDN (октябрь) должна появиться Visual Studio 7 Beta (или Visual Studio.Net). Не хочу рассказывать о .NET, не для маленького письма тема, к тому же, я не настолько хороший лектор, как Jeffrey Richter и Don Box. Поэтому всем, кто интересуется, могу посоветовать пару ссылок: http://www.msdn.microsoft.com/net/, http://www.andymcm.com/ и замечательный список рассылки DOTNET на http://discuss.develop.com.

Alex Ivanoff
ВОПРОС-ОТВЕТ

Q1  В Visual C++ 6.0  создаётся ImageList с помощью ImageList_LoadImage. Потом две загруженные картинки рисуются в окошке – сначала одна, потом поверх неё другая (используется маска) – функция ImageList_Draw. Проблема в том, что рисуется только в 16 стандартных цветах. Картинка 24-битная. Пробовал и с 256 и 16-цветными, с использованием палитры – эффект тот же. Если не сложно, подскажи, как её нарисовать в 16M цвете (использую только API, без MFC)?

Дрон

A. Насколько я понимаю, в функцию ImageList_LoadImage следует передать флаг LR_CREATEDIBSECTION, чтобы избежать преобразований цветов в изображении.

Например:

HIMAGELIST hImageList;

hImageList = ImageList_LoadImage(hInstance, MAKEINTRESOURCE(IDB_BITMAP1), 100, 0, CLR_NONE, IMAGE_BITMAP, LR_CREATEDIBSECTION);

Alexander Shargin

Такой же ответ на этот вопрос прислал David Potashinsky. Большое спасибо всем, кто откликнулся.

У меня выдалось немного свободного времени, поэтому следующий вопрос я не стал помещать в рубрику "В поисках истины", а ответил на него сам:

Q2 Меня попросили сделать страничку свойств (CPropertySheet), которая является главным окном приложения, минимизируемой. Означенная просьба неожиданно оказалась не столь простой как кажется на первый взгляд. Добавить собственно значок минимизации – нет проблем: в CPropertySheet::OnInitDialog добавляем ModifyStyle(0, WS_MINIMIZEBOX). Одно плохо – не работает он.

Олег

A. Сначала скажу, что эта идея – property sheet в качестве главного окна приложения – довольно неудачная. Сейчас объясню, почему. С точки зрения Windows Ваше приложение является не окном в полном смысле слова, а диалогом, причем таким диалогом, кнопка которого на панель задач не выводится. Т.о. при минимизации произойдет вовсе не то, что Вы ожидали – он минимизируется а-ля windows 3.1 (или как дочернее окно MDI) – в левый нижний угол.

Можно конечно ухитриться и сделать так, чтобы показывалась кнопка на таскбаре (см. предыдущий выпуск), но приемлемый, на мой взгляд, выход в данной ситуации – минимизировать в системный трей.

Теперь – что надо сделать, чтобы кнопка минимизации заработала:

При нажатии на эту кнопку для такого окна генерации события  WM_SYSCOMMAND не происходит, и обрабатывать его нет смысла. Поэтому в класс-наследник CPropertySheet нужно добавить обработчик события WM_NCLBUTTONDOWN (non-client left button down, это событие происходит, когда нажимается левая кнопка мыши в неклиентской области окна,  а значок минимизации как раз и находится в этой области):

void CMinSheet::OnNcLButtonDown(UINT nHitTest, CPoint point) {

 // TODO: Add your message handler code here and/or call default

 CPropertySheet::OnNcLButtonDown(nHitTest, point);

 if (nHitTest == HTMINBUTTON) {

  IsIconic()? ShowWindow(SW_RESTORE): ShowWindow(SW_MINIMIZE);

 }

}

Заметьте, что в свернутом состоянии кнопка минимизации (minimize) становится кнопкой восстановления (restore).

Повторю, в этом случае минимизироваться диалог будет в левый нижний угол. Лучше всего вместо минимизации его прятать [ ShowWindow(SW_HIDE); ] и выводить иконку в трее (как это делать см. выпуск рассылки №11).

Если кто-то из вас, уважаемые подписчики, не согласен в чем-то с этим ответом, или есть какие-нибудь дополнения – обязательно напишите.

Подробно про класс CPropertySheet вы сможете прочитать в следующем выпуске.

В ПОИСКАХ ИСТИНЫ

Q. Возникла вот такая задачка. Имеется некоторое разбиение SDI на несколько view при помощи сплиттеров (A). Как его изменить не убивая окна (на B или C)?

  +--+----+     +--+----+    +--+----+

  |  |    |     |  |    |    +  +    +

  +--+----+     +--+    |    +  +----+

  |       |     |  |    |    +  +    +

A +-------+   B +--+----+  C +--+----+

Nikita Zeemin

До встречи!

©Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №17 от 29 сентября 2000 г.

Всем привет!

До меня дошли сведения, что предыдущий, 16-тый, выпуск дошел почему-то не до всех подписчиков. То ли из-за глюков на ГорКоте, то ли из-за гиперактивности магнитных бурь … ;)

Повторно высылать я его, пожалуй, не стану, лучше дам вам на него прямую ссылку. Тем, кто его еще не видел, рекомендую прочитать,так как данный выпуск связан с предыдущим.

MFC

Итак, наконец-то мы добрались до темы создания окон свойств, которые в MFC реализуются с помощью, как вы уже догадались, класса CPropertySheet.

Работа с окнами свойств : использование класса CPropertySheet

Как известно, практически во всех более-менее серъезных программах есть диалоговые окна настройки параметров, или опций, приложения. Такие окна получили название окон свойств. Чтобы увидеть одно из таких окон, достаточно выбрать Tools|Options в Visual C++ IDE.

Задача создания окон свойств стоит практически перед каждым разработчиком, именно поэтому в MFC решение этой проблемы в некоторой степени автоматизировано с помощью класса CPropertySheet. В результате его применения вы получаете готовое диалоговое окно с набором закладок и некоторым количеством стандартных кнопок – OK, Cancel, и т.д. Закладки здесь – это объекты типа CPropertyPage. Этот класс, кажется, уже фигурировал в одном из выпусков. Никогда не путайте CPropertySheet и CPropertyPage: помните, что первый (CPropertySheet) СОДЕРЖИТ вторые (CPropertyPage) так же, как книга содержит страницы.

Так, с этим разобрались, идем дальше. Как пользоваться классом CPropertySheet? Очень несложно, вы в этом сами сейчас убедитесь.

Для каждой закладки нужно создать диалоговый ресурс (не обязательно со стилем child), куда вы помещаете все содержимое соответствующей страницы (также, как и при работе с CTabCtrl). Например, IDD_PROPPAGE1 и IDD_PROPPAGE2ROPPAGE2. Можно сразу заполнить поле Caption в диалогах, чтобы потом заголовки закладок сформировались автоматически.

В проект добавляется класс-наследник от CPropertySheet, пускай он называется CMyPropSheet.

Для того, чтобы можно было работать с контролами на закладках, добавляется отдельный класс для каждой страницы-закладки (наследованный от CPropertyPage). Например, для двух закладок это будут классы CPropPage1 и CPropPage2 (эти классы добавьте дабл-кликнув на поверхности соответствующего диалога и выбрав "Create a new class", затем в поле "Base class" выберите CPropertyPage в качестве класса-родителя). В эти классы нужно поместить члены, связанные с контролами, расположенными на странице. Например, если у нас на первой странице (IDD_PROPPAGE1) есть Edit Box, добавляем в класс CPropPage1 переменную m_strEdit класса CString, доступ – public. Пусть на второй странице у нас Check Box, значит в класс CPropPage2 записываем член m_isChecked типа BOOL, и т.д. Использование типа доступа public к этим полям в данном случае оправданно, т.к. избавляет в дальнейшем от многих хлопот. И не забывайте, эти члены класса должны быть связаны с соответствующими контролами на закладке.

Теперь в файл mypropsheet.h (где объявлен класс CMyPropSheet) пишем:

#include "proppage1.h" // делаем классы страниц видимыми

#include "proppage2.h"

class CMyPropSheet: public CPropertySheet {

 …

protected:

 CPropPage1 page1; // первая страница

 CPropPage2 page2; // вторая страница

 …

}

Чтобы добавить страницы к окну свойств, необходимо в каждый из конструкторов CMyPropSheet вставить по две следующие строчки:

AddPage(&page1);

AddPage(&page2);

Таким образом, мы сделали страницы-закладки частью нашего окна свойств. Настал момент теперь решить, где вы собираетесь хранить настройки вашего приложения. Я это обычно делаю в классе главного окна, по причине легкости доступа, но ничто не мешает вам хранить их там, где удобнее, причем не обязательно все вместе. Неплохой вариант – хранить их в классе приложения, даже с некоторой точки зрения он более логичный.

Но предположим, вы решили хранить их в классе главного окна, а чтобы они не перемешивались с другими полями класса, объединить их в структуру:

class CMainFrame: public CFrameWnd {

 …

public:

 struct Options {

  CString str;

  BOOL val;

 } options;

 …

}

В конструкторе CMainFrame поля структуры options установите в начальные значения. Их можно задать жестко, но обычно сохраненные ранее значения загружаются из файла или реестра , иначе вы быстро доведете пользователя вашей программы до белого каления, заставляя его менять параметры после каждого запуска.

Теперь вставьте обработчик события, возникновение которого должно приводить к выводу на экран вашего окна свойств (например, выбор пункта меню "Сервис|Параметры…"). В обработчике вы устанавливаете параметры, после чего выводите окно свойств. Если пользователь нажал "OK", то после закрытия окна свойств нужно обновить структуру options:

#include "mypropsheet.h"

void CMainFrame::OnToolsOptions() {

 CMyPropSheet ps("Параметры приложения", this, 0);

 ps.page1.m_strEdit = options.str;   // настраиваем закладки

 ps.page2.m_isChecked = options.val; // соответственно текущим параметрам

 if (ps.DoModal() == IDOK) // если пользователь нажал OK

 {

  options.str = ps.page1.m_strEdit; // сохраняем параметры

  options.val = ps.page2.m_isChecked;

 }

}

Вот и все, что касается элементарного использования класса CPropertySheet для создания окна свойств. Как видите, работать с ним довольно просто. В одном из следующих выпусков я расскажу вам о задействовании кнопки "Применить" ("Apply"), о нетривиальном использовании этого класса для создания мастеров (wizards), а также о расширенном классе CPropertySheetEx.

ВОПРОС-ОТВЕТ

Q. Возникла вот такая задачка. Имеется некоторое разбиение SDI на несколько view при помощи сплиттеров (A). Как его изменить не убивая окна (на B или C)?

  +--+----+     +--+----+    +--+----+

  |  |    |     |  |    |    +  +    +

  +--+----+     +--+    |    +  +----+

  |       |     |  |    |    +  +    +

A +-------+   B +--+----+  C +--+----+

Nikita Zeemin

A. Для создания окна сплиттера в MFC служит класс CSplitterWnd. Этот класс предоставляет функции для создания вида (CreateView) и удаления вида DeleteView) в заданной панели, но не предоставляет функции, которая позволила бы перенести вид из одной панели в другую. Чтобы проделать это вручную, нужно понимать, каким образом связаны объект класса CSplitterWnd и объекты дочерних видов CView.

CSplitterWnd может иметь не более 16 панелей по горизонтали и столько же по вертикали. Таким образом, он может сожержать не более 256 панелей. Каждой панели соответствует уникальный идентификатор, который и назначается тому виду, который в этой панели находится. Отображение координат панели на её идентификатор выполняет функция int CSplitterWnd::IdFromRowCol(int row, int col);

На самом деле после целой серии ASSERT'ов она просто возвращает значение

AFX_IDW_PANE_FIRST + row * 16 + col

где AFX_IDW_PANE_FIRST — константа, объявленная в MFC.

Это подсказывает простой способ перемещения вида из одной панели в другую: нужно всего лишь подменить его идентификатор, после чего вызвать CSplitterWnd::RecalcLayout для обновления содержимого сплиттера. Если изначально вид не являлся дочерним окном сплиттера и требуется поместить его в одну из панелей, то необходимо также поменять ему родителя с помощью функции CWnd::SetParent. Таким образом функция, вставляющая вид в заданную панель, может выглядеть примерно так:

class CMySplitter : public CSplitterWnd {

 …

 void InsertView(int nRow, int nCol, CWnd *pView) {

  pView->SetParent(this);

  pView->SetDlgCtrlID(IdFromRowCol(nRow, nCol));

 }

 …

}

Аналогичным образом вид переносится "в юрисдикцию" главного окна приложения, порождённого от CFrameWnd:

class CMyFrame : public CFrameWnd {

 …

 void InsertView(CWnd *pView) {

  pView->SetParent(this);

  pView->SetDlgCtrlID(AFX_IDW_PANE_FIRST);

 }

 …

}

Имея в руках эти две функции, можно без труда решить поставленную задачу, располагая виды как на рис. A, B, C или любым другим способом. Ещё раз замечу, что после всех перемещений необходимо вызывать CSplitterWnd::RecalcLayout и CFrameWnd::RecalcLayout.

Alexander Shargin
ОБРАТНАЯ СВЯЗЬ

Alexander Shargin, воистину герой сегодняшнего выпуска, в письме с ответом на предыдущий вопрос также недоумевал по поводу вопроса прошлого выпуска, где требовалось минимизировать CPropertySheet:

…Честно говоря, я не понимаю, о чём идёт речь. Я буду очень вам признателен, если вы объясните мне, в чём проблема. Дело в том, что я создал визардом приложение на базе диалога, а затем просто заменил диалог на объект класса CMySheet, порождённого от CPropertySheet. После чего добавил пару вкладок (типа CPropertyPage) и вызов ModifyStyle(0, WS_MINIMIZEBOX) в обработчике OnCreate. В результате этих несложных операций получилось приложение, главное окно которого без проблем сворачивается на панель задач.

Я посмотрел приаттаченный им проект и убедился, что Александр совершенно прав. После чего я сам проделал то же самое с новым проектом, и получил такой же результат. Итак, вся загвоздка была в том, что ModifyStyle нужно было вызывать не из OnInitDialog, а из OnCreate!

После этого я задумался, откуда же у класса CPropertySheet вообще есть метод OnInitDialog, ведь сам класс является прямым наследником CWnd. Оказалось, что этот метод, наряду с DoModal, был добавлен туда искусственно, чтобы обращение с классом напоминало обращение с CDialog. Не знаю, почему бы Microsoft просто не сделать CPropertySheet наследником CDialog, но наверное у них были свои причины (хотя здесь можно и посомневаться ;)

Я переслал письмо Александра человеку, задавшему вопрос, и получил от него положительный ответ – у него тоже все заработало.

Вот, оказывается, как просто открывался ларчик! Не надо было перехватывать WM_NCLBUTTONDOWN, не нужно было делать callback функцию… (решение автора вопроса)…

И еще – насчет минимизации в левый нижний угол – видимо это был частный случай поведения, вызванный моими манипуляциями со стилями ;-)

Напоследок хочу процитировать Win32 Q&A из MSDN, чтобы абсолютно точно уяснить для всех

Как Windows определяет, нужно ли выводить кнопку приложения на панель задач

Правила эти довольно просты, хотя и не очень хорошо документированы. Когда вы создаете окно, Windows проверяет его расширенный стиль. Если установлен стиль WS_EX_APPWINDOW (определенный как 0x00040000), на панель задач выводится кнопка окна. Если же установлен стиль WS_EX_TOOLWINDOW (0x00000080), то кнопка не выводится. Не следует создавать окна, где установлены оба эти стиля.

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

И последнее замечание: прежде чем тестировать что-либо из вышеописанного, панель задач проверяет, установлен ли стандартный стиль видимости WS_VISIBLE. Если нет, то окно спрятано, и показывать кнопку нет никакого смысла. Стили WS_EX_APPWINDOW, WS_EX_TOOLWINDOW и информация о принадлежности окна проверяются ТОЛЬКО при установленном  WS_VISIBLE.

Jeffrey Richter
В ПОИСКАХ ИСТИНЫ

Q. У меня программа с использованием MFC и Doc/View. Я вставил RichEditCtrl во вью. (2-ой версии). Установил шрифт с помощью сообщения SetCharFormat. Внимание, вопрос: почему если я ввожу текст с клавиатуры и использую ReplaceText функцию (не сообщение!) фонты различные? Вроде это сообщение не менялось у второй версии. Заранее спасибо за ответ.

Игорь

Это все на сегодня. Пока!

© Алекс Jenter mailto:jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №18 от 7 октября 2000 г.

Приветствую вас!

После публикации статьи про CPropertySheet меня обвинили в чрезмерной ориентированности на начинающих программистов (на самом деле было использовано другое слово). Так что материал этого выпуска как раз для чуть-чуть более "продвинутых".

И еще, хочу чтобы вы приняли к сведению: я отвечаю НЕ НА ВСЕ приходящие письма. Когда вы присылаете мне вопрос, не нужно рассчитывать на то, что я обязательно на него отвечу или помещу в рубрику "В поисках истины".

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

MFC

Сегодня я хочу представить вашему вниманию статью – перевод из MSJ C++ Q&A, которую прислал Илья Простакишин.

Решение проблемы с OnIdle в dialog-based приложениях

Проблема в том, что OnIdle работает нормально только в приложениях document/view, что не скажешь о приложениях dialog-based. Функция CApp::InitInstance вызывает dlg.DoModal, которая в свою очередь вызывает CWnd::RunModalLoop, а та никогда не обращается к OnIdle. Кажется, что можно производить фоновую обработку посредством WM_ENTERIDLE, но это сообщение направляется только родительскому окну диалога, которого в нашем случае просто не существует. Как решить эту проблему?

Модальные диалоги на самом деле лишь имитируются в MFC. Когда вы вызываете CDialog::DoModal, MFC не вызывает ::DialogBox, как можно было ожидать; вместо этого вызывается ::CreateDialogIndirect, затем модальное поведение имитируется путем блокировки родительского окна и запуска своего собственного цикла обработки сообщений. По существу, тоже самое делает функция ::DialogBox. Тогда зачем изобретать велосипед? А дело в том, что теперь MFC имеет свой собственный цикл, в то время как раньше он "прятался" внутри функции API ::DialogBox. Это позволяет MFC обрабатывать сообщения посредством обычных потоков MFC (CWinThread::PumpMessage), что и делается с другими типами окон. В результате вы можете переопределять CWnd::PreTranslateMessage для модальных диалогов – например, для реализации "горячих" клавиш. Ранние версии MFC позволяли реализовывать свою собственную функцию PreTranslateMessage для модального диалога. Но толку от этого было мало, ведь она все равно никогда не вызывалась, т.к. CDialogDoModal напрямую обращалась к ::DialogBox. При этом управление в программу не возвращалось, пока один из обработчиков сообщений вашего диалога не вызывал EndDialog. По этой же причине была невозможна обработка интервала ожидания.

Вместо этого Windows имеет свой собсвенный механизм, WM_ENTERIDLE, предназначенный для обработки интервала ожидания в модальных диалогах. После обработки одного или нескольких сообщений, если в очереди больше ничего нет, Windows автоматически посылает WM_ENTERIDLE окну-владельцу модального диалога или меню. Работает это только в модальных диалогах. Поскольку MFC теперь использует немодальные диалоги в качестве модальных, WM_ENTERIDLE посылается библиотекой "вручную", чтобы самостоятельно имитировать модальные диалоги, но, опять же, только если имеется родительское окно.

Хорошо, если все сообщения модального диалога проходят через стандартную очередь, почему не вызывается CWnd::OnIdle, как часть этого процесса? Проблема в том, что функция CWnd::RunModalLoop вызывает CWinThread::PumpMessage, однако OnIdle вызывается только внутри CWinThread::Run. MFC вызывает CWinThread::Run для запуска вашего приложения после вызова функции InitInstance. В сокращенном виде функция CWinThread::Run выглядит так:

// (from THRDCORE.CPP)

int CWinThread::Run() {

 // for doing idle cycle

 BOOL bIdle = TRUE;

 LONG lIdleCount = 0;

 for (;;) {

  while (bIdle && !::PeekMessage(…)) {

   // call OnIdle while in bIdle state

   if (!OnIdle(lIdleCount++)) // assume "no idle" state

    bIdle = FALSE;

  }

  // Get/Translate/Dispatch the message

  // (calls CWinThread::PumpMessage) 

  …

 }

}

Я убрал все лишнее, чтобы заострить внимание на том, как реализована обработка интервала ожидания. Если соообщений не поступает, MFC вызывает CWinThread::OnIdle, каждый раз увеличивая аргумент-счетчик. Вы можете использовать этот счетчик для установки приоритета различиных обработчиков интервала ожидания. Например, можно выполнять форматирование (диска C:, например :)), когда счетчик ожидания равен 1, затем обновлять показания часов при счетчике, равном 2 и т.п. Если OnIdle возвращает FALSE, то MFC прекращает его вызывать и ждет пока ваш поток получит какое-нибудь сообщение, просле чего обработчик будет вызываться снова.

Обратите внимание, что модальный диалог никогда не будет выполнять этот код, поскольку CWnd::RunModalLoop вызывает CWinThread::PumpMessage сразу из своего собственного цикла обработки сообщений. Он не вызывает CWinThread::Run и, следовательно, никогда не обращается к CWinThread::OnIdle. По-видимому, так было задумано разработчиками. Очевидно, что опасно вызывать OnIdle внутри модального диалога, поскольку многие обработчики сообщений создают временные объекты CWnd, которые, вполне возможно, будут существовать все время, пока существует диалог. Частью процесса обработки OnIdle является освобождение временных карт дескрипторов (handle).

Не могу удержаться от упоминания о том, что механизм временной/постоянной карты дескрипторов (handle map), используемый для связывания дескрипторов HWND с классами CWnd – это один из самых потенциально опасных элементов каркаса приложения, даже более опасный, чем карты сообщений. Проблема "временной карты" непрерывно преследует программистов, особенно в многопотоковых приложениях, делая их трудными для написания в MFC.

Итак, каким же образом обрабатывать период ожидания в приложениях, основанных на диалоге, которые не имеют родительского окна? К счастью, это довольно просто. Разработчики MFC предусмотрели возможность перехвата WM_KICKIDLE. RunModalLoop посылает это частное сообщение MFC (вы не найдете его описания в стандартной документации по Win32 API) все время, пока в очереди диалога нет сообщений, так же как CWinThread::Run вызывает OnIdle. RunModalLoop также поддерживает счетчик и увеличивает его для вас. В результате, WM_KICKIDLE является диалоговым эквивалентом OnIdle. Историческая справка: в ранних версиях MFC была реализована подмена модальных диалогов немодальными в комплексе с WM_KICKIDLE в страницах свойств (property sheets). Видимо, эта схема настоько понравилась, что в дальнейшем все немодальные диалоги стали маскироваться под модальные.

Маленькое замечание: у вас может появиться искушение вызвать функцию OnIdle основного приложения. Вот так, например:

LRESULT CMyDlg::OnKickIdle(WPARAM, LPARAM lCount) {

 return AfxGetApp()->OnIdle(lCount);

}

Разработчики MFC утверждают, что это опасно, в связи с проблемой пресловутой временной карты. Лучше всего реализовывать обработку интервала ожидания внутри OnKickIdle. Если хотите, то можно объединить общие команды обработки в отдельную функцию, которую и вызывать из CApp::OnIdle и CMyDlg::OnKickIdle.

Раз уж здесь был заведен разговор о предмете обработки интервала ожидания, то не лишним будет упомянуть о следующем – не все программисты знают, что есть также функции OnIdle для классов CDocTemplate и CDocument. Если вы хотите реализовать обработчик периода ожидания для документа или шаблона документа, то все что нужно сделать – это определить одну из этих функций.


Paul DiLascia (72400.2702@compuserve.com)
Copyright(C) 1995 by Miller Freeman, Inc.
Перевод: Илья Простакишин (iliya@yes.ru)

Если у вас есть материал (на русском языке) по теме, которая, как вы считаете, будет интересна подписчикам рассылки, не стесняйтесь и присылайте.

ВОПРОС-ОТВЕТ

Q. У меня программа с использованием MFC и Doc/View. Я вставил RichEditCtrl во вью. (2-ой версии). Установил шрифт с помощью сообщения SetCharFormat. Внимание, вопрос: почему если я ввожу текст с клавиатуры и использую ReplaceText функцию (не сообщение!) фонты различные? Вроде это сообшение не менялось у второй версии. Заранее спасибо за ответ.

Игорь

A. Думаю, всё дело в режиме IMF_AUTOFONT, который по умолчанию устанавливается для rich edit'а 2-й версии (в 1-й этого режима просто не было). В этом режиме rich edit автоматически переключает язык и фонт, когда пользователь переключает раскладку клавиатуры (в текст rtf вставляется управляющая последовательность "\langXXXX\fX"). Поэтому если язык, установленный в rich edit'е по умолчанию, отличается от выбранного при запуске программы, фонт подменяется как только кто-то начинает набирать текст с клавиатуры, что и приводит к описанному эффекту.

Для решения проблемы следует попробовать отключить режим IMF_AUTOFONT. Выглядит это так (hEdit – дескриптор rich edit'а):

::SendMessage(hEdit, EM_SETLANGOPTIONS, 0, ::SendMessage(hEdit, EM_GETLANGOPTIONS, 0, 0) & ~IMF_AUTOFONT);

Alexander Shargin

Огромное спасибо Александру за ответ (уже, кстати, третий по счету).

Напоминаю, что в будущем вопросы от Ильи, Александра и всех тех, чьи ответы или материалы были опубликованы, будут рассматриваться вне очереди.

В ПОИСКАХ ИСТИНЫ

Q. Как просканировать LAN на предмет создания поименного списка машин, чтобы затем можно было изпользовать результат в ListBox'e? Пробовал использовать для этой цели SHBrowseForFolder() и связанные ф-ции с установленным флагом CIDL_NETWORK, но открывающееся окно для выбора узла и необходимость "раскрывать плюсики" в локальных группах меня не устраивает. Если можно, в API без MFC.

DevXarT

До встречи!

Алекс Jenter jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №19 от 15 октября 2000 г.

Приветствую всех!

WinAPI & MFC
Тонкая настройка панели инструментов
Задание внешнего вида кнопок и размещение отличных от кнопок элементов

Панель инструментов (Toolbar) cейчас является, пожалуй, одной из обязательных частей любого профессионально сделанного приложения. И тем более становится обидно, что используя стандартные заготовки, ничего, кроме маленьких кнопочек поместить на эту панель нельзя.

Но что делать, если внешний вид приложений MS Office или VC IDE не дает вам спокойно спать? Если вам просто необходимо идти в ногу с конкурирующими программами, где с этим как раз все в порядке? Если вы решили, что размещение дополнительных элементов управления на панели инструментов сразу сделает интерфейс гораздо понятнее и удобнее ?..

Тогда нужно просто взять и сделать это. Да, для этого придется приложить некоторые усилия. Так что любители "рисовать приложения" могут спокойно об этом забыть, а еще лучше – перейти на C++Builder или Delphi, где их способности к рисованию смогут реализоваться в полной мере. (Ладно, не обижайтесь.) Самое большое преимущество Visual C++ в том, что при желании с его помощью можно сделать практически ВСЕ, ЧТО УГОДНО. Главное, знать как. Не пугайтесь – от вас потребуется совсем немного.

Но для начала давайте выясним, можно ли просто изменить стандартный вид тулбара (так для краткости я буду именовать панель инструментов). Например, сделать тулбар а'ля WinZip – большие иконки, с подписями…

Итак, какие настройки нам доступны практически сразу же? – Конечно же, стили. Оперируя стилями, мы тоже можем повлиять на внешний вид панели. Вот самые интересные из них:

CCS_TOP и CCS_BOTTOM — задают размещение тулбара — вверху или внизу окна. (CСS_TOP используется по умолчанию.)

TBSTYLE_FLAT — Делает кнопки плоскими. (Используется по умолчанию.)

TBSTYLE_LIST — Используется для вывода текста справа от кнопки. (Помните пункт "выборочно текст справа" в IE4 и Outlook?)

Остальные стили вы можете, в принципе, посмотреть сами – они задают некоторые другие параметры. Но нам сейчас нужно другое: сделать кнопки большими и с подписями. Выполнить это можно с помощью членов классов CToolBar и CToolBarCtrl, а если вы работаете не в MFC, то придется работать с сообщениями.

Вышеупомянутые классы MFC располагают богатым набором функций для всевозможной настройки тулбара. Функции CToolBarCtrl::SetButtonSize(), CToolBarCtrl::SetBitmapSize(), CToolBarCtrl::SetButtonWidth(), CToolBar::SetButtonText(), CToolBar::SetHeight() говорят сами за себя. Именно они понадобятся нам для реализации такого тулбара, как в WinZip. Без MFC это можно сделать, послав тулбару сообщения _SETBUTTONSIZE, TB_SETBITMAPSIZE, TB_SETBUTTONWIDTH, TB_ADDSTRING и др. Кстати, многие функции классов MFC делают фактически то же самое – просто посылают соответствующие сообщения.

Можете сами поиграться с различными настройками. Если бы я взялся здесь подробно описывать ВСЕ возможности, и как каждую реализовать, то эта статья растянулась бы минимум на  дюжину выпусков. Цель данной публикации – дать вам общее представление, направление, так сказать. Я не думаю, что обязательно нужно все разжевывать и, как это часто происходит, сводить мысль к "нажмите туда, выберите то". Я хочу, чтобы вы учились думать сами.

Психологи приводят следующую статистику: когда человек просто прочитывает информацию, то запоминает не более 50% из прочитанного. Если еще и записывает – не более 70%.

Но если человеку информация досталась с некоторым трудом, если он ее нашел сам – то запоминается более 90%! Сделайте выводы.

Теперь пришла пора перейти к самому интересному вопросу, который я рассмотрю гораздо подробнее, а именно – как на тулбаре разместить что-либо, не являющееся кнопкой.

Я буду рассказывать как это делается в MFC, хотя понять, как это сделать в API после ознакомления с текстом не составит никакого труда.

Как обычно, если мы хотим заставить что-то стандартное работать нестандартно, нужно создавать класс-наследник. В нашем случае это будет наследник CToolBar, обозначим его CAdvBar. В нем вы сможете обрабатывать все события, поступающие от контролов, размещенных на тулбаре.

А теперь самая суть: как именно можно что-то поместить на тулбар. Дело в том, что существует возможность программно управлять шириной элементов-сепараторов. Таким образом, сепараторы становятся как бы "местами содержания" наших контролов.

В редакторе ресурсов отведите отдельную кнопку на тулбаре – в будущем вместо нее появится ваш элемент управления. Теперь для удобства определим следующие символические константы:

CONTROL_INDEX — порядковый номер кнопки-содержателя контрола;

CONTROL_WIDTH — ширина контрола;

CONTROL_HEIGHT — высота контрола. 

Включите контрол в качестве члена в класс CAdvBar. Еще нужно создать функцию инициализации, которая будет подменять кнопку нашим контролом (конструктор или обработчик OnCreate в данном случае не подходят, т.к. вызываются слишком рано). Пускай, например, нам нужно поместить на тулбар элемент управления типа ComboBox. Тогда:

class CAdvBar : public CToolBar {

 …

protected :

 CComboBox m_ComboBox; // наш контрол

 void Initialize( ); // ф-ция инициализации

 …

}

Функция инициализации превращает нашу кнопку в сепаратор и устанавливает ему нужную ширину, после чего создает и позиционирует контрол на его место. Пример для комбобокса:

void CAdvBar::Initialize() {

 CRect rc; 

 SetHeight(CONTROL_HEIGHT + 8); // устанавливаем нужную толщину тулбара

 // превращаем кнопку в сепаратор нужных размеров

 // (IDC_COMBO - ID кнопки)

 SetButtonInfo(CONTROL_INDEX, IDC_COMBO, TBBS_SEPARATOR, CONTROL_WIDTH);

 GetItemRect (CONTROL_INDEX, rc); // получаем координаты сепаратора

 // теперь создаем комбобокс.

 // не забывайте, что для этого контрола при создании указывается

 // его высота В РАЗВЕРНУТОМ ВИДЕ, именно поэтому

 // мы к ней прибавляем еще 100 пикселов.

 rc.bottom += 100;

 m_ComboBox.Create(WS_CHILD | WS_VISIBLE | WS_TABSTOP | WS_VSCROLL | CBS_AUTOHSCROLL | CBS_DROPDOWN, rc, this, IDC_COMBO);

  // настраиваем контрол

 m_ComboBox.AddString("Строка 1");

 m_ComboBox.AddString("Строка 2");

 m_ComboBox.SetCurSel(0);

}

В данном случае еще могу порекомендовать в комбобоксе изменить шрифт на пропорциональный.

Вот, теперь все, что осталось сделать – в CMainFrame::OnCreate() после создания тулбара вызвать Initialize().

Взаимодейстиве с контролом, размещенным на тулбаре, происходит через соответствующий член класса и/или посредством сообщений.

ВОПРОС-ОТВЕТ

Из ответов, содержащих одинаковое решение, я выбрал лучшие (с моей точки зрения). Большая просьба: не нужно присылать мне целые проекты и большие куски кода. Лучше объясните ваше решение словами.

Q. Как просканировать LAN на предмет создания поименного списка машин, чтобы затем можно было изпользовать результат в ListBox'e? Пробовал использовать для этой цели SHBrowseForFolder() и связанные ф-ции с установленным флагом CIDL_NETWORK, но открывающееся окно для выбора узла и необходимость "раскрывать плюсики" в локальных группах меня не устраивает. Если можно, в API без MFC.

DevXarT

A1 Необходимо подключить заголовочные файлы

#include <lmcons.h>

#include <lmserver.h>

#include <lmerr.h>

и библиотеку NetAPI, в диалоге "Project Settings" на странице "Link" в поле "Object/library modules:" вписать netapi32.lib

Далее, например так:

LPSERVER_INFO_100 pServerEnum;

DWORD   dwResult, dwRead, dwTotal;

dwResult = ::NetServerEnum(NULL, 100, (BYTE**)&pServerEnum, -1, &dwRead, &dwTotal, SV_TYPE_ALL, NULL, 0);

 if (dwResult == NERR_Success) {

  for (DWORD i=0; i<dwRead; i++)

   m_wndListBox.AddString(CString((LPCWSTR)pServerEnum[i].sv100_name));

 }

}

Причем, используя SERVER_INFO_101 можно получить более подробную информацию (например тип и версию операционной системы), а комбинируя различные флаги в седьмом параметре NetServerEnum можно выбирать компьютеры по определенному признаку (например, только SQL-серверы или Terminal Server).

Недостаток такого способа в том, что он получает список хостов от мастер-браузера. Таким образом в этом списке присутствуют только хосты, в настоящий момент присутствующие в сети. А поскольку мастер-браузер обновляет эту информацию с периодичностью около 15 минут, список может быть не актуален на данный момент. Кроме того в нем отсутствуют "скрытые" хосты (например командой net config server /hidden:yes ).

А вот мой вопрос… Многие утилиты Windows NT Server (regedt32, Windows NT Diagnostics, Event Viewer, Perfomance Monitor, Shutdown Manager) имеют диалог "Select Computer". Наверняка он в системе "стандартный". Что-то типа SHBrowseForFolder. Может кто знает, где его найти, как вызвать?

Андрей

A2 Ответ кроется в группе функций с префиксом ::WNetXXX:

WNetOpenEnum(RESOURCE_CONTEXT, RESOURCETYPE_ANY, 0, NULL, &handleEnum) – открыть нумерацию локальных доменов верхнего уровня (включая узел Entire Network, эквиалентно выбору Network Neighbourhoods в Explorer), четвертый параметр имеет тип LPNETRESOURCE, где NETRESOURCE – структура, описывающая узел;

WNetOpenEnum(RESOURCEUSAGE_CONTAINER, RESOURCETYPE_ANY, 0, pNetCurrent, &handleEnum) – открыть нумерацию ресурсов узла (шаринги, локальные домены следующего уровня, принтеры, см. флажки в МСДН);

WNetEnumResource(handleEnum, &dwCounter, pNetResource, &dwBufferSize) – получить список ресурсов узла, handleEnum получается предыдущей ф-цией.

…я бы не советовал заполнять листбокс всеми именами машин за раз, процесс этот может быть довольно длительным во времени (порядка минуты); если сеть достаточно велика (от 30-50 машин), лучше использовать дерево.

James Nicolas Borodco

A3 Список машин, их имена, имена провайдера, тип подключения и т.д. имеется в реестре. Смотри ключи:

HKEY_CURRENT_USER\Network

HKEY_CURRENT_USER\Network\Recent

Функции для работы с реестром имеются, ищи в MSDN Library, например, RegOpenKeyEx, RegQueryInfoKey. Там же в MSDN Library имеются и примеры работы с реестром (в обзорах, конечно).

Виктор Никитенко

К сведению: Не во всех системах есть такие ключи реестра. В Windows NT/2000, например, их нет.

Хочу поблагодарить всех, кто откликнулся и прислал ответ на вопрос. Если хотите чтобы ваш ответ был опубликован – постарайтесь, чтобы он был лучше других! Напоминаю, что только вопросы от авторов опубликованных ответов и материалов имеют в дальнейшем приоритет. (Вопросы, естественно, должны быть по программированию).

В ПОИСКАХ ИСТИНЫ

Q. Как создать такое окно (или это диалогбар?) как Workspace в Visual Studio? То есть, я представляю, что если это диалогбар со списком, то какие стили применить в Create, чтобы его можно было "переносить" и изменять размер?

СашА

Начинающим программистам рекомендую подписаться на дружественную рассылку:

Практикум программирования на C++ под Windows

Учебный курс по программированию на языке C++ под Windows. Предназначена для тех, кто уже (немного) умеет программировать, но не знает языка C++ или идеологии написания программ под Windows. В планах — изучение Win32 API, MFC, терминологии Windows и технологий, связанных с ней. Ответы на вопросы, глоссарий, приложения.

Будьте здоровы!

Алекс Jenter jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №20 от 22 октября 2000 г.

Здравствуйте, уважаемые подписчики!

Тем, кто еще пребывает в блаженном неведении, спешу сообщить хорошую новость.

Рассылка в октябре приобрела статус "золотой"!

Что это значит? По определению Subscribe.Ru, это означает, в частности, что рассылка:

– содержит свежие, актуальные и исключительно полноценные материалы;

– соблюдает указанную в описании тематику и периодичность;

– выходит на грамотном русском языке.

Скромно хочу отметить, что "Программирование на VC++" сейчас единственная "золотая" рассылка в разделе "программирование". Будем надеяться, что этот статус теперь закрепится за ней надолго.

Поздравления принимаются по все тому же адресу ;)

НОВОСТИ

Судя по всему, новая концепция Microsoft – .NET – довольно сильно интересует всех программистов, и, соответственно, читателей рассылки. Сегодня я вам предлагаю статью, присланную Ярославом Говоруновым. Он ее решил оформить как продолжение моей публикации из выпуска №8.

Что дядя Билли нам готовит
Часть вторая

Итак, NGWS SDK pre-beta вышла. Это немного развеяло туман, связанный с появлением на свет следующей версии Visual Studio и теперь можно более конкретно говорить о том, что нас ждет. Что же вызвало столько шума? Это не новый язык C#, и не новые инструментальные средства, по большому счету это даже не новая VS ;). Имя счастливчика – .NET.

Так что же такое .NET – технология, SDK или модель? На эту тему было много споров. Был даже спор, является ли .NET операционной системой. Лично я согласен с самим производителем и считаю что .NET – это платформа. Можно сказать, что .NET представляет собой этикетку, название, придуманное маркетологами, для целого набора технологий, как Windows DNA. Формально ее можно определить так:

.NET = COM+

 + дополнительные сервисы и технологии

 + Common Language Runtime (CLR)

 + набор спецификаций (в т.ч. Common Language Specification — CLS)

 + огромная библиотека объектов.

Концептуально .NET представляет собой единение основных идей, лежащих в основе Java и COM.

Теперь обо всем по порядку.

Ядром всей системы является Common Language Runtime (CLR) – это аналог JVM (Java Virtual Machine), но методы ее работы больше похожи на COM. Она контролирует всю основную работу по выделению и освобождению памяти, созданию и уничтожению объектов, вызову методов и многое другое. При этом на низком уровне используются хорошо известные концепции, такие как контексты объектов, перехват по необходимости, Proxy/Stub и т.д. Большая часть технологий не так нова, как кажется. Например, так рекламируемый 'garbage collection' представляет собой просто красивую оболочку механизма подсчета ссылок в COM, только теперь CLR берет на себя всю рутинную работу.

Однако есть ряд существенных отличий. Как и в случае с Java, .NET программы не компилируются в машинные коды. Вместо этого программа поставляется в виде Intermediate Language (IL). На выходе получается тот же самый exe или dll файл, но вместо машинных кодов он содержит IL. На вид IL очень похож на некий прообраз ассемблера, так что исходные тексты , возможно, останутся защищенными. В отличие от байт-кода, IL-код не может быть интерпретирован. Для выполнения программы используется Just-In-Time Compilation (JITting), когда куски кода компилируются и оптимизируются во время выполнения. Такой метод предположительно будет использоваться для WEB-приложений, так как приводит к потерям производительности. Для пользовательских программ будет использоваться другой – pre-JITing, когда компиляция происходит во время установки программы на пользовательскую машину. IL не зависит от языка программирования, теоретически его можно писать даже вручную, однако .NET предлагает лучшее решение.

Common Language Specification (CLS). Да, хорошо сформулированные спецификации являются, пожалуй, самой сильной стороной .NET. Как известно, ни одна технология или платформа не может стать стандартом без спецификаций. .NET, как и COM, является языконезависимой платформой. CLS определяет набор спецификаций, которым должен соответствовать язык программирования, чтобы стать частью .NET. Разумеется, язык должен быть объектно-ориентированным, он должен поддерживать пространства имен. Запрещается множественное наследование, вместо этого вводится концепция интерфейса и множественное наследование интерфейса. Все это делает разницу между языками достаточно тривиальной. В наши дни, для написания программ, программисты пользуются библиотеками объектов. .NET имеет одну большую библиотеку объектов для всех языков. Точнее библиотека является частью CLR, и соответственно доступна для всех языков в платформе. Библиотека эта очень велика. Она состоит из множества пространств имен, каждое из которых в свою очередь содержит классы или другие пространства имен. [Здесь мне почему-то приходит в голову высказывание Роберта Хайнлайна о том, что слон – это мышь, выполненная по государственным спецификациям ;) – AJ]

И наконец о месте VC в новой платформе. Хочу обрадовать читателей, что для VC была отведена особая роль. Так как сам язык C++ не очень соответствует спецификации CLS, то его пришлось немного изменить. Такой измененный язык называется VC managed extension. Однако это не главное! Главное то, что VC остается единственным средством для производства 'unmanaged code', т.е. – программа компилируется в машинные коды и работает не под управлением CLR, а сама по себе.

Итак, какие же преимущества мы получим с переходом на .NET? Первое, и главное – платформонезависимость. Хоть на данный момент доступна только одна платформа – Windows 2000, Microsoft обещает, что CLR будет доступна для всех основных платформ. Второе – языконезависимость. .NET программы могут разрабатываться на любых из более чем 40 уже доступных языков. При этом предоставляется очень высокий уровень интеграции. Облегчается задача разработчика, так как CLR берет на себя часть рутинных задач. А также большая и удобная в использовании библиотека объектов.

А недостатки? О недостатках пока говорить рано. Как говориться «знал бы, где упал».

Возможно, мне так и не удалось ответить на вопрос – что же такое .NET? Грандиозный успех, или грандиозный провал – время покажет. Ясно одно, .NET – это самый значительный шаг Microsoft за последнее время. Важнее даже чем Windows 2000 и X-Box. Грядет революция, и рано или поздно нам придется с этим считаться. Мое мнение – лучше рано, чем поздно.

Несколько полезных ссылок:

Тут можно скачать NGWS SDK

Сайт с кучей полезных ресурсов по .NET

Также сайт посвященный C#

И разумеется первоисточник

ОБРАТНАЯ СВЯЗЬ

Здраствуйте Алекс. Спасибо за Вашу рассылку, я с удовольствием читаю ее с первого выпуска. Прочитав выпуск №19 решил обратить Ваше внимание на, как мне кажется, более новый способ создания паналей инструментов различного внешнего вида (а'ля Internet Explorer и т.п.) Для этих целей в MFC появился класс CReBar позволяющий размещать на панели инструментов не только кнопки но и практически любые объекты произошедшие от CWnd и имеющие стиль WS_CHILD. Как правило в качестве таких объектов выступают экземпляры классов CToolBar и CDialogBar. Более подробно об этом можно прочитать в MSDN.

D. Kosyrevsky.

Использование CReBar действительно в некоторых случаях оправданно. Но необходимо знать, что у ReBar существует ряд существенных ограничений. В частности, они не могут быть "плавающими" и стыковаться с границами окна.

Что касается постановки вопроса: "сделать тулбар а'ля WinZip – большие иконки, с подписями…", так это можно сделать в редакторе ресурсов просто "растянув" изображение до нужного размера и написав все, что нужно (естественно, надписи будут статическими). Что же касается размещения элементов управления на панели инструментов за счет "расширения" сепараторов, то это действительно интересно и, главное, более гибко и удобно, чем создание DialogBar.

Евгений Шмелев.

Вряд ли статический (т.е. являющийся частью изображения ) текст кого-либо устроит. Это, конечно, можно сделать, но вообще-то это не принято.

ВОПРОС-ОТВЕТ

Q. Как создать такое окно (или это диалогбар?) как Workspace в Visual Studio? То есть, я представляю, что если это диалогбар со списком, то какие стили применить в Create, чтобы его можно было "переносить" и изменять размер?

СашА

На этот вопрос было получено удивительно мало ответов. Неужели этим почти никто не интересовался?

A1 Среди заголовочных файлов MFC есть заголовочный файл afxpriv.h, в котором объявлено несколько недокументированных классов, в том числе например класс CDockBar. По-моему именно он обеспечивает создание окон в стиле Visual Studio.

Anton

Я хотел бы предостеречь читателей: использование недокументированных классов чревато неприятностями. В том же MSDN написано, что члены и методы класса CDockBar, скорее всего, претерпят сильные изменения в будущем.

A2 Во время оно я боролся с этим вопросом. Вот краткие выводы: DialogBar – ДЕРЬМО. Проще сходить на сайт http://www.datamekanix.com и слить оттуда компонент CSizingControlBar написанный Crisite Posea. Он тоже не предел совершенства, но работает почти так же как и Workspace.

Vassili Bourdo

Хочу добавить (как еще один вариант), что я кажется видел класс с такой же функциональностью в Ultimate Toolbox от Dundas Software.

В ПОИСКАХ ИСТИНЫ

Q. У меня есть приложение MFC на базе диалога. Я решил организовать переключение некоторых режимов через главное меню, т.е. в меню присутствуют названия режимов и активный в данный момент режим помечен точкой. Для этого я создал обработчики ON_UPDATE_COMMAND_UI для соответствующих пунктов меню и в них вызов СCmdUI::SetRadio(). Например:

void CHeatDlg::OnUpdateSolve(CCmdUI* pCmdUI) {

 if (mode == 1) pCmdUI->SetRadio(TRUE);

 else pCmdUI->SetRadio(FALSE);

}

Это не сработало. Похоже, что сообщения ON_UPDATE_COMMAND_UI просто не посылаются. До этого я использовал такой же подход в приложениях SDI и MDI и все работало. Есть какие-нибудь мысли по этому поводу?

Андрей Моисеев

Успехов!

Алекс Jenter jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №21 от 29 октября 2000 г.

Все настоящие программисты делятся на три категории: на тех, кто пишет программы, завершающиеся по нажатию F10, Alt-F4 и Alt-X. Все  остальные  принципы  деления надуманны.

авт. неизв.

Рад снова приветствовать вас!

Сегодняшний выпуск посвящен вашим письмам с вопросами, ответами, комментариями, замечаниями и дополнениями, которых у меня накопилось изрядное количество.

ВОПРОС-ОТВЕТ

Q. У меня есть приложение MFC на базе диалога. Я решил организовать переключение некоторых режимов через главное меню, т.е. в меню присутствуют названия режимов и активный в данный момент режим помечен точкой. Для этого я создал обработчики ON_UPDATE_COMMAND_UI для соответствующих пунктов меню и в них вызов СCmdUI::SetRadio(). Например:

void CHeatDlg::OnUpdateSolve(CCmdUI* pCmdUI) {

 if (mode == 1) pCmdUI->SetRadio(TRUE);

 else pCmdUI->SetRadio(FALSE);

}

Это не сработало. Похоже, что сообщения ON_UPDATE_COMMAND_UI просто не посылаются. До этого я использовал такой же подход в приложениях SDI и MDI и все работало. Есть какие-нибудь мысли по этому поводу?

Андрей Моисеев

A1 Решение проблемы обработчика ON_UPDATE_COMMAND_UI частично кроется в одном из предыдущих выпусков — №18. Ведь этот обработчик вызывается Framework'ом MFC из OnIdle объекта приложения, а в dialog-based программах OnIdle не работает. Тут можно посоветовать использовать в качестве главного окна аппликации скрытое "фиктивное" окно и подсунуть его в качестве родителя диалога.

Sergey Emantayev

A2 Дело в том, что вся логика генерации user-interface update command message для меню (создание объекта CCmdUI и т.д.) реализована в CFrameWnd::OnInitMenuPopup. Соответственно в dialog-based приложениях вызов этой функции отсутствует. Очевидно, предполагалось что в диалогах меню не обязательно. Поэтому можно предложить два варианта. Общим в них является необходимость создания обработчика OnInitMenuPopup для вашего диалога. Первый вариант подойдёт, если вы уже повсеместно расставили обработчики ON_UPDATE_COMMAND_UI, и не хотите ничего переделывать: Вы просто копируте тело функции CFrameWnd::OnInitMenuPopup в созданную вами функцию (благо, что исходники доступны), чистите всё лишнее (разобраться достаточно легко) и созданные вами обработчики OnUpdateXXX начинают вызываться Второй вариант предполагает, что вы, что называется "ручками", изменяете состояния пунктов меню прямо в созданной вами выше функции OnInitMenuPopup, используя передаваемый ей как параметр CMenu*. Этот вариант вполне приемлем, если меню не очень большое и структура его не очень разветвлённая. Для некоторых этот вариант также покажется более привлекательным по той причине, что вы всё делаете сами, а не копируете фрагменты чужого кода.

Роман Клепов

A3 Когда Windows собирается отобразить всплывающее меню, она посылает сообщение WM_INITMENUPOPUP, чтобы программа могла на лету кое-что поменять: отключить некоторые пункты, расставить галочки и т. п. Поэтому базовый способ модификации всплывающих меню состоит в перехвате этого сообщения с последующим использованием функций EnableMenuItem, CheckMenuItem и т.п.

MFC предлагает альтернативный подход. В классе CFrameWnd есть готовый обработчик WM_INITMENUPOPUP, который инициализирует структуру CCmdUI для каждого пункта меню, после чего отправляет сообщение CN_UPDATE_COMMAND_UI, определённое в MFC, сперва классу представления, затем классу документа, затем классу главного окна и, наконец, классу приложения. Каждый из этих классов может внести свою лепту в инициализацию всплывающего меню. Можно инициировать этот процесс, вообще ничего не зная о CN_UPDATE_COMMAND_UI: достаточно вызвать CCmdUI::DoUpdate, и сообщеине дойдёт до написанных программистом обработчиков CN_UPDATE_COMMAND_UI.

Теперь внимание: класс диалога (CDialog) не имеет предопределённого обработчика WM_INITMENUPOPUP. Поэтому сообщения CN_UPDATE_COMMAND_UI никто не посылает, и обработчики ON_UPDATE_COMMAND_UI не вызываются. Необходимо вручную написать обработчик OnInitMenuPopup, воспроизведя в нём часть функциональности класса CFrameWnd. В простейшем случае он может выглядеть так:

void CMyDlg::OnInitMenuPopup(CMenu* pPopupMenu, UINT nIndex, BOOL bSysMenu) {

 if (!bSysMenu) {

  CCmdUI state;

  state.m_pMenu = pPopupMenu;

  state.m_nIndexMax = pPopupMenu->GetMenuItemCount();

  for (state.m_nIndex = 0; state.m_nIndex < state.m_nIndexMax; state.m_nIndex++) {

   state.m_nID = pPopupMenu->GetMenuItemID(state.m_nIndex);

   state.m_pSubMenu = NULL;

   state.DoUpdate(this, state.m_nID < 0xF000);

  }

 }

}

В случае когда всплывающее меню имеет подменю обработчик будет более сложным. За примером такого обработчика можно обратиться к исходным текстам программы DLGCBR32, которые находятся в MSDN.

Alexander Shargin

A4 Это и не должно работать, так как диалоговое окно не посылает сообщение на обновление меню, следует заметить, что такие "казусы" происходят с диалогами достаточно часто, к примеру Диалог не посылает сообщение о командах меню своим детям, как это делают приложениях SDI и MDI, все дело в том что в MFC диалоги работают по другим правилам, чем обычные окна, так как в MFC главный упор сделан на архитектуру Document-View, а диалоги "искуственное" добавление. Я решал подобную проблему, самостоятельно посылать сообщение Меню на обновление, так:

BEGIN_MESSAGE_MAP(CMyDlg, CDialog)

 ...

 ON_MESSAGE(WM_KICKIDLE, OnKickIdle)

 ...

END_MESSAGE_MAP()


LRESULT CMyDlg::OnKickIdle(WPARAM w, LPARAM l) {

 Sleep(50);

 // Самостоятельно обновлять меню ...

 UpdateMenu(this , GetMenu());

 return TRUE;

}


// А это моя функция ...

void UpdateMenu(CWnd *pWnd, CMenu *pMenu) {

 CCmdUI cmdUI;

 cmdUI.m_pMenu = pMenu;

 cmdUI.m_nIndexMax = pMenu->GetMenuItemCount();

 for (cmdUI.m_nIndex = 0; cmdUI.m_nIndex < cmdUI.m_nIndexMax; ++cmdUI.m_nIndex) {

  CMenu* pSubMenu = pMenu->GetSubMenu(cmdUI.m_nIndex);

  if (pSubMenu == NULL) {

   cmdUI.m_nID = pMenu->GetMenuItemID(cmdUI.m_nIndex);

   cmdUI.DoUpdate(pWnd, FALSE);

  } else UpdateMenu(pWnd, pSubMenu);

 }

} /// и все.

Oleg Zhuk

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

Авторам всех ответов, и опубликованных, и не опубликованных, большое спасибо!

ОБРАТНАЯ СВЯЗЬ

Из входящей почты:

День добрый,

По всем вопросам, ответы на которые публикуются в рассылке у меня сложилось мнение, которое вероятно ошибочно, что никто их ее читателей не знает такого сайта как www.codeguru.com, который содержит гараздо более полную и полезную информацию и ответы на вопросы, чем те, что публикуются…

Юрий Карпенко 

Ну, в чем-то возможно и справедливо. Но далеко не во всем. Некоторые не могут свободно работать с MSDN или CodeGuru из-за недостаточного знания английского, или жалко времени в интернет, а кому-то просто лень…

И потом, я думаю, ответы на вопросы полезны не только для тех, кто задал вопрос – самое главное, они полезны тем, кто даже с этой проблемой никогда и не сталкивался. Рассылка позволяет им получать новые познания практически без труда. Ведь доказано, что в школе ученик, понявший новую тему раньше своего товарища, сможет ему ее объяснить гораздо лучше, чем сам учитель. В случае, если у кого-то в будущем возникнет такая задача, он уже будет знать, в каком направлении двигаться при ее решении.

Следующее письмо пришло в ответ на те строки, которые я написал в прошлом выпуске о классе CReBar. Напомню: "Использование CReBar действительно в некоторых случаях оправданно. Но необходимо знать, что у ReBar существует ряд существенных ограничений. В частности, они не могут быть "плавающими" и стыковаться с границами окна."

Полегче со словом "не могут", уважаемый.

http://codeproject.com/docking/tearoffrebars.asp

Вот яркий пример того чего не может быть.

Paul Bludov

Тот контрол, на который сослался автор письма, в самом деле, благодаря усилиям программиста, который его создал, может "плавать". Но полной функциональности тулбаров он все равно не достигает – стыковаться он по-прежнему может только с одной границей, не возвращается на свое место по double-click и т.д. И потом, я говорил о CReBar. Вряд ли этот модифицированный класс можно так назвать.

Так что полегче со словом "полегче", уважаемый Павел…

Еще письма:

Есть комментарий к ответам на вопрос из номера 18 (по поводу списка компьютеров в сети), точнее к первому из них.

-------------------------

В документации Микрософт сказано, что Функции Netxxx устарели и следует пользоваться функциями WNetxxx. Во-вторых, с использованием функций Netxxx есть проблемы из-за того, что для Windows NT и Windows 9x используются различные библиотеки (в первом случае netapi32.lib, во втором svrapi.lib). Также вызовы функций в этих библиотеках различаются параметрами (кстати, в MSDN приводится версия для WinNT, а для Win9x придется читать заголовочный файл svrapi.h). Кстати, для Windows 9x следует использовать именно svrapi.h, а не lmxxx.h.

Sergey Shoumko

Тут вспомнилось – к Вашему выпуску о читабельности кода:

"Отсутствие коментариев в программе – веский повод для увольнения программиста" – Дональд Кнут

Роман
В ПОИСКАХ ИСТИНЫ

Q. Все, наверное, знают программы, называемые Viewbar, которые показывают рекламные баннеры. Но вот как они ограничивают часть экрана, не позволяя другим окнам находиться поверх них? Например, если разрешение экрана 800×600, как они выделяют полосу сверху, в которой находятся, т.ч. программы, развернутые на полный экран, имеют высоту где-то на 60 пикселей меньше. Причем и немаксимизированные окна не могут "влезть" в эту полосу.

Alexander Popov

До встречи!

Алекс Jenter jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №22 от 5 ноября 2000 г.

Здравствуйте!

Мне пришла пара писем от подписчиков, где они выразили некоторую неудовлетворенность существующей  в рассылке системой поощрения авторов лучших ответов и статей (для вновьподписавшихся: см. в архиве выпуск No. 18) Они пишут, что "прежде всего надо публиковать самые интересные вопросы."

Я лично с этим целиком и полностью согласен, и всегда фактически стараюсь так и делать, хотя понятие "интересный вопрос" достаточно размыто и каждый понимает его по-своему. Для некоторых, например, интересный вопрос – "Как связать контролы на диалоге с переменными класса?", а для других – …мм, ну, совершенно другое ;)

С другой стороны, у меня нет абсолютно никакой альтернативы для поощрения авторов, кроме как морального поощрения. Думаю мало кого увлечет обещание типа "Вы увидите свое имя в рассылке, оно навечно войдет в скрижали ее истории", и т.д. и т.п.

Так вот, к чему я клоню. РАССЫЛКЕ НУЖЕН ПОСТОЯННЫЙ СПОНСОР И РЕКЛАМОДАТЕЛЬ. Тогда станет возможно назначить материальное вознаграждение за лучший ответ и лучший материал (а, возможно, и лучший вопрос тоже!)

Это будет выгодно прежде всего самим читателям, поскольку качество и интересность вопросов, ответов и статей значительно повысится. Да и авторам, я думаю тоже будет неплохо получить, скажем, энное количество $ потратив несколько минут на ответ.

И тогда, действительно, будет возможно публиковать только САМЫЕ ИНТЕРЕСНЫЕ вопросы.

Так что дело только за вами, уважаемые рекламодатели! Хочу вам напомнить, что рассылку получают около 8500 интересующихся программированием человек.

К читателям: может, у вас есть какие-нибудь идеи или просто интересные мысли по этому поводу? Не стесняйтесь – пишите мне.

СТАТЬЯ

Сегодня я предлагаю вам заметку, написанную уже воистину постоянным автором нашей рассылки – Александром Шаргиным.

Три способа подключения DLL

Многие знают, что существует два основных способа подключить DLL к выполняющемуся процессу – явный и неявный.

При неявном подключении (implicit linking) линкеру передаётся имя библиотеки импорта (с расширением lib), содержащей список функций DLL, которые могут вызвать приложения. Обнаружив, что программа обращается к одной из этих функций, линкер добавляет информацию о содержащей её DLL в целевой exe-файл. Позже, когда этот exe-файл будет запущен, загрузчик попытается спроектировать необходимую DLL на адресное пространство процесса; в случае неудачи весь процесс будет немедленно завершён.

При явном подключении (explicit linking) приложение вызывает функцию LoadLibrary(Ex), чтобы загрузить DLL, затем использует функцию GetProcAddress, чтобы получить указатели на требуемые функции, а по окончании работы с этими функциями вызывает FreeLibrary, чтобы выгрузить библиотеку и освободить занимаемые ею ресурсы.

Каждый из способов имеет свои достоинства и недостатки. В случае неявного подключения все библиотеки, используемые приложением, загружаются в момент его запуска и остаются в памяти до его завершения (даже если другие запущенные приложения их не используют). Это может привести к нерациональному расходу памяти, а также заметно увеличить время загрузки приложения, если оно использует очень много различных библиотек. Кроме того, если хотя бы одна из неявно подключаемых библиотек отсутствует, работа приложения будет немедленно завершена. Явный метод лишён этих недостатков, но делает программирование более неудобным, поскольку требуется следить за своевременными вызовами LoadLibrary(Ex) и соответствующими им вызовами FreeLibrary, а также получать адрес каждой функции через вызов GetProcAddress.

В Visual C++ 6.0 появился ещё один способ подключения DLL, сочетающий в себе почти все достоинства двух рассмотренных ранее методов – отложенная загрузка DLL (delay-load DLL). Отложенная загрузка не требует поддержки со стороны операционной системы (а значит будет работать даже под Windows 95), а реализуется линкером Visual C++ 6.0.

При отложенной загрузке DLL загружается только тогда, когда приложение обращается к одной из содержащихся в ней функций. Это происходит незаметно для программиста (то есть вызывать LoadLibrary/GetProcAddress не требуется). После того как работа с функциями библиотеки завершена, её можно оставить в памяти или выгрузить посредством функции __FUnloadDelayLoadedDLL. Вызов этой функции – единственная модификация кода, которую может потребоваться сделать программисту (по сравнению с неявным подключением DLL). Если требуемая DLL не обнаружена, приложение аварийно завершается, но и здесь ситуацию можно исправить, перехватив исключение с помощью конструкции __try/__except. Как видим, отложенная загрузка DLL – весьма удобное средство для программиста.

Теперь рассмотрим, каким образом описанные способы подключения DLL используются на практике. Для этого будем считать, что нам требуется вызвать функцию X, экспортируемую библиотекой MyLib.dll. Пусть функция X имеет простейший прототип: void X(void);

Будем также считать, что библиотека импорта находится в файле MyLib.lib.

Неявное подключение

Первое, что нам нужно сделать – это передать линкеру имя библиотеки импорта нашей DLL. Для этого необходимо открыть окно настройки проекта (Project->Settings) и на вкладке Link дописать "MyLib.lib" в конец списка Object/Library modules. Альтернативный подход заключается в использовании директивы #pragma. В нашем случае необходимо вставить в код программы следующую строку:

#pragma comment(lib,"MyLib")

Второе, что нужно проделать – это добавить объявление функции в код программы (обычно объявления функций, экспортируемых DLL, сводятся в заголовочный файл – тогда требуется просто подключить его). Для нашей функции X объявление выглядит так:

__declspec(dllimport) void X(void);

Вот и всё. Теперь к функции X можно обращаться, как и к любой другой функции, статически прилинкованной к нашей программе:

X();

Явное подключение

Как уже говорилось ранее, при явном подключении к DLL программист должен сам позаботиться о загрузке библиотеки, получении адреса функций и выгрузке библиотеки. Таким образом последовательность шагов может быть следующей.

Загружаем библиотеку:

HINSTANCE hLib = LoadLibrary("MyLib.dll");

Получаем указатель на функцию и вызываем её:

void (*X)();

(FARPROC &)X = GetProcAddress(hLib, "X");

X();

Выгружаем библиотеку из памяти:

FreeLibrary(hLib);

Отложенная загрузка

Сначала необходимо повторить шаги, которые мы проделывали при неявном подключении: передать линкеру имя библиотеки импорта и добавить в программу объявление функции X. Теперь, чтобы отложенная загрузка заработала, нужно добавить ключ линкера /DELAYLOAD:MyLib.dll и прилинковать к приложению библиотеку Delayimp.lib, реализующую вспомогательные функции механизма отложенной загрузки. Хотя эти опции можно добавить в настройки проекта, я предпочитаю использовать директивы #pragma:

#pragma comment(lib, "Delayimp")

#pragma comment(linker, "/DelayLoad:MyLib.dll")

Если после вызова функции X нам требуется выгрузить библиотеку MyLib.dll из памяти, можно воспользоваться функцией FUnloadDelayLoadedDLL. Чтобы эта функция работала корректно, необходимо добавить ещё один ключ линкера /DELAY:unload. Кроме того, нужно подключить заголовочный файл , в котором эта функция объявлена. Выглядеть это может примерно так:

#include <Delayimp.h>

#pragma comment(linker, "/Delay:unload")

.

.

X();

__FUnloadDelayLoadedDLL("MyLib.dll");

Имя, передаваемое функции FUnloadDelayLoadedDLL, должно в точности совпадать с именем, указанным в ключе /DELAYLOAD. Так, если передать ей имя "MYLIB.DLL", библиотека останется в памяти.

В заключение хочется отметить ещё один интересный момент. Когда я попытался воспользоваться отложенной загрузкой в своей программе, линкер отказался подключать библиотеку Delayimp.lib, выдавая сообщение о внутренней ошибке и подробную отладочную информацию. Чтобы решить эту проблему, я просто взял файлы Delayhlp.cpp и Delayimp.h из каталога Vc98\Include, добавил в файл Delayhlp.cpp строки:

PfnDliHook __pfnDliNotifyHook = NULL;

PfnDliHook __pfnDliFailureHook = NULL;

и перестроил эту библиотеку заново. После этого отложенная загрузка заработала нормально.

Ссылки

Поскольку я рассказал об отложенной загрузке далеко не все, рекомендую обратиться за дополнительной информацией к следующим статьям в MSDN:

– December 1998, Microsoft systems journal, Win32 Q&A

– December 1998, Microsoft systems journal, Under the hood

– Linker support for delay-loaded DLLs

Alexander Shargin (rudankort@mail.ru)
ВОПРОС-ОТВЕТ

Q. Все, наверное, знают программы, называемые Viewbar, которые показывают рекламные баннеры. Но вот как они ограничивают часть экрана, не позволяя другим окнам находиться поверх них? Например, если разрешение экрана 800×600, как они выделяют полосу сверху, в которой находятся, т.ч. программы, развернутые на полный экран, имеют высоту где-то на 60 пикселей меньше. Причем и немаксимизированные окна не могут "влезть" в эту полосу.

Alexander Popov

Для рассылки пока уникальный случай: на вопрос ответил сам автор.

A1 Спасибо за опубликование вопроса. Теперь я сам же могу на него ответить. Для создания приложения, похожего на панель задач или панель MS Office, используется AppBar. Последний достаточно хорошо описан в MSDN (см. Extend the Windows 95 Shell with Application Desktop Toolbars, Application Desktop Toolbars) А вообще, достаточно много интересного содержится в Windows Shell API, в частности: работа с панелью задач, как написать ScreenSaver, работа с панелью управления, Band Objects в Internet Explorer.

Alexander Popov

A2 Этого можно добиться, используя функцию SystemParametersInfo. У этой исключительно полезной функции существуют параметры SPI_GETWORKAREA и SPI_SETWORKAREA, позволяющие получить размер рабочей области экрана или установить для неё собственный размер (перед завершением работы программы его рекомендуется восстановить). Напрмер, следующий фрагмент "резервирует" полосу шириной в 100 пикселей в верхней части экрана:

CRect rcOld, rcNew;

SystemParametersInfo(SPI_GETWORKAREA, 0, (PVOID)&rcOld, 0);

rcNew = rcOld;

rcNew.top = 100;

SystemParametersInfo(SPI_SETWORKAREA, 0, (PVOID)&rcNew, 0);

Чтобы восстановить исходный размер, достаточно вызвать:

SystemParametersInfo(SPI_SETWORKAREA, 0, (PVOID)&rcOld, 0);

После того как нужная область зарезервирована, можно, например, поместить туда своё окно (вызовом CWnd::MoveWindow) и лишить пользователя возможности убрать его оттуда (так как в противном случае оно туда не вернётся), после чего рисовать в нём баннеры.

В заключение отмечу, что именно этой функцией пользуются программы типа Magnify.exe из комплекта Windows.

Alexander Shargin (rudankort@mail.ru)

Фактически, ответы, конечно, одинаковые (в статье из MSDN как раз и используется SystemsParametersInfo), просто первый в отличие от самого ответа содержит ссылку на него.

Эти два ответа – все, что я получил. Два из восьми тысяч. Действительно, не очень-то сильно читатели хотят отвечать на вопросы. Так что я по всей видимости был прав по поводу поощрений… Господа! Прошу поактивнее! Или я могу решить что рубрика вам неинтересна и закрою ее…

Многие спрашивают, почему я лично не отвечаю на вопросы. Это неправда, иногда все-таки отвечаю ;)

Ну а главное: посмотрите Microsoft Systems Journal. Там человек В МЕСЯЦ отвечает на ДВА вопроса, причем это – его работа, т.е. он получает за это деньги. Потом, далеко не на всякий вопрос можно сходу дать однозначный ответ. Как правило, те вопросы, для которых можно это сделать – неинтересны. Так что наверное гораздо эффективнее  разделять эту задачу  с читателями.

ОБРАТНАЯ СВЯЗЬ

Alexander Shargin по поводу ответа A1 (Sergey Emantayev) из №21 пишет:

Справедливости ради следует отметить, что всплывающие меню не обновляются в Idle loop'е. В нём обновляются тулбары, статус бар и т.п., но всплывающие меню обновляются только в ответ на WM_INITMENUPOPUP. Этой практики следует придерживаться и в собственных приложениях.

Продолжается дискуссия о комментариях:

Привет, что касается комментариев, то не кажется ли вам, господа, что сам код (естественно, грамотный код) и является самым лучшим и лаконичным комментарием к программе. И вообще, мне кажется, что комментарии нужны только тем людям, которые не писали конкретную программу, и причем, комментировать следует, только ключевые моменты, а если человек просто не понимает кода, то комментируй, не комментируй, это по барабану. Года два назад, я писал, одну небольшую софту, она работала под DDraw в полно-экранном режиме, я колбасил интерфейс a-la X-window Linux, фунций, переменных было море, и я закоментировал только, что и какая переменная делает, недавно, пришлось вернутся к этому коду, я его передал другому, человеку, немного видоизменив. И никаких проблем с восстановлением (в мозгу) архитектуры программы не было, как будто я с ней не работал не два года, а два дня. Код — это и сеть лучший комментарий, ну иногда желательно и присутствие "бумажной" модели программы.

Anton Palagin

У меня к Вам предложение по Вашей рассылки "Vsiual C++" – не могли бы Вы в поле сабжа каждой рассылки в конце ставить темы, которые рассматриваются в данном номере рассылки (например : "WinInet, Tray, Закладки"). Так будет значительно удобнее ориентироваться в архиве рассылке при поиске нужной темы. А то вот искал тот номер, где рассматривался вопрос с помещением программы в Tray и пришлось потратить некоторое время (линейно зависящее от количества вышедших номеров рассылки). А так посмотрел на заголовок и все понятно. А то поиск по сообщениям в Outlook Express глючный какой-то и нифига не находит.

Даниил Иванов

Очень разумное предложение, на мой взгляд. Принял к исполнению – взгляните на subject этого выпуска. Спасибо, Даниил! Правда, в заголовок выношу только главную тему выпуска. Побочные придется искать по-старому.

В ПОИСКАХ ИСТИНЫ

Q. Все знают десктопные программы-ассистенты (screenmates/deskmates, MS Agent). Весь вопрос, что качественных, без артифактов, достаточно мало. Для реализации экранного помошника есть 2 различных подхода (если знаете еще, подскажите): – рисовать поверх десктопа, запоминать-востанавливать фон и т.д. Здесь сложно уследить за случаями, когда другие окна перекрывают место, где выводится текущий кадр персонажа, если на десктопе идет своя жизнь (меняются-появляются иконки, молчу про Drag'n'Drop) – использовать регионы, примеры есть на codeguru, но это достаточно трудоемкая штука – идея проста: создать полностью прозрачное окно и рисовать в нем просто текущий кадр с действием персонажа, не заботясь о том, на каком фоне его рисуешь, ведь окно прозрачное! Т.е. программа может просто рисовать постоянно меняющиеся картинки в таком прозрачном окне и это создаст эффект анимации персонажа, главное тут, чтобы любые изменения фона не влияли, т.е. просто добавление атрибута WS_EX_TRANSPARENT – это не то что нужно

Так вот, внимание, вопрос!

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

Кстати, на кодегуру прямого примера нет точно, а то что есть о том как рисовать прозрачные штучки – не то.

Valery Boronin
АНОНС

Читайте в следующем выпуске

Многозадачность в Windows: теория и практика


Успехов в программировании!

Алекс Jenter jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №23 от 12 ноября 2000 г.

Cын Билла Гейтса приходит к отцу и спрашивает:

"Папа, а что такое многозадачность?"

"Подожди, сынок, вот дискету доформатирую…"

Приветствую вас, уважаемые читатели!

Как я и ожидал, желающих становиться спонсором рассылки пока не нашлось. Ну что ж, ничего не поделаешь – будем придерживаться тогда пока старой системы.

СТАТЬЯ
Многозадачность и ее применение
Или зачем нужна многопоточность простому программисту

Очень многие программисты, перейдя с DOS на Windows, в течение долгого времени все еще стараются программировать по-старому. Конечно, полностью это сделать не получается – такие вещи, как обработка сообщений, являются неотъемлемой частью любого Windows-приложения. Однако, 32-разрядная платформа в силу своей структуры предоставляет программистам новые захватывающие дух возможности. И если вы их не используете, а стараетесь решить проблему так, как привыкли, то вполне естественно, что из этого не получается ничего хорошего.

Эти возможности – возможности многозадачности. Прежде всего очень важно уяснить для себя, КОГДА вам следует подумать об ее использовании в своем приложении. Ответ так же очевиден, как и определение термина "многозадачность" – она нужна тогда, когда вы хотите, чтобы несколько участков кода выполнялось ОДНОВРЕМЕННО. Например, вы хотите, чтобы какие-то действия выполнялись в фоновом режиме, или чтобы в течение ресурсоемких вычислений, производимых вашей программой, она продолжала реагировать на действия пользователя. Я думаю, вы легко сможете придумать еще несколько примеров.

Процессы и потоки

Эти два понятия очень важны, и вы должны постараться их хорошенько осмыслить. Процессом (process) называется экземпляр вашей программы, загруженной в память. Этот экземпляр может создавать потоки (thread), которые представляют собой последовательность инструкций на выполнение. Важно понимать, что выполняются не процессы, а именно потоки. Причем любой процесс имеет хотя бы один поток. Этот поток называется главным (основным) потоком приложения.

Так как практически всегда потоков гораздо больше, чем физических процессоров для их выполнения, то потоки на самом деле выполняются не одновременно, а по очереди. (Заметьте, что распределение процессорного времени происходит именно между потоками, так как, еще раз повторю, процессы не выполняются.) Но переключение между ними происходит так часто, что кажется будто они выполняются параллельно.

В зависимости от ситуации потоки могут находиться в трех состояниях. Давайте посмотрим, что это за состояния. Во-первых, поток может выполняться, когда ему выделено процессорное время, т.е. он может находиться в состоянии активности. Во-вторых, он может быть неактивным и ожидать выделения процессора, т.е. быть в состоянии готовности. И есть еще третье, тоже очень важное состояние – состояние блокировки. Когда поток заблокирован, ему вообще не выделяется время. Обычно блокировка ставится на время ожидания какого-либо события. При возникновении этого события поток автоматически переводится из состояния блокировки в состояние готовности. Например, если один поток выполняет вычисления, а другой должен ждать результатов, чтобы сохранить их на диск. Второй мог бы использовать цикл типа "while (!isCalcFinished) continue;", но легко убедиться на практике, что во время выполнения этого цикла процессор занят на 100% (это называется активным ожиданием). Таких вот циклов следует по возможности избегать, в чем нам оказывает неоценимую помощь механизм блокировки. Второй поток может заблокировать себя до тех пор, пока первый не установит событие, сигнализирующее о том, что чтение окончено.

В системе выделяются два вида потоков – интерактивные, крутящие свой цикл обработки сообщений (такие, как главный поток приложения), и рабочие, представляющие собой простую функцию. Во втором случае поток завершается по мере завершения выполнения этой функции.

Заслуживающим внимания моментом является также способ организации очередности потоков. Можно было бы, конечно, обрабатывать все потоки по очереди, но такой способ далеко не самый эффективный. Гораздо разумнее оказалось ранжировать все потоки по приоритетам. Приоритет потока обозначается числом от 0 до 31, и определяется исходя из приоритета процесса, породившего поток, и относительного приоритета самого потока. Таким образом, достигается наибольшая гибкость, и каждый поток в идеале получает столько времени, сколько ему необходимо.

Иногда приоритет потока может изменяться динамически. Так интерактивные потоки, имеющие обычно класс приоритета Normal, система обрабатывает несколько иначе и несколько повышает фактический приоритет таких потоков, когда процесс, их породивший, находится на переднем плане (foreground). Это сделано для того, чтобы приложение, с которым в данный момент работает пользователь, быстрее реагировало на его действия.

Конечно, эта заметка не претендует на исчерпывающее описание использования многозадачности. Цель этой вводной статьи – заинтересовать темой. В дальнейшем мы с вами поговорим о таких вещах, как создание интерфейсных потоков и синхронизация между потоками. А если вы хотите посмотреть пример создания рабочего потока, то он рассматривался в рассылке №5 от 28 июня.

ВОПРОС-ОТВЕТ

Q. Все знают десктопные программы-ассистенты (screenmates/deskmates, MS Agent). Весь вопрос, что качественных, без артифактов, достаточно мало. Для реализации экранного помошника есть 2 различных подхода (если знаете еще, подскажите): – рисовать поверх десктопа, запоминать-востанавливать фон и т.д. Здесь сложно уследить за случаями, когда другие окна перекрывают место, где выводится текущий кадр персонажа, если на десктопе идет своя жизнь (меняются-появляются иконки, молчу про Drag'n'Drop) – использовать регионы, примеры есть на codeguru, но это достаточно трудоемкая штука – идея проста: создать полностью прозрачное окно и рисовать в нем просто текущий кадр с действием персонажа, не заботясь о том, на каком фоне его рисуешь, ведь окно прозрачное! Т.е. программа может просто рисовать постоянно меняющиеся картинки в таком прозрачном окне и это создаст эффект анимации персонажа, главное тут, чтобы любые изменения фона не влияли, т.е. просто добавление атрибута WS_EX_TRANSPARENT – это не то что нужно

Так вот, внимание, вопрос!

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

Кстати, на кодегуру прямого примера нет точно, а то что есть о том как рисовать прозрачные штучки — не то.

Valery Boronin

A1 Нужно для каждой картинки, входящей в анимацию, делать для окна специальный регион, который включал бы в себя точки, принадлежащие изображению и не включал все остальные. Это можно сделать так (source ниже) : Создать пустой регион, выбрать картинку (bitmap), выбрать прозрачный цвет, проитись по bitmap и для каждого непрозрачного участка в каждой строке bitmap создать регион высотой 1 пиксел и прикомбинировать его к исходному региону. В конце операции установить получившийся регион окну.

void MakeBitmapRegion(HWND hwnd, int int bmp_id) {

 COLORREF back_color;

 CBitmap bmp;

 if (!bmp.LoadBitmap (bmp_id)) return;

 BITMAP bmp_o;

 bmp.GetObject(sizeof(BITMAP), (LPSTR)&bmp_o);

 int w = bmp_o.bmWidth;

 int h = bmp_o.bmHeight;

 HDC wnd_dc = GetDC(hwnd);

 if (hwnd == NULL) return;

 if (wnd_dc == NULL) return;

 HDC hdc_bmp = CreateCompatibleDC(wnd_dc);

 SelectObject(hdc_bmp, HBITMAP(bmp));

 back_color = GetPixel(hdc_bmp, 0, 0);

 int x, x0, y;

 HRGN tmp_rgn, wnd_rgn;

 wnd_rgn = CreateRectRgn(0,0,0,0);

 x = y = 0;

 for (y; y < h; y++) {

  while (x < w-1) {

   while(GetPixel(hdc_bmp, x, y) == back_color && x < w) x++;

   if (x != w) {

    x0 = x;

    while(GetPixel(hdc_bmp, x, y) != back_color && x < w) x++;

    tmp_rgn = CreateRectRgn(x0, y, x, y+1);

    CombineRgn(wnd_rgn, wnd_rgn, tmp_rgn, RGN_XOR);

   }

  }

  x = 0;

 }

 DeleteObject(tmp_rgn);

 DeleteDC(hdc_bmp);

 SetWindowRgn(hwnd, wnd_rgn, TRUE);

 DeleteObject(wnd_rgn);

}

Сергей Егоров

A2 Как сделать полностью прозрачное окно, которое не тащит за собою кусок фона – понятно. Нужно просто перехватить сообщение WM_WINDOWPOSCHANGING и сказать системе, чтобы она не копировала содержимое окна. Для этого в структуре WINDOWPOS, указатель на которую передаётся в функцию окна, предусмотрен флаг SWP_NOCOPYBITS. В MFC обработчик может выглядеть примерно так:

void CMyWnd::OnWindowPosChanging(WINDOWPOS FAR* lpwndpos) {

 lpwndpos->flags |= SWP_NOCOPYBITS;

CWnd::OnWindowPosChanging(lpwndpos);

}

Другой вопрос, что этого явно не достаточно для реализации прозрачного окна. Ведь полностью пустое окно мало кого заинтересует, а если нарисовать в нём что-то, а затем сдвинуть окно, за ним потянется шлейф с нарисованным изображением.

Если прозрачные области в окне статические, то есть способ лучше – воспользоваться SetWindowRgn. Об этой функции писалось в 7-м выпуске рассылки. Но если требуется организовать анимацию на фоне рабочего стола, то, вероятно, не обойтись без сохранения фона с его последующим восстановлением. Дело в том, что многие программы очень медленно перерисовывают свои окна, и поручать им обновление фона под нашим окном не представляется возможным.

Alexander Shargin (rudankort@mail.ru)
ОБРАТНАЯ СВЯЗЬ

К прошлому выпуску:

У меня есть два меленьких примечания к теме "Три способа подключения DLL":

1. При неявном подключении .lib файл можно добавить к проекту с помощью меню "Project\Add to project\Files", выбрав тип файлов *.lib. Об этом все, наверное, знают, но про это не было упоминания в статье.

2.По поводу отложенной загрузки. К сожалению, как сказано в MSDN, такое подключение не позволяет импортировать данные: "Imports of data cannot be supported. A workaround is to explicitly handle the data import yourself using LoadLibrary (or GetModuleHandle after you know the delay-load helper has loaded the DLL) and GetProcAddress.".

Sergey Kuryata

По поводу проблемы, описанной в конце статьи прошлого выпуска:

я не проделывал данных действий, но у меня всё слинковалось и заработало

обычная линковка

#pragma comment(lib, "Delayimp.lib")

проходит, может потому, что установлен SP для MSVC 6.0

Max Stepanov
В ПОИСКАХ ИСТИНЫ

Q. Возникла проблема… Существует sdi-приложение с CFormView-базированным видом. Существует несколько форм также основанных на CFormView. Необходимо динамически изменять основной вид на другие формы в процессе работы программы. Я так понимаю существует два пути. Первый – в OnCreate CMainFrame создавать все формы и потом сортировать их меняя z-порядок и второй – по мере необходимости создавать формы динамически.А вот с реализацией – :(. Или может я не прав? Заранее спасибо.

olegich

Это все на сегодня. Пока!

Алекс Jenter jenter@mail.ru
Красноярск, 2000.

Программирование на visual C++ Выпуск №24 от 19 ноября 2000 г.

Всем привет!

СТАТЬЯ
Как бороться с мерцанием

Вот наконец настал момент, когда работа над программой уже как бы закончена, все вылизано и подчищено, и шедевр вроде не глючит и даже заказчик кажется довольным. И все просто отлично… кроме одной мелочи – при изменении размеров окна элементы управления на форме сильно мерцают. Да, вроде бы мелочь. Да, многие коммерческие приложения тоже мерцают… даже ОЧЕНЬ многие.

Но все-таки от этого создается впечатление какой-то НЕИДЕАЛЬНОСТИ, недоделанности, что ли… И остается неприятный осадок в душе у вас (это еще полбеды!) – и у пользователей вашего приложения (а вот это намного серьезнее).

Windows в силу своего строения не позволит вам писать идеальные программы – даже если вы могли бы это делать – так как система сама далеко не идеальна. (Если кто знает идеальную – подскажите). В этой статье я хочу рассказать, как если уж не совсем убрать, то хотя бы значительно уменьшить такое мерцание, причем как это можно сделать буквально за несколько секунд (Правда звучит совсем как реклама? Мы уже столько ее наслушались, что иногда и мыслим ею ;-)

Но сначала предлагаю вам разобраться, откуда вообще берется это мерцание, т.е. чем оно обусловлено.

Как выясняется, причина всегда одна и та же: какая-то часть вашей программы рисует что-то на экран, а потом другая часть рисует что-то поверх этого. (Под рисованием я подразумеваю и вывод контролов). На короткий момент между двумя этими операциями пользователь может видеть то, что нарисовано раньше.

И хотя причина всегда в принципе одна и та же, есть две разные ситуации, которые нужно рассматривать в плане борьбы с мерцанием.

Если все рисование происходит в одном окне (т.е. где нет контролов; помните, что любой контрол – это тоже окно) всегда можно избавиться от мерцания, если сначала выводить изображение в отдельный контекст устройства в памяти (memory device context), а затем одним махом переносить его на экран. (Этот принцип известен с доисторических времен и использовался еще в очень ранних компьютерных играх). Т.е. создаете в памяти совместимый с экраном контекст (CreateCompatibleDC), рисуете все в него, а затем вызываете BitBlt. О деталях реализации я распространяться не буду, т.к. они достаточно прозаичны. Как говаривал Laurence Fishbourne в "The Matrix", я могу показать вам дверь, а пройти через нее вы должны сами.

Другая ситуация встречается гораздо чаще – когда у вас есть дочерние окна (контролы). Типичным примером является любая форма или диалоговое окно. Главное окно – пустой прямоугольник, где выводятся разные кнопки, списки, строки редактирования… В этом случае, мерцание происходит когда Windows удаляет фон главного окна при вызове InvalidateWindow с fErase=TRUE. Система не удаляет фон сразу же, а ждет следующего цикла перерисовки – который наступает либо когда нечего больше делать, либо когда кто-то его форсировал с помощью UpdateWindow. В любом случае, предже чем посылать WM_PAINT, Windows вежливо просит окно очистить себя, посылая ему сообщение WM_ERASEBKGND. Стандартная процедура обработки сообщений (DefWindowProc) отвечает на это перерисовыванием окна цветом GetSysColor(COLOR_WINDOW+1), обычно белым. После того, как окно очистило фон, система посылает WM_PAINT и окно отрисовывает себя. (В случае формы/диалога, само окно ничего не рисует, а рисуют только дочерние окна. ) В результате получается мерцание: сначала вы видите, как окно целиком очищается, затем – как рисуются дочерние окна. Это мерцание особенно заметно при изменении размера окна, потому что система постоянно стирает и выводит заново все элементы управления. И чем их больше, тем сильнее мерцание.

Если вы специалист по програмированию в Windows, то можете подумать, что решение состоит в перехвате каким-либо образом сообщения WM_ERASEBKGND. Это хорошая идея, но есть способ проще. Один из стилей окна, который вы можете указать при его создании –  WS_CLIPCHILDREN. Этот стиль сообщает Windows, что каждый раз, когда программа или сама система пытаются отобразить содержимое окна, области занятые дочерними окнами должны остаться нетронутыми. Так что все, что нужно сделать, чтобы значительно уменьшить мерцание контролов – указать родительскому окну стиль  WS_CLIPCHILDREN. За это, конечно, вы платите незначительным уменьшением скорости, но все-таки это лучше, чем мерцание.

К сожалению, вышеописанный способ не работает, если некоторые контролы частично пустые – т.е. зависят от того, чтобы родительское окно отобразило фон за ними (это происходит при использовании hollow brush). В этом случае нужно будет унаследовать класс от этого контрола, где должным образом позаботиться о фоне.

Cтатья основана на материалах C++ Q&A (MSDN)
ВОПРОС-ОТВЕТ

Q. Возникла проблема… Существует sdi-приложение с CFormView-базированным видом. Существует несколько форм также основанных на CFormView. Необходимо динамически изменять основной вид на другие формы в процессе работы программы. Я так понимаю существует два пути. Первый – в OnCreate CMainFrame создавать все формы и потом сортировать их меняя z-порядок и второй – по мере необходимости создавать формы динамически.А вот с реализацией – :(. Или может я не прав? Заранее спасибо.

olegich

A1 В начале немного теории.

В технологии Документ/Представление у документа (class CDocument) может быть несколько представлений (class CView и его наследники), которые в свою очередь находяться (отображаются) во Фреймах (CFrameWnd). Представление может отображаться только в одном Фрейме, но во Фрейме могут отображаться несколько представлений.

Как я понял вопрос был по поводу динамического переключения Представлений (т.е. класса CView и/или любого его наследника, которым и является класс CFormView) внутри одного Фрейма. Библиотека MFC прямого решения не предоставлет, но тем не менее такая возможность есть. MFC каждому представлению присваивает идентификатор от AFX_IDW_PANE_FIRST до AFX_IDW_PANE_LAST (всего 256 вчем легко убедиться посмотрев их значения) но на экран отображается только Представление с ID=AFX_IDW_PANE_FIRST. Поэтому задача сводиться к корретному изменению ID.

Теперь практика. Пусть имеется готовое SDI приложение (с технологией Документ/Представление). Создаем дополнительное Представление. Это делается в функции CFrameWnd::OnCreateClient примерно так:

BOOL CMainFrame::OnCreateClient(LPCREATESTRUCT lpcs, CCreateContext* pContext) {

 // class CNewView – это наше новое представление

 pContext->m_pNewViewClass = RUNTIME_CLASS(CNewView);

 // обратите внимание на идентификатор нового Представления

 // переменная m_pNewView описана в CMainFrame как CNewView* m_pNewView;

 m_pNewView = STATIC_DOWNCAST(CNewView, CreateView(pContext, AFX_IDW_PANE_FIRST+1));

 m_pNewView->ShowWindow(SW_HIDE); // для сброса флага WS_VISIBLE

 return CFrameWnd::OnCreateClient(lpcs, pContext);

}

Теперь нам нужна функция переключения активного Представления на Представление только что нами созданное.

void CMainFrame::SwitchView(CView *pView) {

 CFormView *pNewView=STATIC_DOWNCAST(CFormView, pView),

 *pActiveView=STATIC_DOWNCAST(CFormView, GetActiveView());

 if (pNewView!=NULL && pActiveView!=NULL) {

  UINT tempID=::GetWindowLong(pActiveView->GetSafeHwnd(), GWL_ID);

  ::SetWindowLong(pActiveView->GetSafeHwnd(), GWL_ID, ::GetWindowLong(pNewView->GetSafeHwnd(), GWL_ID));

  ::SetWindowLong(pNewView->GetSafeHwnd(), GWL_ID, tempID);

  pActiveView->ShowWindow(SW_HIDE);

  pNewView->ShowWindow(SW_SHOW);

  pNewView->OnInitialUpdate();

  SetActiveView(pNewView);

  RecalcLayout(); // можно делать можно и не делать

  pNewView->Invalidate();

 }

}

Похожий способ описан в Microsoft Knowledge Base (Q141334 – проект VSWAP32).

Ilya Zharkov

A2 Как и указывается в вопросе, эту задачу можно решать различными способами. Если виды переключаются часто, логичнее создать их один раз, а затем показывать один из них и скрывать все остальные. Если их переключают редко, имеет смысл создавать их динамически. Рассмотрим оба варианта.

Способ 1.

Сначала создаём все нужные нам виды. Поскольку в нормальном SDI-приложении вид, прописанный в шаблоне документа, создаётся в функции CFrameWnd::OnCreateClient, вполне естественно создать в ней и все остальные виды. Для этой цели удобно воспользоваться функцией CFrameWnd::CreateView, которая вызовет за нас и CView::CreateObject, и CView::Create с нужными параметрами. Всё, что требуется от нас – это подменить член m_pNewViewClass в структуре CCreateContext, указатель на которую передаётся в OnCreateClient. Выглядит это следующим образом.

BOOL CMainFrame::OnCreateClient(LPCREATESTRUCT lpcs, CCreateContext* pContext) {

 CRuntimeClass *ppFormViewClasses[] = {

  RUNTIME_CLASS(CFormView1),

  RUNTIME_CLASS(CFormView2)

  // :

 };

 for(int i=0; i < sizeof(ppFormViewClasses)/sizeof(CRuntimeClass*); i++) {

  pContext->m_pNewViewClass = ppFormViewClasses[i];

  if (!CreateView(pContext, AFX_IDW_PANE_FIRST+i+1))

  return FALSE;

 }

 SwitchView(AFX_IDW_PANE_FIRST+1);

 return TRUE;

}

Чтобы использовать этот фрагмент в реальной программе, нужно подставить правильные имена классов в массив ppFormViewClasses. Функция SwitchView добавляется в класс главного окна приложения и используется каждый раз, когда нужно переключиться с одного вида на другой. Она получает идентификатор нужного вида (в приведённом выше коде виды получают идентификаторы от AFX_IDW_PANE_FIRST+1 до AFX_IDW_PANE_FIRST, где N – число видов, но это поведение легко изменить на любое другое). Её код может выглядеть так:

void CMainFrame::SwitchView(UINT ID) {

 if(ID == m_CurID) return;

 CView *pOldView;

 CView *pNewView;

 pOldView = GetActiveView();

 pNewView = (CView *)GetDlgItem(ID);

 if (pOldView) {

  pOldView->SetDlgCtrlID(m_CurID);

  pOldView->ShowWindow(SW_HIDE);

 }

 m_CurID = ID;

 pNewView->SetDlgCtrlID(AFX_IDW_PANE_FIRST);

 pNewView->ShowWindow(SW_SHOW);

 SetActiveView(pNewView);

 RecalcLayout();

 RecalcLayout();

}

Чтобы эта функция работала правильно, необходимо добавить переменную m_CurID типа UINT в класс главного окна. В ней временно хранится идентификатор текущего вида, поскольку при переключении он заменяется на AFX_IDW_PANE_FIRST. Это необходимо, так как функции класса CFrameWnd во многих местах предполагают, что идентификатор активного вида именно такой.

Способ 2.

Его реализация проще. Допустим, нам требуется создать для просмотра документа вид класса CSomeView. Для этого мы уничтожаем текущий вид, создаём новый и перерисовываем экран. Функцию, которая делает всё это, можно вставить в класс главного окна. Выглядит она так:

void CMainFrame::ReplaceView(CRuntimeClass *pRuntimeClass) {

 CView *pActiveView = GetActiveView();

 if(pActiveView->IsKindOf(pRuntimeClass)) return;

 CCreateContext context;

 context.m_pCurrentDoc = GetActiveView()->GetDocument();

 context.m_pNewViewClass = pRuntimeClass;

 context.m_pCurrentFrame = this;

 SetActiveView((CView *)CreateView(&context, AFX_IDW_PANE_FIRST));

 pActiveView->DestroyWindow();

 RecalcLayout();

}

Эта функция вызывается следующим образом:

ReplaceView(RUNTIME_CLASS(CSomeView));

Обратите внимание, что во втором случае функция OnInitialUpdate будет вызвана только для первого вида (который прописан в шаблоне документа). Если она выполняет важные действия и в других классах, можно добавить её вызов в функцию ReplaceView.

В заключение отмечу, что я нигде не использовал тот факт, что виды порождаются от CFormView. Поэтому описанные мною способы годятся для любых других видов (например, порождённых от CScrollView или CListView).

Alexander Shargin
В ПОИСКАХ ИСТИНЫ

Q. У меня вопрос для гуру. В конференциях от пару раз возникал, но как-то так тихо и кончался. То ли это очевидная истина, то ли никто не знает (чему я не верю). Итак вопрос: как в программу на правую кнопку подцепить меню, такое же как в Експлорере? Как туда напихать свои элементы? Второй второй вопрос отпадает, если можно выцепить именно меню, а не какую-то системную функцию, которая выводит окно меню, а тебе с этим сприходится смиряться, как с фактом бытия этого экранного элемента…

Serg Loginov

Это все на сегодня. Пока!

Алекс Jenter jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №25 от 26 ноября 2000 г.

Приветствую вас, уважаемые подписчики!

СТАТЬЯ
Профилирование : анализ и оптимизация

Профилирование – это очень мощный инструмент анализа поведения вашей программы, позволяющий во время ее выполнения выявить "узкие места", где происходит падение производительности. С помощью профилирования можно получить статистику вызова функций, чтобы в дальнейшем использовать эту информацию при оптимизации кода. Ведь каждому понятно, что нет смысла оптимизировать функцию, вызывающуюся всего пару раз. При использовании MFC это тем более актуально, т.к. многие вызовы не всегда очевидны для программиста.

Еще одна причина использования профилирования – это контроль за качеством тестов. Такой контроль предоставляет информацию о том, осуществляет ли данный тест вызов и обработку результатов выполнения всех без исключения подпрограмм, и какие строки кода при этом выполняются.

Профилирование по сути совершенно НЕ аналогично отладке, и используется с другой целью: не для отлова ошибок, а для улучшения работы приложения – в подавляющем большинстве случаев, это равносильно "для увеличения скорости работы".

Итак, профилирование используется для того, чтобы определить:

1. Оптимален ли использованный алгоритм (по времени);

2. Слишком большое (или слишком малое) количество вызовов подпрограммы;

3. Покрывается ли участок кода тестирующими процедурами.

Приведу пример из жизни: в программе, осуществляющей доступ к данным из файла MS Access, наблюдалось катастрофичное падение производительности при превышении объема данных определенной величины, причем относительно небольшой (порядка 500 записей). Применение профилирования позволило мгновенно выяснить, что подпрограмма, извлекающая данные из базы, совершенно здесь не при чем, а всему виной подпрограмма, заносящая данные в таблицу на экране. После внесения соответствующих изменений, все отлично (т.е. БЫСТРО) заработало, причем скорость программы при просмотре записей практически перестала зависеть от объема данных.

Разделяют два вида профилирования: по функциям и по строкам кода.

Профилирование по функциям полезно для выявления неэффективного кода. Также оно быстрее, чем профилирование по строкам, т.к. приходится собирать меньше информации. Включает в себя следующие измерения:

• суммарный объем времени, в течение которого выполнялась функция + количество вызовов этой функции (function timing),

• только количество вызовов функции (function counting),

• список ни разу не вызывавшихся функций (function coverage),

• запись содержимого стека при каждом вызове функции (function attribution).

Профилирование по строкам используется для проверки алгоритмов, т.к. позволяет посмотреть, сколько раз была выполнена каждая строчка, а также выявить строки, не выполнившиеся вообще ни разу. Здесь есть только два варианта: подсчет строк (line counting) – т.е. сколько раз данная строка была выполнена; и покрытие строк (line coverage) – показывает те строки, которые выполнялись хотя бы раз.

Перейдем к практике. Если у вас установлен Visual C++ Professional или Enterprise Edition, то профилировщик у вас есть, он встроен в IDE. Осталось только научиться им пользоваться. Предугадывая поток писем, замечу, что существует довольно большой выбор всяческих профилировщиков от сторонних фирм, возможности которых иногда действительно впечатляют. Но в данной статье я кратко рассмотрю возможности профилирования, встроенные в Visual C++.

Прежде всего необходимо установить опции проекта для включения профилирования (т.е. генерации профилировочной информации). Это делается через Project Settings|Link|Enable Profiling.

Дальше выберите Build|Profile, и появится диалог "Profile", где можно выбрать любой тип профилирования, плюс еще есть возможность как следует это все настроить с помощью Custom Options (см. параметры команды PREP). Примечательна также опция Merge – позволяет совместить текущие результаты с предыдущими для наглядного сравнения. После нажатия на "OK" запускается ваша программа – дальше вы производите те действия, которые вам необходимо проверить. По завершении работы вашего приложения, профилировочная информация выводится в Profile Output Window, где вы ее анализируете… и делаете выводы.

И напоследок, несколько советов.

1. Не стоит профилировать все приложение целиком, лучше сконцентрироваться на каких-то отдельных частях, представляющих наибольший интерес. (См. параметры /EXC и /INC). Есть много частей, которые просто нет смысла профилировать – такие, как пользовательский интерфейс, например.

2. Замеры не всегда будут точными, поэтому имеет смысл брать среднее значение от нескольких проходов. Собирать статистику за несколько проходов можно с помощью опции Merge.

3. Когда вы профилируете, постарайтесь, чтобы количество запущенных процессов в системе было минимальным.

4. Лучше отсоединиться от локальной сети или интернета, чтобы ОС не приходилось принимать входящие пакеты.

5. Следите за количеством вызовов. Например, у вас в алгоритме есть итерация на тысячу повторений – проследите, чтобы функции, которыми он пользуется, вызывались соответствущее число раз.

6. Время, в течение которого выполняется функция, включает также и время, в течение которого выполнялись все функции, вызванные из данной.

Заинтересовавшимся данной темой предлагаю следующие статьи в MSDN:

• Performance Tuning

• Using Profile, PREP and PLIST

• Profiling from the Development Environment

ВОПРОС-ОТВЕТ

Q. У меня вопрос для гуру. В конференциях от пару раз возникал, но как-то так тихо и кончался. То ли это очевидная истина, то ли никто не знает (чему я не верю). Итак вопрос: как в программу на правую кнопку подцепить меню, такое же как в Експлорере? Как туда напихать свои элементы? Второй второй вопрос отпадает, если можно выцепить именно меню, а не какую-то системную функцию, которая выводит окно меню, а тебе с этим сприходится смиряться, как с фактом бытия этого экранного элемента…

Serg Loginov

A1 Контекстное (правокнопочное) меню создать довольно просто:

1. Добавляем в графическом редакторе новое пустое меню.

2. Для крайнего слева элемента верхнего уровня вводим какое-нить имя и в полученное раскрывающееся меню добавляем команды.

3. Вставляем обработчик сообщения  WM_CONTEXTMENU в класс "вид" или в класс другого окна, получающего сообщения от кнопок мыши, ну, например, в CMyDialog. Обработчик этот программируем так:

CMyDialog::OnContextMenu(CWnd* pWnd, CPoint point) {

 CMenu menu;

 menu.LoadMenu(IDR_MYMENU);

 menu.GetSubMenu(0)->TrackPopupMenu(TPM_LEFTALIGN | TPM_RIGHTBUTTON, point.x, point.y, this);

}

Вот и все. TrackPopupMenu и занимается выводом контекстного меню на экран. Правда, объект класса CMenu лучше сделать мембером класса, тогда в любой функции можно будет удалять, добавлять, запрещать etc. элементы меню. Конечно, в этом случае m_Menu.LoadMenu(IDR_MYMENU); надо написать в OnInitDialog. Заметте, OnContextMenu получает координаты курсора, т.е. можем для разных областей окна элементарно выводить разные меню, просто проверяя координаты.

Sergey Pochechuev

A2 В Windows все файлы и папки входят в иерархию объектов оболочки. В неё также входят и объекты, не имеющие отношение к файловой системе: корзина, рабочий стол и т. п. Windows Explorer является по сути программой для просмотра этой иерархии объектов.

Каждый объект оболочки обязан реализовывать COM-интерфейс IShellFolder. Многие объекты реализуют и ряд других интерфейсов. Так, IExtractIcon отвечает за иконку объекта, а IContextMenu – за его контекстное меню. Эксплорер использует эти (и другие) интерфейсы, чтобы корректно отображать элементы иерархии объектов и позволять пользователю манипулировать ими. Мы также можем воспользоваться этими интерфейсами.

Итак, нам требуется функция, которая выводила бы контекстное меню для заданного файла (каталога), который передавался бы ей в качестве параметра. Эта функция должна выполнить следующие действия:

• Получить интерфейс IContextMenu для этого файла (каталога).

• Создать всплывающее меню (посредством CreatePopupMenu).

• Заполнить его элементами с помощью IContextMenu::QueryContextMenu.

• Показать меню пользователю (TrackPopupMenu).

• Выполнить выбранную команду посредством IContextMenu::InvokeCommand.

Основную сложность на самом деле представляет первый этап. Получить указатель на IContextMenu мы можем только, имея указатель на базовый интерфейс IShellFolder, но Windows не предоставляет простого способа получить этот указатель. Выполнение этой задачи в свою очередь распадается на несколько шагов:

– Получить интерфейс IShellFolder рабочего стола посредством SHGetDesktopFolder.

– Построить LPITEMIDLIST для заданного файла (каталога), используя IShellFolder::ParseDisplayName.

– Получить IShellFolder для этого файла вызовом IShellFolder::BindToObject.

Функция, которая отображает контекстное меню, может выглядеть примерно так (я снабдил её подробными комментариями).

void ShowContextMenu (CWnd *pWnd, LPCTSTR pszPath, CPoint point) {

 // Строим полное имя.

 TCHAR tchPath[MAX_PATH];

 GetFullPathName(pszPath, sizeof(tchPath)/sizeof(TCHAR), tchPath, NULL);

 // Если нужно, перекодируем ANSI в UNICODE.

 WCHAR wchPath[MAX_PATH];

 if(IsTextUnicode (tchPath, lstrlen (tchPath), NULL)) lstrcpy ((char *)wchPath, tchPath);

 else MultiByteToWideChar(CP_ACP, 0, pszPath, -1, wchPath, sizeof(wchPath)/sizeof(WCHAR));

 // Получаем интерфейс IShellFolder рабочего стола

 IShellFolder *pDesktopFolder;

 SHGetDesktopFolder(&pDesktopFolder);

 // Преобразуем путь в LPITEMIDLIST

 LPITEMIDLIST pidl;

 pDesktopFolder->ParseDisplayName(pWnd->m_hWnd, NULL, wchPath, NULL, &pidl, NULL);

 // Получаем интерфейс IShellFolder для заданного файла (папки)

 IShellFolder *pFolder;

 pDesktopFolder->BindToObject(pidl, NULL, IID_IShellFolder, (void**)&pFolder);

 // Получаем интерфейс IContextMenu для заданного файла (папки)

 IContextMenu *pContextMenu;

 pFolder->GetUIObjectOf(pWnd->m_hWnd, 1, (LPCITEMIDLIST*)&pidl, IID_IContextMenu, NULL, (void**)&pContextMenu);

 // Создаём меню

 CMenu PopupMenu;

 PopupMenu.CreatePopupMenu();

 // Заполняем меню

 pContextMenu->QueryContextMenu(PopupMenu.m_hMenu, 0, 1, 0x7FFF,CMF_EXPLORE);

 // Отображаем меню

 UINT nCmd = PopupMenu.TrackPopupMenu(TPM_LEFTALIGN|TPM_LEFTBUTTON|TPM_RIGHTBUTTON|TPM_RETURNCMD, point.x, point.y, pWnd);

 // Выполняем команду (если она была выбрана)

 if(nCmd) {

  CMINVOKECOMMANDINFO ici;

  ZeroMemory(&ici, sizeof(CMINVOKECOMMANDINFO));

  ici.cbSize = sizeof(CMINVOKECOMMANDINFO);

  ici.hwnd = pWnd->m_hWnd;

  ici.lpVerb = MAKEINTRESOURCE(nCmd-1);

  ici.nShow = SW_SHOWNORMAL;

  ContextMenu->InvokeCommand(&ici);

 }

 // Получаем интерфейс IMalloc.

 IMalloc *pMalloc;

 SHGetMalloc(&pMalloc);

 // Используем его для освобождения памяти, выделенной на ITEMIDLIST

 pMalloc->Free(pidl);

 // Освобождаем все полученные интерфейсы

 pDesktopFolder->Release();

 pFolder->Release();

 pContextMenu->Release();

 pMalloc->Release();

 return;

}

Эту функцию можно вызывать, например, из обработчика OnContextMenu. Делается это так:

void CMyView::OnContextMenu(CWnd* pWnd, CPoint point) {

 ShowContextMenu(pWnd, "C:\\command.com", point);

}

За дополнительной информацией следует обратиться к следующим статьям в MSDN:

– Periodicals 1997, Microsoft Systems Journal, April, Wicked Code

– Knowledge Base, статья ID: Q198288

– Описание IShellFolder и IContextMenu

Что касается второго вопроса (о создании собственных пунктов меню), мы имеем полный контроль над процессом создания меню, а значит можем делать с ним всё, что угодно. Нужно только иметь в виду 2 момента.

Во-первых, поскольку функция TrackPopupMenu вызывается с флагом TPM_RETURNCMD, она на будет отправлять окну сообщение WM_COMMAND. Поэтому нужно анализировать значение nCmd, возвращённое функцией TrackPopupMenu и вызывать нужный обработчик вручную. Например:

UINT nCmd = PopupMenu.TrackPopupMenu(…);

if (nCmd) {

 if (nCmd == 0x8000) {

  AfxMessageBox("It works!!!");

 } else {

  // Используем IContextMenu::InvokeCommand

 }

}

Во-вторых, функция IContextMenu::QueryContextMenu получает параметры idCmdFirst, idCmdLast (в примере выше они равны 1 и 0x7FFF соответственно). Идентификаторы для стандартных пунктов меню выбираются именно в диапазоне от idCmdFirst до idCmdLast. Поэтому нужно проследить, чтобы идентификаторы пользовательских пунктов меню в этот диапазон не попали.

Alexander Shargin
ОБРАТНАЯ СВЯЗЬ

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

Нужно просто создать обработчик события WM_ERASEBKGND с одной-единственной строчкой:

BOOL CSomeClass::OnEraseBkgnd(CDC* pDC) {

 return FALSE;

}

Т.е., по-русски говоря, программа фон не очистила, рисуйтесь полностью.

Vlad

На ответ A1 из прошлого выпуска:

Теперь практика. Пусть имеется готовое SDI приложение (с технологией Документ/Представление). Создаем дополнительное Представление. Это делается в функции CFrameWnd::OnCreateClient примерно так:

BOOL CMainFrame::OnCreateClient(LPCREATESTRUCT lpcs, CCreateContext* pContext) {

 // class CNewView – это наше новое представление

 pContext->m_pNewViewClass = RUNTIME_CLASS(CNewView);

 // обратите внимание на идентификатор нового Представления

 // переменная m_pNewView описанна в CMainFrame как

 CNewView* m_pNewView;

 m_pNewView = STATIC_DOWNCAST(CNewView, CreateView(pContext, AFX_IDW_PANE_FIRST+1));

 m_pNewView->ShowWindow(SW_HIDE); // для сброса флага WS_VISIBLE

 return CFrameWnd::OnCreateClient(lpcs, pContext);

}

Этот код работает неправильно, причём это видно даже невооружённым взглядом. В последней строчке функции CMainFrame::OnCreateClient вызывается функция базового класса. Но ведь поле pContext->pNewViewClass уже изменилось! В результате вместо двух разных видов будет создано два одинаковых. Ошибка лечится переносом вызова функции из базового класса в начало переопределённой функции:

BOOL CMainFrame::OnCreateClient(LPCREATESTRUCT lpcs, CCreateContext* pContext) {

 int nResult = CFrameWnd::OnCreateClient(lpcs, pContext);

 …

 return nResult;

}

Кроме того, неясно, как использовать функцию SwitchView. Указатель на созданный нами вид хранится в m_pNewView, но для получения указателя на вид, созданный самой MFC, не видно удобного способа. Вероятно, лучший вариант – также сохранить его в члене класса CMainFrame.

Alexander Shargin
В ПОИСКАХ ИСТИНЫ

Q. У меня dialog-base приложение, живет в systray. Необходимо, чтобы приложение при повторном запуске находило уже запущеный экземпляр программы и активизировало его. Я пытался сделать это через FindWindow(), в которую передается имя зарегистрированного класса окна, и заголовок окна, которое разыскивается. По заголовку я искать не могу, так как он все время у меня меняется. Следовательно, нужно искать по зарегистрированному имени класса окна. Вот тут то и начинается проблема. Я его не знаю. MFC сама их раздает dialog-based приложениям. А переопределить это имя можно было бы в PreCreateWindow(), но этот метод CDialog не наследует из CWnd. Во всех остальных методах, имя класса уже зарегистрированно, т.е. менять его поздно. Как быть?

el-f

Это все на сегодня. До новых встреч!

Алекс Jenter jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №26 от 3 декабря 2000 г.

Здравствуйте!

Итак, вот уж и зима на дворе… Время, когда отходить от компьютера не хочется даже ненадолго ;) Правда, это если у вас в комнате достаточно тепло. В другом случае не хочется вылезать из-под трех одеял;)

IDE

В прошлом выпуске мы с вами говорили о профилировании программ. Некоторые читатели просили также рассказать обо всех богатых возможностях отладки, которые предлагает Visual C++. Александр Шаргин, наш постоянный автор, любезно предложил написать в рассылку статью на эту тему. Думаю, что даже умеющие пользоваться отладчиком программисты найдут в ней для себя много интересного.

Использование отладчика в Visual C++

В этой статье я очень кратко расскажу о возможностях встроенного отладчика Visual C++.

Запуск отладки

Чтобы запустить программу на отладку, нужно выбрать одну из команд меню Build->Start Debug. Обратите внимание, что команда Attach to Process позволяет подключиться к уже запущенному процессу.

Точки останова (Breakpoints)

Точки останова служат для прерывания программы, выполняемой в отладчике. Их можно привязывать к конкретной строке в коде программы, к переменной или к сообщению Windows. После того как программа прервана, её можно выполнять в пошаговом режиме или просто проанализировать значения переменных, после чего продолжить выполнение.

Чтобы установить точку останова на строку вашей программы, достаточно выбрать команду Insert/Remove Breakpoint или нажать F9. Однако гораздо больше возможностей предоставляет окно Breakpoints из меню Edit. В нижней части этого окна находится список уже поставленных точек останова (любую из них можно активизировать, отключить или удалить), а вверху расположены три вкладки, предназначенные для установки точек останова различных типов.

Вкладка Location

Здесь устанавливаются точки останова, привязанные к конкретным строкам в вашей программе. Адрес точки останова задаётся в поле Break at в виде {имя_функции, имя_файла_cpp, имя_файла_exe} @номер_строки

Для формирования адреса можно воспользоваться окном Advanced breakpoint; чтобы вызвать это окно, щелкните на стрелке справа от поля ввода и выберите пункт Advanced. Обычно достаточно задать только номер строки и имя файла с исходным кодом.

В окне Condition можно дополнительно указать условие срабатывания точки останова. Условием может быть любое выражение. Если заданное вами выражение имеет тип bool, точка останова срабатывает, когда оно истинно; в противном случае она срабатывает при изменении значения выражения.

Бывают случаи, когда точку останова нужно пропустить несколько раз, прежде чем прерывать на ней программу. Специально для этого в окне Condition предусмотрено ещё одно поле Skip count (в самом низу). С помощью этого поля можно, к примеру, пропустить 10 итераций цикла и прервать программу только на одиннадцатой.

Вкладка Data

На этой вкладке устанавливаются точки останова по данным. Их отличие состоит в том, что они могут сработать в любом месте программы, как только изменится (или станет истинным) введённое вами выражение.

Если выражение имеет смысл только в определённом контексте (например, в нём используются локальные переменные какой-либо функции), этот контекст необходимо указать с помощью всё того же окна Advanced breakpoint, но здесь уже важно указать имя функции, а не файла.

Вкладка Messages

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

LRESULT WINAPI WndProc(HWND, UINT, WPARAM, LPARAM);

В программах, использующих MFC, удобнее ставить точки останова в соответствующие обработчики сообщений.

Пошаговая отладка

После того, как программа прервана, её можно выполнять в пошаговом режиме. Для этого в отладчике предусмотрены следующие команды (из меню Debug).

Go (F5) – продолжить выполнение программы до следующей точки останова.

Step Into (F11) – выполнить одну инструкцию; если это вызов функции, точка выполнения перемещается на первую инструкцию этой функции.

Step Over (F10) – выполнить одну инструкцию; если это вызов функции, то она выполняется целиком.

Step Out (Shift+F11) – выполнять программу до возврата из текущей функции.

Run to Cursor (Ctrl+F10) – эквивалентна установке временной точки останова с последующим вызовом команды Go.

Иногда в процессе отладки возникает необходимость перенести точку выполнения. Например, вы заметили ошибку и хотите "перескочить" через неё или, наоборот, хотите вернуться немного назад и выполнить фрагмент программы ещё раз. Чтобы это сделать, установите курсор в нужном месте и выберите команду Set Next Statement из контекстного меню (или нажмите Ctrl+Shift+F10).

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

Окно Variables

В этом окне автоматически отображаются значения локальных переменных (вкладка Locals), переменных-членов класса, адресуемого указателем this (вкладка This), а также всех переменных, которые используются в предыдущей и текущей строках программы (вкладка Auto). На вкладке Auto также показываются возвращаемые значения функций.

Чтобы изменить значение переменной в окне Variables, достаточно просто два раза кликнуть на старом значении и ввести новое.

Выпадающий список Context позволяет просматривать локальные переменные любой из вызванных в данный момент функций. Кроме того, код выбранной в нём функции отображается в окне редактора.

Вы, вероятно, заметили, что отладчик "умеет" распознавать стандартные структуры данных (CString, RECT и т. п.) и показывать их содержимое в удобном виде. Оказывается, можно не только изменить представление этих структур в окне Variables, но и определить представление для собственных структур. Для этого нужно отредактировать файл autoexp.dat, расположенный в каталоге :\Common\MSDev98\Bin. Описание формата приводится в самом файле.

Окно Watch

Окно Watch позволяет просматривать значения переменных и выражений. Переменные и выражения можно размещать на любой из четырёх вкладок. Добавить переменную или выражение в окно Watch можно одним из следующих способов:

– Ввести с клавиатуры

– Перетащить из окна редактора или из окна Variables

– Добавить из окна Quick watch

Чтобы изменить значение переменной, достаточно два раза кликнуть на старом значении и ввести новое. Значение выражений изменять нельзя.

Чтобы узнать тип переменной или выражения, нужно щёлкнуть по ним правой кнопкой и выбрать Properties из всплывающего меню.

В окне Watch можно наблюдать любые регистры процессора и изменять их значения, хотя это удобнее делать в окне Registers. Можно также использовать регистры в выражениях.

Можно указать отладчику, в каком формате выводить значение переменной/выражения, используя флаги форматирования. Эти флаги добавляются к имени переменной или выражению через запятую. Большинство из них совпадает с символами форматирования функции printf: d – целое число со знаком, u – беззнаковое целое, f – число с плавающей точкой, c – символ, s – строка и т. д. Однако есть четыре флага, на которых я хочу остановиться подробнее.

Флаг wm превращает код сообщения в его название, например:

0x01,wm = WM_CREATE

Флаг wc позволяет стиль окна, например:

0x6840000,wc = _OVERLAPPEDWINDOW WS_CLIPSIBLINGS WS_CLIPCHILDREN

Флаг hr переводит коды ошибок Win32 и значения HRESULT, возвращаемые функциями COM, в удобочитаемый вид, например:

0x02,hr = 0x00000002 Системе не удается найти указанный файл.

Наконец, в Visual C++ есть числовой флаг, который позволяет просмотреть заданное количество элементов массива, адресуемого указателем (по умолчанию показывается всего один элемент). Допустим, мы выделили динамический массив из 10 целых чисел:

Int *pInt = new[10];

Чтобы просмотреть его содержимое в окне Watch, нужно ввести:

pInt,10

Псевдорегистр ERR

Как известно, получить расширенный код ошибки после вызова функций Win32 API можно с помощью GetLastError. Однако расставлять по всей программе вызовы GetLastError крайне неудобно. Поэтому в отладчике Visual C++ предусмотрен специальный псевдорегистр ERR, который всегда содержит расширенный код ошибки. Особенно удобно наблюдать значение этого регистра, использую уже знакомый нам флаг hr. Добавьте ERR,hr в окно Watch, и информация об ошибках в вызовах функций API всегда будет у вас перед глазами.

Другие окна отладчика

Окно Registers. Позволяет просматривать и изменять значения регистров процессора.

Окно Memory. Позволяет просматривать и изменять содержимое ячеек памяти.

Окно Call Stack. Показывает последовательность вызванных функций. Используя контекстное меню, можно отобразить также типы и значения параметров этих функций. К тексту любой функции можно переместиться, сделав двойной щелчок на её имени. Обратите внимание, что точки останова можно ставить прямо в этом окне.

Окно Disassembly. Показывает текст отлаживаемой программы на языке ассемблера. Иногда без помощи этого окна ошибку в программе найти не удаётся.

Диалоги

Диалоги отладчика предоставляют вам ряд дополнительных возможностей. Они вызываются из меню Debug.

Quick Watch. Имеет возможности, аналогичные возможностям окна Watch, с той разницей, что в нём можно просматривать только одну переменную за раз. Используется, когда вам не хочется добавлять переменную в окно Watch.

Exceptions. Позволяет настроить реакцию отладчика на возникновение системных и пользовательских исключений.

Threads. Показывает список активных потоков. Позволяет приостановить (suspend) или продолжить (resume) поток, а также установить на него фокус.

Modules. Показывает список загруженных модулей. Для каждого модуля выводится диапазон адресов и имя файла.

Edit and Continue

В заключение хотелось бы упомянуть о новой мощной возможности, которая появилась в Visual C++ 6.0 – Edit and Continue. С её помощью вы можете вносить изменения в код программы и перестраивать её, не прерывая сеанса отладки.

Для этого достаточно вызвать команду Apply code changes из меню Debug (или нажать Alt+F10), после того как вы подправили исходные тексты. Более того, Visual C++ может вызывать для вас эту команду автоматически. Это будет происходить, если в окне Tools->Options на вкладке Debug установить флаг Debug commands invoke Edit and Continue.

Александр Шаргин
ВОПРОС-ОТВЕТ

Q. У меня dialog-base приложение, живет в systray. Необходимо, чтобы приложение при повторном запуске находило уже запущеный экземпляр программы и активизировало его. Я пытался сделать это через FindWindow(), в которую передается имя зарегистрированного класса окна, и заголовок окна, которое разыскивается. По заголовку я искать не могу, так как он все время у меня меняется. Следовательно, нужно искать по зарегистрированному имени класса окна. Вот тут то и начинается проблема. Я его не знаю. MFC сама их раздает dialog-based приложениям. А переопределить это имя можно было бы в PreCreateWindow(), но этот метод CDialog не наследует из CWnd. Во всех остальных методах, имя класса уже зарегистрированно, т.е. менять его поздно. Как быть?

el-f

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

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

AОтносительно вопроса, заданного в №25 данной рассылки хотелось бы сразу высказать сильное сомнение по поводу возможности его решения при помощи использования имен оконных классов. Мне кажется, что каждый экземпляр приложения в операционной системе Windows имеет, как это не пародоксально звучит, свой набор зарегистрированных оконных классов. Общность стандартных (системных) оконных классов поддерживается автоматической загрузкой в адресное пространство системных библиотек, которые, в момент своей инициализации, регистрируют свои оконные классы. Список DLL (только они позволяют делать общедоступными определенные виды окон), подгружаемых автоматом каждому приложению, хранится где-то в реестре (не помню точно где). Еще одним доводом в пользу предположения об уникальности списка зарегистрированных оконных классов каждого приложения (экземпляра приложения) служит сама процедура RegisterClass(Ex). В качестве аргумента данной процедуры выступает указатель на структуру, одним из элементов которой является указатель (адрес) на оконную процедуру. Нет 100% гарантии того, что разные DLL проекцируются в одно и то же адресное пространство всех приложений без исключений. Следовательно, адрес оконной процедуры перестает нести смысловую нагрузку. Из изложенного выше, позвольте сделать вывод: если в результате регистрации приложением оконного класса произошла ошибка типа "Оконный класс с указанным именем уже существует" это означает лишь то, что именно ЭТО приложение уже зарегистрировало подобный класс. И наоборот, если регистрация прошла успешно, то это не значит, что нет такого приложения (экземпляра приложения) которое не зарегистрировало бы оконный класс с подобным именем. Следовательно подобный подход при решении подобной проблемы невозможен.

Решить указанную проблему можно лишь при помощи объектов ядра операционной системы, объектов файловой системы (так, по моему, решаются подобные задачи в OS типа Linux/Unix) и некоторых других объектов (типа mailslot, TCP ports и наверное можно придумать что либо еще). Важно выполнение следующих условий:

1. Объекты должны быть доступны из различных приложений

2. Объекты должны быть одинаковым образом идентефицированы для всех приложений (идет отказ от дескрипторов объектов, которые актуальны только в рамках одного процесса).

3. Желательно (а может обязательно?), что бы OS поддерживала синхронизацию доступа к данным объектам.

Самый простой способ идентефикации объектов заключается в присвоении им строковых имен. Такой способ применяестся к объектам ядра, файловой системы, mailslot. TCP способ использует разименовку по номеру порта. И имя и номер имеют одно и то же значение для всех приложений. Для функции RegisterClass(Ex), похоже, не выполняется первое условие. Способ определения повторного запуска экземпляра приложения давно известен и использует объект ядра системы типа "mutex". В задаче, кроме того, требуется подать сигнал активизации первому экземпляру приложения. Пришлось модифицировать известный способ, попутно решив эту проблему для себя, и использовать объект ядра типа "event". В общем, принцип работы схемы выглядит так:

1. Попытка получить доступ к объекту ядра по имени

1.1. Доступ получить не удалось из-за отстутствия объекта с указанным именем – данный экземпляр приложения первый. Переходим к п. 2

1.2. Доступ получен – большая вероятность того что данное приложение запущено во второй раз. Почему не 100% уверенность? Делаем скидку на то, что кто то другой мог выбрать для своих нужд именно этот тип объектов и именно с этим именем :). Переходим на п. 3

2. Инициализация и активация главного окна

2.1. Создаем объект ядра с именем, использованным в п. 1

2.2. Инициализируем и запускаем приложение

2.3. Время от времени проверяем поступление сигнала о запуске второй копии приложения

3. Передача сигнала первому приложению о запуске второй копии и выход из программы.

Владимир Голенкевич

Очень подробный и интересный ответ, но к сожалению не совсем корректный. Насчет классов – действительно, они доступны только внутри зарегистрировавшего их процесса (в MSDN есть хорошая статья "Window Classes in Win32" by Kyle Marsh). Однако я не совсем согласен с логическими построениями автора (или понял их неправильно). Т.к. имя класса по идее уникально, то естественно, что ИМЕННО ЭТО приложение зарегистрировало класс. А как иначе?..

Вопросы вызывают еще два момента. Во первых, при создании объектов ядра НИ В КОЕМ СЛУЧАЕ не нужно сначала проверять, существует ли такой объект (п.1). Иначе можно нарваться на т.н. race conditions, описанные в вышеупомянутой статье – ситуация, когда два экземпляра стартуют почти одновременно. Получается, что одна копия проверяет, что объект не существует, и создает его. Но прежде чем она его создаст, вторая копия тоже убеждается в том, что объекта еще нет, и тоже собирается со спокойной совестью его создать. В результате первая копия успевает создать объект, а второй копии создать объект так и не удается, но это уже не важно, т.к. вторая копия все равно запускается.

Не стоит думать, что такая ситуация маловероятна. Представьте себе пользователя, который настроил Windows запускать программы по одному щелчку на ярлыке, но по привычке делает double-click…

Весь смысл объектов ядра как раз в том, что при их создании ГАРАНТИРУЕТСЯ, что никто другой в это же время не сможет создать такой же объект. Нужно сразу пытаться СОЗДАТЬ объект – и если эта операция не удается (возвращается ERROR_ALREADY_EXISTS или ERROR_ACCESS_DENIED) – вот тогда можно с уверенностью говорить о том, что запущена еще одна копия.

Во-вторых, мне не совсем понятны пункты 2.3 и 3. Мне кажется это очень неэфективным – постоянно проверять на наличие сигнала от второй копии (как я понимаю, по этому сигналу приложение должно себя активизировать). Есть способы гораздо лучше (читайте ниже).

Но (заметьте!) мы выяснили очень важную вещь: использование объектов ядра абсолютно необходимо для определения, запущена ли копия приложения или нет.

A2 Можно например с помощью RegisterWindowMessage.

В двух словах:

1. Регистрируем сообщение.

2. Отправляем его на HWND_BROADCAST с каким нибудь кодом в wParam, (например 1) и своим hWnd в lParam (чтобы получатель знал, куда отправлять ответ)

3. Пишем обработчик нашего зарегистрированного сообщения. Он анализирует wParam, если там 1 и lParam не равен собственному hWnd, то он отсылает в ответ такое же сообщение но с кодом 2 например.(отправителя мы получили через lParam)

4. Если мы получили сообщение с кодом 2 в wParam значит уже есть запущенная копия приложения.

Pavlik Yatsuk

Если к ответу добавить механизм объектов ядра, то получается вариант правильный… на первый взгляд. Вот что говорит об этом способе Александр Шаргин:

"Я отказался от этого подхода, и вот почему […] Посылая сообщение с параметром HWND_BROADCAST, мы теряем доступ к возвращаемому в ответ значению. А значит, уже запущенная копия нашего приложения (если таковая есть) должна ответить также посылкой сообщения. Вопрос: кому его посылать? Главное окно во второй копии приложения ещё не создано, цикла сообщений нет… Выход один: создавать невидимое окно, и ловить в нём сообщение — кривовато…

Вариант второй: не использовать HWND_BROADCAST, а сделать EnumWindows и посылать сообщение каждому окну в отдельности. А значит писать свою CALLBACK-функцию, обработчик зарегистрированного сообщения… Тоже кривовато, мне не понравилось."

(Кстати, вариант второй как раз используется в статье;) А вот и сам его ответ:

AДля начала два замечания. Во-первых, CDialog таки наследует функцию PreCreateWindow от своего предка – класса CWnd. Другой вопрос, что эта функция не вызывается в процессе создания диалогового окна. Во-вторых, MFC не регистрирует класс диалогового окна, оставляя имя, предопределённое в Windows. Вместо этого MFC передаёт адрес своей собственной диалоговой функции (AfxDlgProc) при вызове CreateDialogIndirect.

Итак, мы установили, что диалоговое окно создаётся в функции CreateDialogIndirect. Мы не можем повлиять на процесс создания окна, а значит не можем и изменить имя класса. Придётся искать обходные пути. Самый простой из них, на мой взгляд – дать диалогу "во владение" невидимое окно, для которого заголовок и имя класса известны. Затем можно найти это окно с помощью FindWindow, переместиться к самому диалогу через GetWindow и сделать на него SetForegroundWindow.

Вот фрагмент функции InitInstance, который делает всё необходимое (использование статических переменных выглядит несколько коряво – я использовал их, чтобы весь код был в одном месте, но в реальной программе лучше сделать их членами класса).

BOOL CMyApp::InitInstance() {

 …

 HWND hWnd = FindWindow("{4C1D4220-C3E5-11d4-93A8-B5D00D46136A}", NULL);

 if (hWnd != NULL) {

  hWnd = GetWindow(hWnd, GW_OWNER);

  SetForegroundWindow(hWnd);

  return FALSE;

 }

 WNDCLASS wc;

 ZeroMemory(&wc, sizeof(wc));

 wc.hInstance = AfxGetInstanceHandle();

 wc.lpfnWndProc = DefWindowProc;

 wc.lpszClassName = "{4C1D4220-C3E5-11d4-93A8-B5D00D46136A}";

 RegisterClass(&wc);

 static CMyDlg dlg;

 m_pMainWnd = &dlg;

 dlg.Create(IDD_MY_DIALOG, NULL);

 static CWnd wndDummy;

 wndDummy.CreateEx(0, "{4C1D4220-C3E5-11d4-93A8-B5D00D46136A}", "", 0, CRect(0,0,0,0), &dlg, 0);

 …

 return TRUE;

}

Обратите внимание на использование GUIDа в качестве имени класса. Он получен с помощью утилиты Guidgen (меню Tools). Вероятность того, что в системе найдутся окна с таким классом, не имеющие отношения к нашей программе, представляется ничтожно малой.

Александр Шаргин

А вот если к этому ответу добавить механизм mutex'ов, то получится действительно корректный способ.

Хочу обратить ваше внимание на один факт, присутствующий в обоих предыдущих ответах. Функция активизации уже запущенной копии целиком возлагается именно на вторую копию. Многие предлагали посылать первой копии сообщение, чтобы она воостановилась сама. Это в общем случае не работает (т.е. работает не во всех системах), из-за того, что приложение не может активизировать свое главное окно, если само не активно, и при этом не помогают ни BringWindowToTop, ни SetForegroundWindow.

Интересующимся этой темой я настоятельно рекомендую ознакомиться со статьей by Joseph M. Newcomer, где подробно разбираются достоинства и, главное, недостатки, каждого метода. А методов, помимо рассмотренных выше, очень много, напр. file mapping, shared variable и др. (я не стал публиковать эти ответы т.к. все эти объекты используются с одной целью, которая отлично решается с помощью mutex'ов).

Некоторые ссылались на статью в MSDN Q109175 – так вот: там используется некорректное решение!

Если вдруг кто-нибудь, кто прислал мне ответ, все еще считает его 100% правильным, прошу написать мне об этом – я никого обидеть не хотел, а в таком большом количестве ответов было легко что-то упустить. И еще: у кого есть какие соображения по этому поводу, замечания – пишите! Дискуссия получается на редкость интересная.

В ПОИСКАХ ИСТИНЫ

Q Есть диалог на нем Date Time Picker и есть соответствующая ему переменная m_Time типа CTime. Проблема в том, что если m_Time = 0, то в диалоге высвечивается 2:00:00!!?? Т.е. сдвиг на два часа. Причем если выставить 0:00:00, то будет "Assertion fault". Ну и соответственно, если установить 2:00:00, то после UpdateData() m_Time станет = 0. Скорее всего это как-то связано с часовым поясом (у меня часовой пояс +02:00). Как от этого избавиться?

Михаил

Это все на сегодня. Удачи вам!

Алекс Jenter jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №27 от 10 декабря 2000 г.

Здравствуйте, уважаемые подписчики!

Я получал достаточно много писем с просьбами рассказать о чем-то конкретном , и в этих просьбах довольно часто встречалась тема доступа к данным из программ с использованием различных технологий – ODBC, DAO, OLE DB. Конечно, тема эта очень обширна и многогранна. Но, тем не менее, программистам с ней приходится сталкиваться довольно часто, и поэтому рассмотрение ее в рассылке кажется оправданным. Я решил, что разумнее всего будет сделать серию статей на эту тему, отдельные заметки из этой серии будут по мере написания появляться в рассылке (но, заметьте, что далеко не в каждом выпуске).

Сейчас я работаю над продолжением статьи про многозадачность. Тема синхронизации потоков думаю будет особенно интересна в свете того обсуждения, которое вызвал вопрос из выпуска №25 (про активизацию уже запущенного экземпляра приложения в случае попытки запуска нового). В дальнейшем нас также ждет очень интересная тема о работе с e-mail.

Когда Александр Шаргин попросил меня перечислить вопросы, интересующие читателей рассылки, то я назвал ему и вопрос доступа к данным. К сегодняшнему дню он закончил работу над первой частью статьи про ODBC: технологии, с которой воистину все начиналось. Думаю, с нее стоит начать и нам.

СТАТЬЯ
Доступ к БД с использованием ODBC
Часть 1

Открытый интерфейс доступа к базам данных (Open Database Connectivity, ODBC) – это программный интерфейс, который позволяет приложению обращаться к различным СУБД, используя структурированный язык запросов SQL. Применяя ODBC, разработчики могут писать программы, независимые от архитектуры конкретной СУБД. Такие программы будут работать с любой реляционной базой данных (как существующей в данный момент, так и той, которая, возможно, появится в будущем), для которой написан ODBC-драйвер.

НЕМНОГО ТЕОРИИ

Структура ODBC

Архитектура ODBC имеет четыре основных компонента: пользовательское приложение, менеджер драйверов ODBC, драйвер, источник данных. Менеджер драйверов написан в виде DLL, которая загружается пользовательским приложением и перенаправляет вызовы функций ODBC API нужному драйверу. Драйвер, в свою очередь, выполняет основную работу по выполнению запросов.

Типичная схема взаимодействия приложения с базой данных состоит из трёх шагов:

• установка соединения с БД

• выполнение запросов на выборку и/или изменение данных в БД

• разрыв соединения

ODBC API и классы MFC

MFC предоставляет набор классов, облегчающих работу с ODBC API. Два из них мы рассмотрим подробно – это CDatabase и CRecordset. Хотя эти два класса позволяют выполнять все основные операции по выборке и модификации данных, иногда их возможностей оказывается недостаточно. В этом случае приходится вызывать функции ODBC API напрямую (все эти функции имеют префикс SQL).

Источники данных

Источник данных (data source) – это по сути логическое имя базы данных, которое используется для обращения к ней средствами ODBC. Эта абстракция оказывается достаточно удобной: если база данных, используемая программой, будет скопирована в другой каталог или перенесена на другой компьютер, нужно просто скорректировать атрибуты источника данных, не внося никаких изменений в саму программу. Однако, ODBC позволяет работать с базой данных и напрямую, то есть без использования источников данных.

БАЗОВЫЕ ВОЗМОЖНОСТИ ODBC

Обработка ошибок

Прежде чем мы приступим к работе с ODBC, нужно научиться обрабатывать ошибки, которые могут возникнуть в процессе выполнения программы. Очень часто ответ на вопрос "почему программа не работает?" находится под рукой; нужно только знать, куда посмотреть.

При использовании ODBC API программист должен был анализировать возвращаемые значения функций, обращаясь за более подробной информацией об ошибке к функции SQLError. MFC скрывает от нас детали этого процесса. В случае возникновения ошибки она возбуждает исключение, которое и должна перехватить наша программа. Обработчик исключения получает указатель на структуру CDBException, которая содержит всю необходимую информацию. Так, поле m_strError содержит описание ошибки в понятной для человека форме, а в m_strStateNativeOrigin записывается пятибуквенный код состояния ODBC, который удобно анализировать в программе, а также некоторая дополнительная информация.

Типичный пример кода обработки исключений выглядит так:

try {

 // Работаем с БД

} catch(CDBException *pException) {

 AfxMessageBox(pException->m_strError);

 pException->Delete(); // Удаляем структуру из памяти!

}

Замечу, что обработку исключений следует использовать только для восстановления программы после ошибки. Если всё, что нам требуется – это просмотреть значения полей структуры CDBException, можно сделать это и без перехвата исключений. В режиме отладки Visual C++ сам выводит содержимое структуры CDBException на вкладку Debug в окно Output; так что если ваша программа "рухнула", следует первым делом посмотреть на эту вкладку.

Соединение с базой данных

Сначала поговорим о том, как в системе регистрируются источники данных. Это можно сделать программно или с помощью специальной утилиты – администратора источников данных ODBC. Эта утилита входит в состав Windows и вызывается через панель управления (пункт "Источники данных ODBC (32)"). Программную регистрацию мы рассмотрим во второй части, а пока можно воспользоваться услугами администратора.

Соединение с базой данных в MFC представляется объектом класса CDatabase. Чтобы установить соединение, необходимо воспользоваться функцией CDatabase::OpenEx (функция Open устарела; к тому же пользоваться ею менее удобно). Например:

CDatabase db;

db.OpenEx("DSN=db;UID=sa;PWD=", 0);

Первый параметр функции OpenEx – это строка подключения, в которой пары "параметр=значение" разделяются точкой с запятой. Имена параметров нечувствительны к регистру. В стандартный набор параметров строки соединения входят: DSN (data source name – имя источника данных), UID (имя пользователя), PWD (пароль) и DRIVER (драйвер ODBC). Большинство драйверов распознаёт ряд дополнительных параметров.

Обратите внимание, что строка соединения не должна начинаться с префикса "ODBC;" (этот префикс нужно было добавлять при использовании функции CDatabase::Open).

Второй параметр функции OpenEx – набор битовых флагов, объединённых логическим "ИЛИ". Вот некоторые из них:

• CDatabase::openReadOnly – открыть БД в режиме "только для чтения".

• CDatabase::noOdbcDialog – никогда не выводить диалог, запрашивающий дополнительную информацию о соединении.

• CDatabase::forceOdbcDialog – всегда выводить диалог, запрашивающий информацию о соединении. Этот режим уместен, если во время написания программы не известно, с какой именно базой данных она будет работать.

По умолчанию (если второй параметр OpenEx не задан или равен 0) база данных открывается в режиме "чтение и запись", а диалог появляется только в случае, когда в строке соединения отсутствуют необходимые параметры (например, имя источника данных).

Выборка данных из таблицы

Работая с ODBC, программа получает данные, извлекаемые из БД, в виде множества записей (recordset). Каждая запись содержит набор полей. В любой заданный момент времени программа может работать только с одной записью (она называется текущей). Используя функции ODBC, можно перемещаться от одной записи к другой. Для удобства каждое поле в результирующем множестве обычно связывается с переменной, которую программа использует для чтения и модификации значения соответствующего поля. Тем не менее, связывать поля с переменными в общем случае необязательно.

В MFC для работы с множеством записей предназначен класс CRecordset. Как правило, этот класс не используется в программе напрямую. Вместо этого от него порождают новые классы, переменные-члены которых и связываются с полями множества записей. Само связывание происходит в виртуальной функции CRecordset::DoFieldExchange, которая переопределяется в производном классе; эта же функция осуществляет обмен данных между полями записи и переменными класса. Множество записей создаётся функцией CRecordset::Open, а перемещение от одной записи к другой осуществляется посредством функций Move, MoveNext, MovePrev и т. п.

Пример

Рассмотрим небольшой пример. Допустим, в базе данных содержится таблица tPeople с полями Name (типа строка из 50 символов) и DateOfBirth (типа дата/время), и мы хотим напечатать на экране её содержимое. Сперва создаём новый класс, порождённый от CRecordset:

class CPeople : public CRecordset {

public:

 CPeople(CDatabase *pDatabase = NULL) : CRecordset(pDatabase) {

  m_nFields = 2;

 };


 CString m_Name;

 CTime m_DateOfBirth;

 void DoFieldExchange(CFieldExchange *pFX);

};

Для каждого поля в таблице tPeople мы объявили переменную соответствующего типа. Так, поле Name хранится как строка, поэтому m_Name имеет тип CString. DateOfBirth - это дата, поэтому m_DateOfBirth - переменная типа CTime. Обратите внимание, что в переменную m_nFields (CPeople наследует её от CRecordset) необходимо записать количество полей таблицы (это значение необходимо MFC, чтобы правильно построить запрос). Теперь реализуем функцию DoFieldExchange, в которой происходит связывание полей таблицы с переменными нашего класса CPeople.

void CPeople::DoFieldExchange(CFieldExchange *pFX) {

 pFX->SetFieldType(CFieldExchange::outputColumn);

 RFX_Text(pFX, "Name", m_Name, 50);

 RFX_Date(pFX, "DateOfBirth", m_DateOfBirth);

}

Вызов SetFieldType с параметром CFieldExchange::outputColumn должен всегда предшествовать операциям связывания. Сам механизм связывания напоминает механизм обмена данными с элементами управления диалога. Тут и там используется набор специальных макросов, которые в зависимости от контекста (который определяется объектом класса CFieldExchange) выполняют различные действия – в нашем случае формируют элементы запроса, связывают переменные с полями множества записей и осуществляют обмен данными между ними.

Каждый из макросов, используемых в DoFieldExchange, имеет префикс "RFX_". Существует несколько версий этих макросов – по одному на каждый основной тип. Наборы параметров у них несколько отличаются, но первые три параметра совпадают у всех макросов: указатель на объект класса CFieldExchange (нужно просто передать указатель, полученный от MFC), имя поля во множестве записей и ссылка на переменную, которая будет с этим полем связана.

Итак, создание класса CPeople закончено, и можно использовать его для доступа к таблице tPeople. Вот фрагмент, который печатает на экране её содержимое.

:

CDatabase Db;

Db.OpenEx("DSN=db;UID=sa;PWD=");

CPeople Rs(&Db);

Rs.Open(CRecordset::dynaset, "tPeople");

while(!Rs.IsEOF()) {

 printf("%s\t%s\n", Rs.m_Name, Rs.m_DateOfBirth.Format("%d of %B %Y"));

 Rs.MoveNext();

}

:

Здесь нужно обратить внимание на несколько моментов. Во-первых, как мы помним, прежде чем работать с базой данных, необходимо установить соединение с ней. Это делается с использованием уже знакомой нам функцией CDatabase::OpenEx. Во-вторых, указатель на соединение нужно передать конструктору класса CPeople, чтобы данные извлекались именно из нужной нам базы данных.

Теперь рассмотрим параметры функции CRecordset::Open. Первый параметр задаёт тип результирующего множества записей. Можно задавать следующие типы:

• CRecordset::forwardOnly – множество записей, доступное только для чтения и по которому можно перемещаться только вперёд.

• CRecordset::snapshot – множество записей, по которому можно перемещаться в любом направлении. Изменения, внесённые в БД после создания такого множества, в нём не отражаются.

• CRecordset::dynaset – похоже на предыдущее, но любые изменения записи в БД будут видны после повторной выборки этой записи. Новые записи, добавленные в БД после создания такого множества, в нём не отражаются.

• CRecordset::dynamic – самое ресурсоёмкое множество. Любые изменения, внесённые в БД после его открытия, будут в нём отражены. Не поддерживается многими драйверами.

Если драйвер не поддерживает запрошенный тип множества записей, MFC возбудит исключение.

Второй параметр функции CRecordset::Open используется для передачи имени таблицы или запроса, на основе которого будет построено множество записей. MFC сама определит, что именно ей передали. У функции CRecordset::Open есть также третий параметр – который во многих случаях можно не указывать. За его описанием можно обратиться к документации.

После того как множество записей создано, пользоваться им достаточно просто. Для обращения к полям текущий записи мы используем переменные-члены класса CPeople, а к следующей записи перемещаемся при помощи функции CRecordset::MoveNext. Когда все записи исчерпаны, функция CRecordset::IsEOF возвращает TRUE, и цикл прерывается.

Модификация данных в таблице

С помощью методов класса CRecordset можно изменять записи в таблице и добавлять новые записи. Прежде чем изменять запись, следует убедиться, что открытое множество записей допускает такую операцию, с помощью функции CRecordset::CanUpdate. Сама модификация начинается вызовом функции CRecordset::Edit и завершается вызовом функции CRecordset::Update; между этими двумя вызовами следует изменить значения переменных, связанных с полями множества записей. Например:

if (Rs.CanUpdate()) {

 Rs.Edit();

 Rs.Rs.m_Name = "Vasya Pupkin";

 Rs.m_DateOfBirth = CTime(2000, 1, 1, 0, 0, 0);

 Rs.Update();

}

Аналогичным образом можно добавлять новые записи, но вместо Edit используется AddNew. Убедиться в том, что множество записей поддерживает добавление, можно с помощью функции CRecordset::CanAppend. Например:

if (Rs.CanAppend()) {

 Rs.AddNew();

 Rs.Rs.m_Name = "Vasya Pupkin";

 Rs.m_DateOfBirth = CTime(2000, 1, 1, 0, 0, 0);

 Rs.Update();

}

И последнее замечание. Чтобы обновить множество записей после внесения изменений в БД, нужно вызвать функцию CRecordset::Requery.

Разрыв соединения

Это самый простой, но совершенно необходимый этап. Закончив работу с источником данных, программа должна разорвать с ним соединение вызовом CDatabase::Close. Перед этим необходимо также закрыть все наборы записей, используя функцию CRecordset::Close. Ни одна из этих функций не принимает никаких параметров.


Если у вас есть какие-либо вопросы, предложения или пожелания, присылайте их мне по адресу rudankort@mail.ru. Я постараюсь учесть их при написании второй части статьи, которая будет посвящена более сложным аспектам работы с ODBC.

Александр Шаргин
ВОПРОС-ОТВЕТ

Q Есть диалог на нем Date Time Picker и есть соответствующая ему переменная m_Time типа CTime. Проблема в том, что если m_Time = 0, то в диалоге высвечивается 2:00:00!!?? Т.е. сдвиг на два часа. Причем если выставить 0:00:00, то будет "Assertion fault". Ну и соответственно, если установить 2:00:00, то после UpdateData() m_Time станет = 0. Скорее всего это как-то связано с часовым поясом (у меня часовой пояс +02:00). Как от этого избавиться?

Михаил

A1 Как известно, класс CTime – это всего лишь объектная обёртка вокруг типа _t из стандартной библиотеки языка C. А тип time_t (4 байта) хранит время как число секунд, прошедших с момента полуночи 1 января 1970 года. Это означает, что класс CTime не может хранить время ДО этого момента. А если записать в него 0, мы как раз и получим 1.01.1970, 0:00:00 (или 2:00:00 с учётом часового пояса).

Когда Date Time Picker работает в режиме ввода времени, он всё равно "помнит" полную дату. Если ввести в него "0:00:00", то с учётом часового пояса получится 31.12.1969, 22:00:00, то есть дата за пределами диапазона допустимых значений CTime. Это и приводит к срабатыванию ASSERT'а.

А для решения проблемы достаточно записать в CTime какую-нибудь дату, отличную от 1.01.1970. Например:

m_Time = CTime(2000, 1, 1, 0, 0, 0); // 1 января 2000 года

Александр Шаргин

A2 Суть "проблемы" в том, что элемент управления CDateTimeCtrl инкапсулирует одновременно и дату, и время , а не то или другое по отдельности. Как известно, тип данных time_t и класс CTime используют так называемый "UTC-based time" формат и хранят число секунд с ноля часов 1 января 1970 года (с учетом часового пояса). Поэтому при работе с CDateTimeCtrl это следует учитывать и использовать его именно в этом контексте (в "увязке" с датой). То есть, если мы инициируем переменную нулевым значением, то мы и имеем "точку отсчета".

Другой интересный вопрос состоит в том, как эффективно организовать корректировку даты и времени одновременно. К примеру: мы имеем переменную  m_Time типа CTime с некоторым значением и хотим дать пользователю возможность изменить и время и дату, используя соответственно два элемента CDateTimeCtrl, чтобы в конечном итоге получить скорректированное значение m_Time. Вариант с созданием двух ассоциированных переменных CTime и последующим отбрасыванием у одной даты, у другой времени, и их сложением не очень красивый. Я решил это таким образом: создал ассоциированные переменные типа CDateTimeCtrl (а не CTime), использовал функцию SetTime(&m_Time) для установки даты и времени в обоих переменных, а потом при изменении любой из них считывал измененное значение функцией GetTime(&m_Time) и тут же корректировал значение "сопряженной" переменной функцией SetTime(&m_Time). Таким образом достаточно просто решилась проблема "синхронизации" изменения даты и времени.

Евгений Шмелев
ОБРАТНАЯ СВЯЗЬ

Хотел бы дополнить Ваши материалы по .NET:

В частности, хотел бы указать на ошибки в №20 от 22 октября 2000 г.

Платформа Microsoft.NET не базируется на сервисах COM+, а предлагает совершенно новое, более удобное множество сервисов. Так, вместо DCOM и COM+ Вам предоставляется Microsoft .NET Remoting (http://msdn.microsoft.com/library/default.asp?URL=/library/techart/hawkremoting.htm). Вместо каталога COM+ используется каталог .NET.

Естественно, компоненты .NET совместимы с компонентами COM+, в частности, и те, и другие прозрачно доступны друг другу через соответствующий уровень трансляции (flattened COM).

Компиляция исходного кода возможна не только в IL, но и напрямую в машкод.

Первое преимущество .NET – настоящая объектность, включая наследование. Второе примущество – настоящая компонентная архитектура. Если кто-нибудь знаком с RAD-инструментарием Borland Delphi, то могу лишь сказать, что концепции .NET в области компонентной архитектуры, хранимых компонент и свойств, редакторов компонент и редакторов свойств являются органичным развитием идей, заложенных в Delphi VCL.

Собственно, приглашаю на http://msdn.microsoft.com/net/default.asp

Акжан Абдулин

[…] пару слов по поводу темы предыдущей рассылки. Я использую для решения этой проблемы опубликованный на нескольких сайтах класс CInstanceChecker (http://www.naughter.com/sinstance.html, автор P.J. Naughter), который, по-моему, вполне успешно решает все описанные проблемы. В частности, там элегантно решен вопрос блокирования с помощью объекта класса CSingleLock повторно-запущенных копий вплоть до того момента, когда первая копия создаст главное окно для возможности его активизации.

И последнее. Порой не хочется заглядывать в русифицированные группы новостей из-за обилия "крутого профессионального жаргона" и некоторой агрессивности участников. Грустно за родной язык. Эдакое подражание новорусскому стилю: "пальцы веером" :). Кстати, англоязычные группы гораздо более традиционные и терпимые, хотя вопросы там бывают дилетантские, а профессиональный уровень отвечающих при этом очень высокий. В этом смысле эта рассылка приятно выделяется, и особо хочется отметить регулярные статьи Александра Шаргина.

Евгений Шмелев

[…] хотелось бы также выразить благодарность Александру Шаргину, автору статьи на тему "отладчик" – несмотря на мной многолетний опыт узрел там несколько "приятных мелочей", проверить которые самому руки не доходили.

B свою очередь могу внести небольшое дополнение: если в окне отладчика Watch на одной из закладок поместить выражение

<variable>=<value#1>

где variable – имя переменной, а value#1 – одно из возможных ее значений, то поместив на второй закладке Watch такую же строку с иным значением переменной, мы получаем очень удобный вариант быстрой установки/переключения значений интересующей нас переменной. чаще всего таковыми выступают логические переменные (хотя это и не обчзательно). если же у нас целый набор переменных, значения которых в процессе отладки нужно периодически менять, данный способ будет просто незаменим.

Alexander Zasypkin

Благодарю всех, кто не поленился написать.

В ПОИСКАХ ИСТИНЫ

Q. 1. Есть окно нестандартной формы (например, круглое). Но рамка, появляющаяся вокруг него при перемещении, – строго прямоугольной формы. Как избавиться от такой рамки вообще? Или, может быть, ее можно сделать тоже произвольной формы (по контуру окна)?

2. Как избавиться от пунктирной рамки на кнопке, имеющей фокус? Для кнопки, сделанной из красивого рисунка, такая рамка выглядит лишней…

Максим Чучуйко

Это все на сегодня. Всего вам доброго!

Алекс Jenter jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №28 от 17 декабря 2000 г.

Всем привет!

Сегодня вас ждет сюрприз. Сегодня в рассылке впервые появится статья по COM. Мне приходило очень много просьб по этому поводу, часто выражалось недовольство тем, что слишком много внимания уделяется MFC. Типичный пример – в рубрике "Обратная связь". Так что по зрелом размышлении я решил начать понемногу освещать в рассылке и тему COM. В связи с этим, тем кто никогда раньше с COM не сталкивался (а думаю среди подписчиков такие есть), предлагаю вам прочитать статью, знакомящую вас с этой технологией.

СТАТЬЯ Введение в COM Часть 1

Автор: michael dunn

Перевод: Илья Простакишин

Источник: The Code Project

Предмет данной статьи

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

Введение

COM (Component Object Model – Объектно-Компонентная Модель) – одно из трехбуквенных сокращений, которые сегодня очень часто используются в Windows (вспомните – API, MFC, OLE, ATL). Множество новых технологий, разрабатывающихся постоянно, базируется на COM. Документация просто пестрит терминами типа COM object (объект COM), interface (интерфейс), server (сервер), и так далее, но везде почему-то предполагается, что вы уже знакомы с тем, как COM работает и как ее использовать.

Эта статья является вводной для начинающих, она описывает основные используемые механизмы, а также показывает как использовать объекты COM, поставляемые со стороны (особенно, оболочкой Windows). После знакомства со статьей вы сможете использовать COM-объекты, как встроенные в Windows, так и предоставляемые третьими лицами.

Я предполагаю, что вы уже являетесь специалистом в C++. Я частично использую в своих примерах MFC и ATL, и в этих случаях смысл кода будет поясняться, на случай, если вы не знакомы с этими библиотеками. […]

Что такое COM?

COM – это метод разделения двоичного кода между разными приложениями, написанными на разных языках программирования. Это не совсем то, что обеспечивает C++, а именно повторное использование исходного кода. ATL – хороший пример такого подхода. Отлаженный исходный код может повторно использоваться и нормально работать только в C++. При этом существует возможность коллизий между именами, не говоря уже о неприятностях при наличии множества копий одинакового кода в ваших проектах.

Windows позволяет разделять код между приложениями с помощью библиотек DLL. Я не раскрою большого секрета, если скажу, что все функции Windows содержатся в различных внешних библиотеках – kernel32.dll, user32.dll и т.д., которые доступны любому Windows – приложению, и более того, должны им использоваться. Но DLL расчитаны на использование только посредством интерфейса С или языков, понимающих стандарты вызова языка C. Таким образом, реализация языка программирования является барьером между создаваемым приложением и уже реализованными процедурами, содержащимися внутри DLL-библиотеки.

В MFC был введен новый механизм разделения двоичного кода – библиотеки расширения MFC (MFC extension DLLs). Но это еще более ограниченный метод, т.к. вы можете использовать его только в приложениях, созданных на основе библиотеки MFC.

COM решает все эти проблемы. Делается это посредством введения двоичного стандарта. При этом спецификация COM требует, чтобы двоичные модули (DLL и EXE) компилировались в соответствие со специфической структурой, которая декларируется этим стандартом. Стандарт также в точности определяет, каким образом COM-объекты должны быть организованы в памяти. Вдобавок, двоичная структура не должна быть зависима от особенностей языка программирования (как, например, стандарта описаний имен в C++). Все это нужно для того, чтобы облегчить доступ к модулю приложения, созданного на любом языке программирования. Двоичный стандарт возлагает "бремя" совместимости на "плечи" компилятора, облегчая задачу вам, как создателю компонентов, и другим людям, которые будут пользоваться вашими компонентами.

Структура расположения COM-объектов в памяти очень похожа на модель, которая используется в C++ виртуальными функциями, поэтому многие компоненты COM создаются с использованием языка C++. Однако, здесь важно заметить, что язык, на котором вы пишите, не имеет значения, поскольку результат можно использовать в будущем с любыми языками программирования.

Строго говоря, COM не является спецификацией, привязанной к Win32. Теоретически, можно портировать ваши COM-объекты в Unix или любые другие ОС. Однако, я никогда не видел, чтобы COM применялась где-то за пределами сферы влияния Microsoft.

Основные определения

Начнем двигаться снизу-вверх. Итак, интерфейс (interface) – это простая группа функций. Эти функции, в свою очередь, называются методами (methods). Имена интерфейсов начинаются с буквы I, например IShellLink. В терминологии C++ интерфейс представляет собой абстрактный базовый класс, содержащий только чистые виртуальные функции (pure virtual functions).

Интерфейсы могут наследоваться (inherit) от других интерфейсов. Наследование работает также, как и одиночное наследование в C++. Множественное наследование для интерфейсов не применяется.

CO-класс (coclass) (сокращение от component object class) содержится в dll или exe и включает код одного или нескольких интерфейсов. Говорят, что CO-класс поддерживает или реализует (implement) эти интерфейсы. Объект COM (COM object) – это экземпляр CO-класса в памяти. Заметьте, что "класс" COM – это не тоже самое, что "класс" C++, хотя часто бывает, что класс COM реализуется посредством класса C++.

Сервер COM (COM server) – это двоичный файл (DLL или EXE), содержащий один или несколько CO-классов.

Регистрация (registration) – это процесс создания записей в реестре, которые сообщают Windows о том, где можно найти определенный сервер COM. Дерегистрация (unregistration) наоборот – удаление этих данных из реестра.

GUID (рифмуется с "fluid" – "жидкий, текучий", сокращение от globally unique identifier – Глобальный Уникальный Идентификатор) – это 128-битный номер, который используется COM для идентификации различных элементов. Каждый интерфейс и CO-класс имеет GUID. Коллизии между именами невозможны, поскольку каждый GUID абсолютно уникален и повторение GUID очень маловероятно (если вы используете для их создания функции COM API). Вы также можете иногда встретить термин UUID (сокращение от universally unique identifier). uuid и guid это практически одно и тоже.

ID класса (class ID) или CLSID – это GUID, которым обозначается CO-класс. В свою очередь, ID интерфейса (interface ID) , или IID – это GUID, обозначающий интерфейс.

Существует две причины, по которым идентификаторы GUID так широко используются в COM:

1. GUID это всего лишь число. Любой язык программирования может оперировать им. 

2. Каждый GUID, создаваемый на любой машине, уникален (если создан правильно). Следовательно, два COM-разработчика не могут использовать одни и те же GUID. Это решает проблему по выделению уникальных GUID и устраняет необходимость в специальном центре по выделению GUID (как, например, при регистрации доменов в Internet).

HRESULT – это целочисленный тип, который используется COM для возврата кодов ошибок или кодов завершения. Не смотря на то, что имя типа начинается с префикса H, он (этот тип) не является дескриптором. Переменная типа HRESULT способна участвовать в любых логических операциях языка C, например != и ==.

Наконец, Библиотека COM (COM library) – это часть операционной системы, с которой вы взаимодействуете, когда делаете что-либо с элементами COM. Часто библиотека COM называется просто "COM" и иногда это приводит к некоторой путанице.

Работа с объектами COM

Каждый язык реализует операции с объектами по-разному. Например, в C++ вы создаете объекты на стеке, либо с помощью new динамически выделяете для них место в "куче". Поскольку COM должна быть нейтральна к языку, библиотека COM включает свои собственные средства управления объектами. Сравним управление объектами в COM и C++:

Создание нового объекта

• В C++ используется оператор new, либо объект создается на стеке. 

• В COM вызывается специальная API-функция библиотеки COM.

Удаление объектов

• В C++ используется оператор delete, либо объект удаляется автоматически при выходе из области видимости. 

• В COM каждый объект хранит свой собственный счетчик обращений. Когда вы заканчиваете работу с объектом, вы должны сообщить ему, что он вам больше не нужен. Когда счетчик обращений равен 0, объект сам выгружается из памяти.

Теперь, между этими двумя стадиями – создания и удаления объекта – вы, естественно, должны использовать этот объект. Когда вы создаете COM-объект, вы сообщаете библиотеке COM, какой интерфейс вам нужен. Если объект был успешно создан, библиотека COM возвращает указатель на запрашиваемый интерфейс. С его помощью вы можете вызывать методы этого интерфейса, также как при использовании обычного объекта C++.

Создание объекта COM

Для создания COM-объекта и получения интерфейса из этого объекта (напомню, что COM-объект может содержать несколько интерфейсов) вы должны вызвать библиотечную функцию CoCreateInstance(). Прототип CoCreateInstance():

 HRESULT CoCreateInstance(REFCLSID rclsid, LPUNKNOWN pUnkOuter, DWORD dwClsContext, REFIID riid, LPVOID* ppv);

Описание параметров:

rclsid CLSID CO-класса. Например, вы можете передать CLSID_ShellLink при создании COM-объекта, который используется для создания ярлыков.
pUnkOuter Этот параметр используется только при агрегации COM-объектов, когда берется существующий CO-класс и в него добавляются новые методы. Для наших целей мы должны передать NULL для указания на то, что агрегация использоваться не будет.
dwClsContext Указывает на тип COM-сервера. В этой статье будет использоваться простейший тип сервера – in-process DLL, поэтому в качестве параметра будет передаваться константа CLSCTX_INPROC_SERVER. Предостережение: не используйте CLSCTX_ALL (она установлена в ATL по умолчанию), т.к. это может привести к ошибке в системах Windows 95, где не инсталлирован DCOM.
riid Это IID интерфейса, который вы хотите получить. Например, вы должны передать IID_IShellLink для получения указателя на интерфейс IShellLink.
ppv Адрес указателя на интерфейс. Библиотека COM возвращает указатель на запрашиваемый интерфейс через этот параметр.

Когда вы вызываете CoCreateInstance(), она находит CLSID в реестре, считывает данные о расположении сервера, загружает сервер в память и создает экземпляр CO-класса, который вы запрашивали.

Вот пример, в котором создается объект CLSID_ShellLink и запрашивается указатель на интерфейс IShellLink, которым владеет этот COM-объект.

HRESULT hr;

IShellLink* pISL;

hr = CoCreateInstance (CLSID_ShellLink,  // CLSID CO-класса

      NULL, // агрегация не используется

      CLSCTX_INPROC_SERVER, // тип сервера

      IID_IShellLink, // IID интерфейса

      (void**)&pISL); // Указатель на наш интерфейсный указатель

if (SUCCEEDED(hr)) {

 // Здесь можно вызывать методы, используя pISL.

} else {

 // Невозможно создать объект COM. hr присвоен код ошибки.

}

В начале мы объявляем переменную типа HRESULT для хранения значения, возвращаемого CoCreateInstance() и указатель на IShellLink. Затем мы вызываем CoCreateInstance() для создания нового COM-объекта. Макрос SUCCEEDED возвращает TRUE, если hr хранит код успешного завершения, или FALSE, если hr содержит код ошибки. Есть также похожий макрос – FAILED, который проверяет значение на предмет соответствия коду ошибки (т.е. делает все наоборот).

Удаление COM-объекта

Как уже было сказано ранее, вам не надо освобождать COM-объекты – достаточно сообщить им, что они больше не нужны. Интерфейс IUnknown, являющийся прародителем всех COM-объектов, содержит метод Release(). Вы должны вызвать этот метод для того, чтобы сообщить COM-объекту, что вы в нем более не нуждаетесь. Однажды вызвав Release(), вы больше нигде не сможете использовать указатель на интерфейс, т.к. COM-объект может исчезнуть из памяти в любое время.

Продолжим предыдущий пример, добавив команду удаления объекта:

// Создаем COM-объект как раньше и…

if (SUCCEEDED(hr)) {

 // Вызов методов интерфейса через pISL.

 // Сообщим COM-объекту о том, что он нам больше не нужен.

 pISL->Release();

}

Интерфейс IUnknown будет детально рассмотрен в следующем разделе.

[Продолжение следует]

ВОПРОС-ОТВЕТ 

Q 1. Есть окно нестандартной формы (например, круглое). Но рамка, появляющаяся вокруг него при перемещении, – строго прямоугольной формы. Как избавиться от такой рамки вообще? Или, может быть, ее можно сделать тоже произвольной формы (по контуру окна)?

2. Как избавиться от пунктирной рамки на кнопке, имеющей фокус? Для кнопки, сделанной из красивого рисунка, такая рамка выглядит лишней…

Максим Чучуйко 

A 1. Избавиться от рамки можно так. Как известно, в Windows существует настройка, определяющая двигаются ли окна целиком или двигается только рамка, а окно переносится на новое место после отпускания кнопки мыши. Менять эту настройку можно либо через панель управления, либо программно – с помощью функции SystemParametersInfo. Таким образом, нужно включить режим перетаскивания окна целиком, когда наше окно начинают перемещать, и вернуть его в первоначальное положение после того, как перемещение закончено.

О том, что перемещение начинается, окно узнаёт по сообщению WM_SYSCOMMAND (с параметром SC_MOVE). Когда перемещение завершается, окно получает ещё одно сообщение – WM_EXITSIZEMOVE. Обработчики могут выглядеть так: 

void CMainFrame::OnSysCommand(UINT nID, LPARAM lParam) {

 if ((nID & 0xFFF0) == SC_MOVE) {

  SystemParametersInfo(SPI_GETDRAGFULLWINDOWS, 0, &m_bDrag, 0);

  SystemParametersInfo(SPI_SETDRAGFULLWINDOWS, TRUE, 0, 0);

 }

 CFrameWnd::OnSysCommand(nID, lParam);

}


LRESULT CMainFrame::OnExitSizeMove(WPARAM wParam, LPARAM lParam) {

 if(m_bDrag != -1) {

  SystemParametersInfo(SPI_SETDRAGFULLWINDOWS, m_bDrag, 0, 0);

  m_bDrag = -1;

 }

 return Default();

} 

Переменную m_bDrag типа int следует добавить с класс главного окна и инициализировать значением -1 в конструкторе.

Обратите внимание, что ClassWizard не умеет вставлять обработчик WM_EXITSIZEMOVE — придётся сделать это вручную, используя макрос ON_MESSAGE.

2. Сперва порекомендую метод, который широко применяют парни из Microsoft – использовать вместо кнопки Tool bar с одной-единственной кнопкой. Нужно только установить такому тулбару стили CCS_NOPARENTALIGN и CCS_NORESIZE, чтобы он не прижимался к верхней кромке окна, а оставался там, где мы его разместили. Этот же способ, кстати, можно использовать, если в приложении требуется "нормальная" плоская кнопка. 

Ну а если такой способ не подходит, остаётся прибегнуть к custom draw. Это не должно быть проблемой, так как изображение для кнопки уже нарисовано – осталось добавить к нему выпуклую/вдавленную кромку.

Александр Шаргин
ОБРАТНАЯ СВЯЗЬ 

Я уже давно получаю вашу подписку. Она мне очень нравится. Но у меня всё время возникает вопрос когда я читаю очередной номер подписки. Почему почти все выпуски так или иначе посвещены MFC? Даже если тема к примеру ODBC, то примеры всё равно на MFC? Я не имею ничего против MFC, но сам последний раз писал на ней уже очень давно потому-что MFC больше всё-же desktop-UI-ориентированная. То чем я занимаюсь и надеюсь не только я. Написанием COM, COM+ компонентов с UI обычно на ASP. Компоненты я пишу на ATL с STL, с доступом к базам данных через OLE DB/ADO. По ATL/STL/COM/COM+/OLE DB/ADO довольно мало материала в подписке. Почему? Неужели подавляющее большинство подписчиков пишет только на MFC?

Vladislav Loidap 
В ПОИСКАХ ИСТИНЫ

Q. Как в Win9x и WinNT заблокировать клавиши WIN, Alt+Tab, Ctrl+Esc etc.?

Mike Krasnik 

А на сегодня это все… До скорого! 

Алекс Jenter jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №29 от 24 декабря 2000 г.

Здравствуйте, уважаемые подписчики!

Рад снова приветствовать вас на страницах рассылки. В этом выпуске вас ожидает вторая часть статьи "Введение в COM" и, конечно же, ответы на вопрос из предыдущего выпуска и кое-что еще.

СТАТЬЯ Введение в COM Часть 2

Автор: michael dunn

Перевод: Илья Простакишин

Источник: The Code Project

Базовый интерфейс – IUnknown

Каждый COM-интерфейс наследуется от интерфейса IUnknown. Имя выбрано не совсем удачно, поскольку этот интерфейс не является "неизвестным" (unknown). Это имя всего лишь означает, что если вы имеете указатель на интерфейс COM-объекта IUnknown, то вы не можете знать, какой объект им владеет (реализует), поскольку интерфейс IUnknown есть в каждом COM-объекте.

IUnknown включает три метода:

1. AddRef() – заставляет COM-объект увеличивать (инкрементировать) свой счетчик обращений. Вы должны использовать этот метод, если была сделана копия указателя на интерфейс и нужно обеспечить возможность использования двух указателей – копии и оригинала. Мы не будем использовать метод AddRef() в этой статье, т.к. для рассматриваемых здесь задач он не нужен. 

2. Release() – сообщает COM-объекту о необходимости уменьшения (декремента) счетчика обращений. Смотрите предыдущий пример, чтобы понять, как нужно использовать Release(). 

3. QueryInterface() – запрашивает указатель на интерфейс COM-объекта. Используется если CO-класс содержит не один, а несколько интерфейсов.

Вы уже видели пример использования Release(), но как же действует QueryInterface()? Когда вы создаете COM-объект с помощью CoCreateInstance(), вы получаете указатель на интерфейс. Если COM-объект включает более одного интерфейса (не считая IUnknown), вы должны использовать метод QueryInterface() для получения дополнительных указателей на интерфейсы, которые вам нужны. Посмотрим на прототип QueryInterface():

HRESULT IUnknown::QueryInterface(REFIID iid, void** ppv);

Значения параметров:

iid IID интерфейса, который вам нужен.
ppv Адрес указателя на интерфейс. QueryInterface() возвращает указатель на интерфейс через этот параметр, если не произошло никаких ошибок.

Продолжим наш пример с ярлыком. CO-класс для создания ярлыков включает интерфейсы IShellLink и IPersistFile. Если у вас уже есть указатель на IShellLink – pISL, то вы можете запросить интерфейс IPersistFile у COM-объекта с помощью следующего кода:

HRESULT hr;

IPersistFile* pIPF;

hr = pISL->QueryInterface(IID_IPersistFile, (void**)&pIPF);

Затем вы тестируете hr с помощью макроса SUCCEEDED. Это нужно, чтобы узнать, сработал ли метод QueryInterface(). Если все нормально, то можно использовать новый указатель pIPF, так же как и любой другой интерфейсный указатель. Затем вам нужно вызвать метод pIPF->Release() для сообщения COM-объекту, что вы закончили работу с интерфейсом и он вам больше не нужен.

Обратите внимание – обработка строк

Я хочу остановиться на некоторых моментах, касающихся работы со строками при написании программ в COM.

Всякий раз, когда метод COM возвращает строку, он делает это, используя формат Unicode. Unicode это таблица символов, также как и ASCII, только все символы в ней занимают 2 байта (в ANSI – один байт). Если вы хотите получить строку в более удобном виде, то ее нужно преобразовать в тип TCHAR.

TCHAR и функции, начинающиеся с _t (например, _tcscpy()) были разработаны для управления строками Unicode и ANSI с использованием одинакового исходного кода. Наверняка, вы раньше писали программы с использованием ANSI-строк и ANSI-функций, поэтому далее в этой статье я буду обращаться к типу char, вместо TCHAR, чтобы лишний раз вас не смущать. Однако, вы должны знать, что есть такой тип – TCHAR, хотя бы для того, чтобы не задавать лишних вопросов, когда встретите его в программах, написанных другими разработчиками.

Когда вы получаете строку из метода COM, вы можете преобразовать ее в строку char одним из следующих способов:

1. Вызвать функцию API WideCharToMultiByte(). 

2. Вызвать функцию CRT wcstombs().

3. Использовать конструктор CString или оператор присваивания (только в MFC). 

4. Использовать макрос преобразования ATL.

Особенности Unicode

С другой стороны, вы можете лишь хранить строку Unicode, если с ней не требуется делать что-либо еще. Если вы создаете консольное приложение, то вывод на экран строки Unicode можно осуществить с помощью глобальной переменной std::wcout, например:

wcout << wszSomeString;

Однако, имейте ввиду, что wcout предполагает, что все "входящие" строки имеют формат Unicode, поэтому если вы имеете любую "нормальную" строку, то для вывода нужно использовать std::cout. Если вы используете строковые литералы, для перевода в Unicode ставьте перед ними символ L, например:

wcout << L"The Oracle says…" << endl << wszOracleResponse;

Если вы используете строки Unicode, вы должны знать о следующих ограничениях:

• С этими строками вы должны использовать функции вида wcsXXX(), например wcslen(). 

• За редким исключением, вы не должны передавать строки Unicode функциям Windows API в ОС Windows 9x. Чтобы обеспечить переносимость кода между платформами 9x и NT, вы должны использовать типы TCHAR, как это описано в MSDN. Объединим все вместе – Примеры Программ

Здесь приведены два примера, иллюстрирующие концепции COM, которые обсуждались ранее в этой статье.

Использование объекта COM с одним интерфейсом

Первый пример показывает, как можно использвать объект COM, содержащий единственный интерфейс. Это простейший случай из тех, которые вам могут встретиться. Программа использует содержащийся в оболочке CO-класс Active Desktop для получения имени файла "обоев", которые установлены в данный момент. Чтобы этот код был работоспособен, вам может потребоваться установить Active Desktop.

Мы должны осуществить следующие шаги:

1. Инициализировать библиотеку COM. 

2. Создать COM-объект, используемый для взаимодействия с Active Desktop и получить интерфейс IActiveDesktop. 

3. Вызвать метод COM-объекта GetWallpaper(). 

4. Если GetWallpaper() завершился успешно, вывести имя файла "обоев" на экран. 

5. Освободить интерфейс. 

6. Разинициализировать библиотеку COM.

WCHAR wszWallpaper[MAX_PATH];

CString strPath;

HRESULT hr;

IActiveDesktop* pIAD;


// 1. Инициализация библиотеки COM (заставляем Windows загрузить библиотеки DLL). Обычно

// вам нужно делать это в функции InitInstance() или подобной ей. В MFC-приложениях

// можно также использовать функцию AfxOleInit().

CoInitialize(NULL);

// 2. Создаем COM-объект, используя CO-класс Active Desktop, поставляемый оболочкой.

// Четвертый параметр сообщает COM какой именно интерфейс нам нужен (IActiveDesktop).

hr = CoCreateInstance(CLSID_ActiveDesktop, NULL, CLSCTX_INPROC_SERVER, IID_IActiveDesktop, (void**)&pIAD);

if (SUCCEEDED(hr)) {

 // 3. Если COM-объект был создан, то вызываем его метод GetWallpaper().

 hr = pIAD->GetWallpaper(wszWallpaper, MAX_PATH, 0);

 if (SUCCEEDED(hr)) {

  // 4. Если GetWallpaper() завершился успешно, выводим полученное имя файла.

  // Заметьте, что я использую wcout для отображения Unicode-строки wszWallpaper.

  // wcout является Unicode-эквивалентом cout.

  wcout << L"Wallpaper path is:\n " << wszWallpaper << endl << endl;

 } else {

  cout << _T("GetWallpaper() failed.") << endl << endl;

 }

 // 5. Освобождаем интерфейс.

 pIAD->Release();

} else {

 cout << _T("CoCreateInstance() failed.") << endl << endl;

}

// 6. Разинициализируем библиотеку COM. В приложениях MFC этого не требуется –

// MFC делает это автоматически.

CoUninitialize();

В этом примере я использовал std::wcout для отображения строки Unicode wszWallpaper.

Использование COM-объекта, включающего несколько интерфейсов

Второй пример показывает, как можно использовать QueryInterface() для получения единственного интерфейса COM-объекта. В этом примере используется CO-класс Shell Link, содержащийся в оболочке, для создания ярлыка для файла "обоев", имя которого мы получили в предыдущем примере.

Программа состоит из следующих шагов:

1. Инициализация библиотеки COM. 

2. Создание объекта COM, используемого для создания ярлыков, и получение интерфейса IShellLink. 

3. Вызов метода SetPath() интерфейса IShellLink. 

4. Вызов метода QueryInterface() объекта COM и получение интерфейса IPersistFile. 

5. Вызов метода Save() интерфейса IPersistFile. 

6. Освобождение интерфейсов. 

7. Разинициализация библиотеки COM.

CString sWallpaper = wszWallpaper; // Конвертация пути к "обоям" в ANSI

IShellLink* pISL;

IPersistFile* pIPF;


// 1. Инициализация библиотеки COM (заставляем Windows загрузить библиотеки DLL). Обычно

// вам нужно делать это в функции InitInstance() или подобной ей. В MFC-приложениях

// можно также использовать функцию AfxOleInit().

CoInitialize(NULL);

// 2. Создание объекта COM с использованием CO-класса Shell Link, поставляемого оболочкой.

// 4-й параметр указывает на то, какой интерфейс нам нужен (IShellLink).

hr = CoCreateInstance(CLSID_ShellLink, NULL, CLSCTX_INPROC_SERVER, IID_IShellLink, (void**)&pISL);

if (SUCCEEDED(hr)) {

 // 3. Устанавливаем путь, на который будет указывать ярлык (к файлу "обоев").

 hr = pISL->SetPath(sWallpaper);

 if (SUCCEEDED(hr)) {

  // 4. Получение второго интерфейса (IPersistFile) от объекта COM.

  hr = pISL->QueryInterface(IID_IPersistFile, (void**)&pIPF);

  if (SUCCEEDED(hr)) {

   // 5. Вызов метода Save() для сохранения ярлыка в файл. Первый параметр

   // является строкой Unicode.

   hr = pIPF->Save(L"C:\\wallpaper.lnk", FALSE);

   // 6a. Освобождение интерфейса IPersistFile.

   pIPF->Release();

  }

 }

 // 6b. Освобождение интерфейса IShellLink.

 pISL->Release();

}

// Где-то здесь должен быть код для обработки ошибок.

// 7. Разинициализация библиотеки COM. В приложениях MFC этого делать

// не нужно, т.к. MFC справляется с этим сама.

CoUninitialize();

Литература

Essential COM, Don Box, ISBN 0-201-63446-5.

MFC Internals, George Shepherd and Scot Wingo, ISBN 0-201-40721-3.

Beginning ATL 3 COM Programming, Richard Grimes, ISBN 1-861001-20-7.

ВОПРОС-ОТВЕТ 

Q. Как в Win9x и WinNT заблокировать клавиши WIN, Alt+Tab, Ctrl+Esc etc.?

Mike Krasnik 

A1 Например так – в конструкторе главного окна приложения зарегистрировать HotKey:

m_HK = GlobalAddAtom("alttab"); // DWORD m_HK;

RegisterHotKey(GetSafeHwnd(), m_HK, MOD_ALT, VK_TAB); 

а в деструкторе не забыть его разрегистрировать: 

UnregisterHotKey(GetSafeHwnd(), m_HK); 

так как никакого обработчика для этого HotKey мы не делаем, то соответственно и происходить по нажатию Alt-Tab ничего не будет.

Алексей Кирюшкин 

A2 По материалам http://msdn.microsoft.com/msdnmag/issues/0700/Win32/Win320700.asp

В WinNT (начиная с Windows NTR 4.0 Service Pack 3) существует возможность использовать "low-level" hook на клавиатуру WH_ KEYBOARD_LL для отключения комбинаций Ctrl+Esc, Alt+Tab, Alt+Esc.

Для данной данной функии установлен лимит времени: Система возвращается в нормальное состояние через промежуток времени определяемый параметром LowLevelHooksTimeout в HKEY_CURRENT_USER\Control Panel\Desktop время указывается в милисекундах.

Владимир Згурский 

A3 Это делается очень по-разному в различных системах от Microsoft.

В Windows 9x можно использовать трюк, опсанный в MSDN – вызвать функцию SystemParametersInfo с недокументированным параметром. В данном случае им можно пользоваться смело: Микрософт больше не будет вносить изменений в архитектуру Win9x. Чтобы отключить Alt+Tab, Ctrl+Alt+Del и т. д., нужно написать: 

int prev;

SystemParametersInfo(SPI_SCREENSAVERRUNNING, TRUE, &prev, 0); 

Выполняя этот код, мы сообщаем системе, что работает скринсейвер. А когда он работает, переключение задач запрещено. Чтобы включить стандартные комбинации снова, используйте: 

int prev;

SystemParametersInfo(SPI_SCREENSAVERRUNNING, FALSE, &prev, 0); 

Внимание: если этого не сделать, переключение задач будет невозможно даже после завершения работы вашего приложения! 

Перейдём к Windows NT/2000. Там трюк со скрин сейвером не работает, но зато есть низкоуровневые хуки для мыши и клавиатуры (обычные хуки не перехватывают системные комбинации клавиш). Установив глобальный низкоуровневый хук на клавиатуру, можно "съесть" все системные нажатия (кроме Ctrl+Alt+Del). Для этого в ответ на приход таких нажатий функция хука должна вернуть единицу. 

Как известно, хуки устанавливаются функцией SetWindowsHookEx. В нашем случае требуется глобальный хук, а значит, его код придётся размещать в DLL. DLL может выглядеть примерно так. 

#define _WIN32_WINNT 0x0500

#include <windows.h>


static HINSTANCE hInstance;

static HHOOK     hHook;


BOOL APIENTRY DllMain(HANDLE hModule, DWORD  ul_reason_for_call, LPVOID lpReserved) {

 hInstance = (HINSTANCE)hModule;

 return TRUE;

}


LRESULT CALLBACK KeyboardProc(INT nCode, WPARAM wParam, LPARAM lParam);


extern "C" __declspec(dllexport) void HookKeyboard() {

 hHook = SetWindowsHookEx(WH_KEYBOARD_LL, (HOOKPROC)KeyboardProc, hInstance, 0);

}


extern "C" __declspec(dllexport) void UnhookKeyboard() {

 UnhookWindowsHookEx(hHook);

}


LRESULT CALLBACK KeyboardProc(INT nCode, WPARAM wParam, LPARAM lParam) {

 KBDLLHOOKSTRUCT *pkbhs = (KBDLLHOOKSTRUCT*)lParam;

 BOOL bControlKeyDown = 0;

 if (nCode == HC_ACTION) {

  bControlKeyDown = GetAsyncKeyState(VK_CONTROL) >> ((sizeof(SHORT) * 8) - 1);

  // Проверяем CTRL+ESC

  if (pkbhs->vkCode == VK_ESCAPE && bControlKeyDown) return 1;

  // Проверяем ALT+TAB

  if (pkbhs->vkCode == VK_TAB && pkbhs->flags & LLKHF_ALTDOWN) return 1;

  // Проверяем ALT+ESC

  if (pkbhs->vkCode == VK_ESCAPE && pkbhs->flags & LLKHF_ALTDOWN) return 1;

 }

 return CallNextHookEx(hHook, nCode, wParam, lParam);

}

Чтобы воспользоваться этой DLL, загрузите её любым способом, а затем вызывайте HookKeyboard, чтобы перехватывать комбинации клавиш, и UnhookKeyboard, чтобы прекратить перехват. 

В ранних версиях NT низкоуровневых хуков не было. В MSDN утверждается, что там от Alt+Tab там можно избавиться с помощью перерегистрации глобального акселератора на ту же комбинацию (посредством RegisterHotKey), но испытать это средство мне не удалось (нет под рукой NT3.51 или NT4.0 с SP 2 и ниже). Ctrl+Esc там не блокируется. 

Для полноты картины упомяну ещё одно непровереное средство, с помощью которого можно обезвредить Ctrl+Alt+Del под Windows NT/2000. Для этого нужно написать собственную GINA DLL. Если кого-нибудь интересуют подробности, сделайте в MSDN поиск по строке "GINA".

Александр Шаргин 
ОБРАТНАЯ СВЯЗЬ 

Уважаемый Алекс.

Читая Вашу статью о DCOM я прочел:

"Строго говоря, COM не является спецификацией, привязанной к Win32. Теоретически, можно портировать ваши COM-объекты в Unix или любые другие ОС. Однако, я никогда не видел, чтобы COM применялась где-то за пределами сферы влияния Microsoft."

Могу подсказать ОС использующую COM/DCOM не из семейства Windows. Как ни странно это VxWorks, где COM/DCOM существует в виде одного из компонент ядра и обеспечивает все, что может быть положено на концепцию этой ОС.

Например из-за ограничений ОС (там по сути только один процесс с общей памятью, но со многими потоками-задачами) серверы могут быть только INPROC. Не поддержан (пока что) IDispatch, массивы в VARIANT. Зато теперь можно использовать DCOM-распределенные системы на основе смеси Windows и VxWorks, что очень удобно для управления realtime системами.

С уважением

Алексей Трошин 

На вопрос из выпуска №27 о пунктирной рамке вокруг кнопки: 

Предложенный Александром Шаргиным вариант с тулбаром врядли можно признать удовлетворительным. Диалог не получит сообщение от тулбара да и программное создание кнопки… Можно, конечно, но… :-( . Наиболее приемлемый выход – использование самопрорисовывающихся элементов управления. Достоинство этого метода – нарисовать можно всё, что угодно! :-))). А в вопросе Максима Чучуйко есть ещё подвопрос: А должна ли кнопка вообще получать фокус?.

В общем, плоскую кнопку, не получающую фокус совсем сделать достаточно просто:

1) Создаём класс

CFlatButton: public CButton;

2) Добавляем переменные:

protected:

 BOOL bMouseCaptured;

 CWnd* pOldFocus;

В конструкторе инициализируем:

 bMouseCaptured = FALSE;

 pOldFocus = NULL;

3) Добавляем методы:

protected:

 void CFlatButton::SetOldFocus() {

  // Закомментировать тело метода, если кнопка может получать фокус.

  if (pOldFocus) pOldFocus->SetFocus();

  pOldFocus =NULL;

}

Добавляем обработчики сообщений:

 void CFlatButton::OnSetFocus(CWnd* pOldWnd) {

  CButton::OnSetFocus(pOldWnd);

  if (!pOldFocus) // Дабы не было проблем с модальными окнами, вызываемыми по нажатию этой кнопки.

   pOldFocus = pOldWnd;

 }


 void CFlatButton::OnLButtonUp(UINT nFlags, CPoint point) {

  CButton::OnLButtonUp(nFlags, point);

  CRect rectBtn;

  GetClientRect(rectBtn);

  if (rectBtn.PtInRect(point) && GetCapture() != this) {

   bMouseCaptured = TRUE;

   SetCapture();

   Invalidate(FALSE);

  }

  SetOldFocus();

 }


 void CFlatButton::OnMouseMove(UINT nFlags, CPoint point) {

  CRect rectBtn;

  GetClientRect(rectBtn);

  if (rectBtn.PtInRect(point)) {

   BOOL bNeedUpdate =FALSE;

   if (!bMouseCaptured) bNeedUpdate = TRUE;

   bMouseCaptured = TRUE;

   SetCapture();

   if (bNeedUpdate) Invalidate(FALSE);

  } else {

   bMouseCaptured = FALSE;

   ReleaseCapture();

   SetOldFocus();

   Invalidate(FALSE);

  }

  CButton::OnMouseMove(nFlags, point);

 }

И, самое интересное… :-))) Перекрываем виртуальный метод:

void CFlatButton::DrawItem(LPDRAWITEMSTRUCT lpDIS) {

 // Test WS_TABSTOP

 ASSERT(!(GetStyle() & WS_TABSTOP)); 

 CDC* pDC = CDC::FromHandle(lpDIS->hDC);

 CRect rectAll;

 GetClientRect(rectAll);

 CString text;

 GetWindowText(text);

 int save = pDC->SaveDC();

 CRect rectText(rectAll);

 rectText.DeflateRect(2,2);

 CBrush bkBr(GetSysColor(COLOR_3DFACE));

 pDC->FillRect(rectAll,&bkBr);

 UINT state = lpDIS->itemState;

 if (state & ODS_SELECTED) {

  // Нажатое состояние

  rectText.OffsetRect(1,1);

  pDC->DrawEdge(rectAll, BDR_SUNKENOUTER, BF_RECT);

 } else {

  if (bMouseCaptured) {

   pDC->DrawEdge(rectAll, BDR_RAISEDINNER, BF_RECT);

  }

 }

 pDC->DrawText(text, rectText, DT_SINGLELINE|DT_VCENTER|DT_CENTER|DT_TOP);

 pDC->RestoreDC(save);

}

Использование: очень просто. Ставим на шаблоне диалога кнопку, убираем стиль WS_TABSTOP, ставим стиль WS_OWNERDRAW. В ClassWizard'е сопоставляем ей переменную типа CButton, затем тип переменной вручную меняем на CFlatButton. И всё. Далее – как с обычной кнопкой. У меня (VC++ 5.0) – работает.

Дмитрий Сулима
В ПОИСКАХ ИСТИНЫ

Q. Как включать в проект незарегистрированный компонент ActiveX? Вернее он на моей машине зарегистрирован, а на другой нет, и в результате этого программа на той машине вообще не запускается.

Сергей Лобачев

Это все на сегодня. Удачи вам!

Алекс Jenter jenter@mail.ru
Красноярск, 2000.

Программирование на Visual C++ Выпуск №30 от 28 января 2001 г.

Здравствуйте, дорогие друзья!

Я очень рад вас всех вновь приветствовать! К сожалению, по не зависящим от меня причинам я не имел возможности выпускать рассылку вплоть до настоящего времени. Искренне прошу извинить за причиненные неудобства и такой вот вынужденный перерыв. Хочу развеять опасения некоторых товарищей: рассылку я закрывать не собираюсь. Начиная с сегодняшнего дня, выпуски будут опять выходить регулярно.

За это время количество подписчиков перевалило за 10 000 – действительно круглое число! Создавая рассылку, я и не предполагал, что она будет пользоваться такой популярностью – все-таки весьма специфичная тематика. Но это значит, что рассылка актуальна, и это не может не радовать. Что еще могу сказать – оставайтесь с нами, и скорее всего не пожалеете!

А теперь – let's get started!

СТАТЬЯ

Помнится, в одном из декабрьских выпусков шел у нас разговор о предотвращении запуска второй копии приложения. Тогда мы затронули тему использования объектов синхронизации, подробнее про которые я пообещал рассказать во второй части статьи про многозадачность. Тема эта хотя и очень интересная, но и довольно обширная; так что учитывая ограниченность места в одном выпуске, я освещу только самые важные для понимания моменты. Некоторые же второстепенные темы – такие, как предотвращение взаимного блокирования потоков, или оповещения об изменениях, – я здесь лишь упомяну, и (возможно) вынесу в дальнейшем в отдельную статью. Также в отдельную статью скорее всего выльется очень важная тема межпроцессного обмена данными (inter-process communication, IPC). Как скоро появятся эти статьи, будет зависеть от степени их востребованности. А пока представляю вашему вниманию давно обещанную вторую часть статьи про многозадачность.

Многозадачность и ее применение
Часть 2: Синхронизация потоков

Итак, в первой части статьи (см. №23) мы определили, что использование многопоточности находит себе широчайшее применение в самых различных программах и позволяет значительно повысить производительность и надежность приложений и системы в целом, сделать работу пользователя более комфортной, а также несколько упростить логику программы, производя естественное разделение обязанностей между потоками. Настоящий программист под Windows должен знать и уметь использовать преимущества операционной системы, одним из которых как раз и является вытесняющая многозадачность.

Необходимость синхронизации

Если вы помните, в Windows выполняются не процессы, а потоки. При создании процесса автоматически создается его основной поток. Этот поток в процессе выполнения может создавать новые потоки, которые, в свою очередь, тоже могут создавать потоки и т.д. Процессорное время распределяется именно между потоками, и получается, что каждый поток работает независимо.

Все потоки, принадлежащие одному процессу, разделяют некоторые общие ресурсы – такие, как адресное пространство оперативной памяти или открытые файлы. Эти ресурсы принадлежат всему процессу, а значит, и каждому его потоку. Следовательно, каждый поток может работать с этими ресурсами без каких-либо ограничений. Но так ли это в действительности? Вспомним, что в Windows реализованам вытесняющая многозадачность – это значит, что в любой момент система может прервать выполнение одного потока и передать управление другому. (Раньше использовался способ организации, называемый кооперативной многозадачностью. Система ждала, пока поток сам не соизволит передать ей управление. Именно поэтому в случае глухого зависания одного приложения приходилось перезагружать компьютер. Так была организована, например, Windows 3.1). Что произойдет, если один поток еще не закончил работать с каким-либо общим ресурсом, а система переключилась на другой поток, использующий тот же ресурс? Произойдет штука очень неприятная, я вам это могу с уверенностью сказать, и результат работы этих потоков может чрезвычайно сильно отличаться от задуманного. Такие конфликты могут возникнуть и между потоками, принадлежащими различным процессам. Всегда, когда два или более потоков используют какой-либо общий ресурс, возникает эта проблема.

Именно поэтому необходим механизм, позволяющий потокам согласовывать свою работу с общими ресурсами. Этот механизм получил название механизма синхронизации потоков (thread synchronization).

Структура механизма синхронизации

Что же представляет собой этот механизм? Это набор объектов операционной системы, которые создаются и управляются программно, являются общими для всех потоков в системе (некоторые – для потоков, принадлежащих одному процессу) и используются для координирования доступа к ресурсам. В качестве ресурсов может выступать все, что может быть общим для двух и более потоков – файл на диске, порт, запись в базе данных, объект GDI, и даже глобальная переменная программы (которая может быть доступна из потоков, принадлежащих одному процессу).

Объектов синхронизации существует несколько, самые важные из них – это взаимоисключение (mutex), критическая секция (critical section), событие (event) и семафор (semaphore). Каждый из этих объектов реализует свой способ синхронизации. Какой из них следует использовать в каждом конкретном случае вы поймете, подробно познакомившись с каждым из этих объектов. Также в качестве объектов синхронизации могут использоваться сами процессы и потоки (когда один поток ждет завершения другого потока или процесса); а также файлы, коммуникационные устройства, консольный ввод и уведомления об изменении (к сожалению, освещение этих объектов синхронизации выходит за рамки данной статьи).

В чем смысл объектов синхронизации? Каждый из них может находиться в так называемом сигнальном состоянии. Для каждого типа объектов это состояние имеет различный смысл. Потоки могут проверять текущее состояние объекта и/или ждать изменения этого состояния и таким образом согласовывать свои действия. Что еще очень важно – гарантируется, что когда поток работает с объектами синхронизации (создает их, изменяет состояние) система не прервет его выполнения, пока он не завершит это действие. Таким образом, все конечные операции с объектами синхронизации являются атомарными (неделимыми), как бы выполняющимися за один такт.

Важно понимать, что никакой реальной связи между объектами синхронизации и ресурсами нет. Они не смогут предотвратить нежелательный доступ к ресурсу, они лишь подсказывают потокам, когда можно работать с ресурсом, а когда нужно подождать. Можно провести грубую аналогию со светофорами – они показывают, когда можно ехать, но ведь в принципе водитель может и не обратить внимания на красный свет (правда, потом он об этом скорее всего пожалеет ;)

Работа с объектами синхронизации

Чтобы создать тот или иной объект синхронизации, производится вызов специальной функции WinAPI типа Create… (напр. CreateMutex). Этот вызов возвращает дескриптор объекта (HANDLE), который может использоваться всеми потоками, принадлежащими данному процессу. Есть возможность получить доступ к объекту синхронизации из другого процесса – либо унаследовав дескриптор этого объекта, либо, что предпочтительнее, воспользовавшись вызовом функции открытия объекта (Open…). После этого вызова процесс получит дескриптор, который в дальнейшем можно использовать для работы с объектом. Объекту, если только он не предназначен для использования внутри одного процесса, обязательно присваивается имя. Имена всех объектов должны быть различны (даже если они разного типа). Нельзя, например, создать событие и семафор с одним и тем же именем.

По имеющемуся дескриптору объекта можно определить его текущее состояние. Это делается с помощью т.н. ожидающих функций. Чаще всего используется функция WaitForSingleObject. Эта функция принимает два параметра, первый из которых – дескриптор объекта, второй – время ожидания в мсек. Функция возвращает WAIT_OBJECT_0, если объект находится в сигнальном состоянии, WAIT_TIMEOUT — если истекло время ожидания, и WAIT_ABANDONED, если объект-взаимоисключение не был освобожден до того, как владеющий им поток завершился.

Если время ожидания указано равным нулю, функция возвращает результат немедленно, в противном случае она ждет в течение указанного промежутка времени. В случае, если состояние объекта станет сигнальным до истечения этого времени, функция вернет WAIT_OBJECT_0, в противном случае функция вернет WAIT_TIMEOUT.

Если в качестве времени указана символическая константа INFINITE, то функция будет ждать неограниченно долго, пока состояние объекта не станет сигнальным.

Если необходимо узнавать о состоянии сразу нескольких объектов, следует воспользоваться функцией WaitForMultipleObjects.

Чтобы закончить работу с объектом и освободить дескриптор вызывается функция CloseHandle.

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

Теперь давайте рассмотрим каждый тип объектов синхронизации в отдельности.

Взаимоисключения

Объекты-взаимоисключения (мьютексы, mutex – от MUTual EXclusion) позволяют координировать взаимное исключение доступа к разделяемому ресурсу. Сигнальное состояние объекта (т.е. состояние "установлен") соответствует моменту времени, когда объект не принадлежит ни одному потоку и его можно "захватить". И наоборот, состояние "сброшен" (не сигнальное) соответствует моменту, когда какой-либо поток уже владеет этим объектом. Доступ к объекту разрешается, когда поток, владеющий объектом, освободит его.

Для того, чтобы объявить взаимоисключение принадлежащим текущему потоку, надо вызвать одну из ожидающих функций. Поток, которому принадлежит объект, может его "захватывать" повторно сколько угодно раз (это не приведет к самоблокировке), но столько же раз он должен будет его освобождать с помощью функции ReleaseMutex.

События

Объекты-события используются для уведомления ожидающих потоков о наступлении какого-либо события. Различают два вида событий – с ручным и автоматическим сбросом. Ручной сброс осуществляется функцией ResetEvent. События с ручным сбросом используются для уведомления сразу нескольких потоков. При использовании события с автосбросом уведомление получит и продолжит свое выполнение только один ожидающий поток, остальные будут ожидать дальше.

Функция CreateEvent создает объект-событие, SetEvent – устанавливает событие в сигнальное состояние, ResetEvent — сбрасывает событие. Функция PulseEvent устанавливает событие, а после возобновления ожидающих это событие потоков (всех при ручном сбросе и только одного при автоматическом), сбрасывает его. Если ожидающих потоков нет, PulseEvent просто сбрасывает событие.

Семафоры

Объект-семафор – это фактически объект-взаимоисключение со счетчиком. Данный объект позволяет "захватить" себя определенному количеству потоков. После этого "захват" будет невозможен, пока один из ранее "захвативших" семафор потоков не освободит его. Семафоры применяются для ограничения количества потоков, одновременно работающих с ресурсом. Объекту при инициализации передается максимальное число потоков, после каждого "захвата" счетчик семафора уменьшается. Сигнальному состоянию соответствует значение счетчика больше нуля. Когда счетчик равен нулю, семафор считается не установленным (сброшенным).

Критические секции

Объект-критическая секция помогает программисту выделить участок кода, где поток получает доступ к разделяемому ресурсу, и предотвратить одновременное использование ресурса. Перед использованием ресурса поток входит в критическую секцию (вызывает функцию EnterCriticalSection). Если после этого какой-либо другой поток попытается войти в ту же самую критическую секцию, его выполнение приостановится, пока первый поток не покинет секцию с помощью вызова LeaveCriticalSection. Похоже на взаимоисключение, но используется только для потоков одного процесса.

Существует также функция TryEnterCriticalSection, которая проверяет, занята ли критическая секция в данный момент. С ее помощью поток в процессе ожидания доступа к ресурсу может не блокироваться, а выполнять какие-то полезные действия.

Защищенный доступ к переменным

Существует ряд функций, позволяющих работать с глобальными переменными из всех потоков не заботясь о синхронизации, т.к. эти функции сами за ней следят. Это функции InterlockedIncrement/InterlockedDecrement, InterlockedExchange,InterlockedExchangeAdd и InterlockedCompareExchange. Например, функция InterlockedIncrement увеличивает значение 32-битной переменной на единицу – удобно использовать для различных счетчиков. Более подробно об этих функциях см. в документации.

Пример

Как известно, теория лучше всего познается на примерах. Давайте рассмотрим небольшой пример работы с объектом-взаимоисключением. Для простоты я использовал консольное Win32 приложение, но как вы понимаете, это совершенно не обязательно.

#include <windows.h>

#include <iostream.h>


void main() {

 DWORD res;

 // создаем объект-взаимоисключение

 HANDLE mutex = CreateMutex(NULL, FALSE, "APPNAME-MTX01");

 // если он уже существует, CreateMutex вернет дескриптор существующего объекта,

 // а GetLastError вернет ERROR_ALREADY_EXISTS

 // в течение 20 секунд пытаемся захватить объект

 cout<<"Trying to get mutex...\n";

 cout.flush();

 res = WaitForSingleObject(mutex, 20000);

 if (res == WAIT_OBJECT_0) // если захват удался

 {

  // ждем 10 секунд

  cout<<"Got it! Waiting for 10 secs…\n";

  cout.flush();

  Sleep(10000);

  // освобождаем объект

  cout<<"Now releasing the object.\n";

  cout.flush();

  ReleaseMutex(mutex);

 }

 // закрываем дескриптор

 CloseHandle(mutex);

}

Для проверки работы мьютекса запустите сразу два экземпляра этого приложения. Первый экземпляр сразу захватит объект и освободит его только через 10 секунд. Только после этого второму экземпляру удастся захватить объект. В данном примере объект используется для синхронизации между процессами, поэтому он обятельно должен иметь имя.

Cинхронизация в MFC

Библиотека MFC содержит специальные классы для синхронизации потоков (CMutex, CEvent, CCriticalSection и CSemaphore). Эти классы соответствуют объектам синхронизации WinAPI и являются производными от класса CSyncObject. Чтобы понять, как их использовать, достаточно просто взглянуть на конструкторы и методы этих классов – Lock и Unlock. Фактически эти классы – всего лишь обертки для объектов синхронизации.

Eсть еще один способ использования этих классов – написание так называемых потоково-безопасных классов (thread-safe classes). Потоково-безопасный класс – это класс, представляющий какой либо ресурс в вашей программе. Вся работа с ресурсом осуществляется только через этот класс, который содержит все необходимые для этого методы. Причем класс спроектирован таким образом, что его методы сами заботятся о синхронизации, так что в приложении он используется как обычный класс. Объект синхронизации MFC добавляется в этот класс в качестве закрытого члена класса, и все функции этого класса, осуществляющие доступ к ресурсу, согласуют с ним свою работу.

С классами синхронизации MFC можно работать как напрямую, используя методы Lock и Unlock, так и через промежуточные классы CSingleLock и CMultiLock (хотя на мой взгляд, работать через промежуточные классы несколько неудобно. Но использование класса СMultiLock необходимо, если вы хотите следить за состоянием сразу нескольких объектов).

Заключение

Игнорируя возможности многозадачности, которые предоставляет Windows, вы игнорируете преимущества этой операционной системы. Как вы могли убедиться, многозадачность – это вовсе не так сложно, как кажется на первый взгляд.

Тем, кто интересуется этой темой, могу порекомендовать следующие статьи и разделы MSDN:

• Platform SDK / Windows Base Services / Executables / Processes and Threads

• Platform SDK / Windows Base Services / Interprocess Communication / Synchronization

• Periodicals 1996 / MSJ / December / First Aid For Thread-impaired:Using Multiple Threads with MFC

• Periodicals 1996 / MSJ / March / Win32 Q&A

• Periodicals 1997 / MSJ / July / C++ Q&A.

• Periodicals 1997 / MSJ / January / Win32 Q&A.

ВОПРОС-ОТВЕТ

Q. Как включать в проект незарегистрированный компонент ActiveX? Вернее он на моей машине зарегистрирован, а на другой нет, и в результате этого программа на той машине вообще не запускается.

Сергей Лобачев

A1 Большинство средств дистрибутирования (InstallShield, Wise, Windows Installer, etc.) позволяют регистрировать ActiveX-элементы в процессе инсталляции. При инсталляции "руками" можно вызвать regsvr32.exe и передать ей параметром исполняемый файл ActiveX-элемента. Если Вы сами пишете программу инсталляции – вызовите ф-ию DllRegisterServer из исполняемого файла ActiveX.

Но при этом помните – для использования чужого ActiveX в коммерческих проектах необходимо иметь на то лицензию.

Andrew Shvydky

A2 Сначала необходимо учесть, что перед запуском программы на другом компьютере, в случае добавления в свой проект ActiveX (COM) компонентов,их необходимо будет перенести и зарегестрировать в реестре.

Ответ несколькими способами:

1. Первый И пожалуй самый надежный это сделать инсталяшку, которая будет заниматься, помимо установки, регистрацией ActiveX компонентов. (ActiveX надо включить в инсталяшку)

2. Это написать .bat файл, в который включить строки regsvr32.exe my.ocx … и принести на другой комп свой .exe, .ocx,и этот .bat файл, перед первым запуском запустить .bat который зарегистрирует твой ActiveX в системе, а далее запускай программу. (Стандартная программа Window regsvr32.exe, займется регистрацией ActiveX компонента в системе)

3. Это самый утомительный, на другом компьютере через командную строку использую программу regsvr32.exe вручную зарегестрировать свои ActiveX компоненты.

Оleg Zhuk

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

ОБРАТНАЯ СВЯЗЬ

Хочу рассказать о решении одной проблемы, с которой я сам много провозился, да и многие другие тоже… Речь идет об инсталляции MSDN на компьютере, где уже установлен MSOffice 2000. Проблема возникает при регистрации коллекции справочников. Решение следующее: перенести файл C:\WINDOWS\HELP\HHCOLREG.DAT на другое место, а после установки MSDN объединить его с новым файлом на том же месте. Файл имеет простую текстовую структуру (XML) и разобраться в нем не составит труда. Другой вариант решения – ставить сначала MSDN, а уже затем Office.

Никита Зимин

Прочитав дополнение Алексея Трошина к статье о DCOM по поводу реализации DCOM на платформах, отличных от Windows, решил внести и свою небольшую лепту. Дело в том, что существует, и уже довольно давно (в течении нескольких лет) реализация DCOM для нескольких платформ, включая различные варианты UNIX систем, IBM mainfraim и OpenVMS. Семейство продуктов носит название EntireX и реализовано это немецкой компанией Software AG.

Более подробная информация есть на их сайте: http://www.softwareag.com/entirex/technical/data.htm.

Более того, эта же компания предоставляет бесплатную версию данного продукта для Linux, ее можно скачать отсюда: http://www.softwareag.com/entirex/download/free_download.htm. Пакет включает в себя реализацию многих компонентов DCOM, вкючая подмножество Win32 API, Structured Storage, Automation, ATL версии 2.1 и др.

Самое интересное, что все это даже работает :-) У нас был опыт успешного портирования Win32 DCOM сервиса, основанного на ATL под Linux платформу с использованием данного продукта.

Одним из существенных недостатков данного продукта является цена версий для не-Linux платформ – нам ее, например, так ни разу и не назвали, наверное чтобы не отпугивать сразу :-), поскольку полагаю, она не меленькая.

Прошу ни в коем случае не принимать мое письмо как рекламу данного продукта :-))) Я не имею никакого отношения к компании Software AG, просто подумал, что вам будет интересно об этом всем узнать.

Антон Масловский
В ПОИСКАХ ИСТИНЫ

Q. У меня одна проблема: Пишу одну программку (написал уже довольно много) используя Win32API. И у меня возникла проблема со ScrollBar'ами. Вся загвоздка в том, что позиция бегунка прокрутки описана как short int и соответственно лежит в двухбайтном диапазоне. А в моей программе диапазон прокрутки может быть больше чем 32767. В хелпе на сообщение WM_VSCROLL советуют использовать функцию GetScrollPos, у меня че-то не получилось ее использовать. Как решить эту проблему?

Алексей Иванов

Ну вот, на сегодня хватит. И так выпуски получаются довольно объемными. Кстати, хочу всем сказать: я НЕ высылаю архив выпусков по почте. Если вы хотите посмотреть старые выпуски, добро пожаловать в архив на Subscribe.ru.

До встречи!

Алекс Jenter jenter@mail.ru
Красноярск, 2001.

Программирование на Visual C++ Выпуск №31 от 4 февраля 2001 г.

Всем привет!

В Красноярске опять стоят жуткие холода, что надо сказать, уже до смерти надоело. Но точно также, как жизнь в городе – которая продолжается не смотря на температуру за бортом, продолжается и публикация различных интересных материалов в рассылке. На этот раз я хочу представить вашему вниманию статью про работу с оболочкой Windows, которую автор мне любезно разрешил опубликовать.

СТАТЬЯ Пространство имен оболочки Windows

Автор: Акжан Абдулин

Cтатья публикуется с сокращениями.

Полную версию этой статьи (с примерами), а также много другой полезной информации, вы можете найти на сайте автора по адресу http://www.akzhan.midi.ru

В операционных системах компании Microsoft с 1995 года используется новая оболочка, построенная на основе компонентной объектной модели. Одним из нововведений оболочки операционной системы стало понятие пространства имён оболочки. Пространство имён оболочки являет собой иерархически упорядоченный мир объектов, известных операционной системе, с их свойствами и предоставляемыми действиями. Оно во многом сходно со структурой файловой системы, но включает в себя не только файлы и каталоги. Такие понятия файловой системы, как имя файла и путь, заменены более универсальными. 

Основное пространство имён начинается с корневого объекта "Рабочий стол", и его легко исследовать, запустив приложение "Проводник". Параллельно основному пространству имён могут сосуществовать множество дополнительных пространств имён, о которых подробнее будет рассказано позднее.

Основные понятия

Пространство имён (Shell namespace) является древовидной структурой, состоящей из COM-объектов. Объекты, владеющие дочерними объектами, именуются папками (Shell folder), причём среди таковых могут оказаться и другие папки (Subfolders). Объекты, не владеющие дочерними объектами, именуются файловыми объектами (file objects), причём файловым объектом может представлять собой не только файл файловой системы, но и принтер, компонент "Панели Управления" или объект другого типа. Каждый объект имеет идентификатор элемента (Item identifier), однозначно определяющий его расположение в папке. Таким образом, чтобы указать на некий объект в данной папке, нам потребуется лишь передать его идентификатор. Если же мы хотим указать на некий объект в известном пространстве имён, тогда нам придётся указать идентификаторы всех папок, начиная с корня, и до самого объекта включительно. В качестве примера приведём аналогию из файловой системы: "C:\Мои документы\Доклад о возможных способах реализации интерфейса к корпоративной БД.doc" уникально представит файл относительно файловой системы известного (моего домашнего) компьютера.

То, что в файловой системе именуется путём к файлу, в пространстве имён именуется списком идентификаторов (Identifier List).

Объекты-папки знают о тех обьектах, которыми они владеют, и о тех операциях, которые с ними возможны. Папки предоставляют нам механизм для перечисления всех объектов, которыми данный объект-папка владеет – интерфейс IShellFolder. Получение от объекта указателя на данный интерфейс называется привязкой (Binding).

Большая часть объектов основного пространства имён оболочки являются объектами, представляющими часть файловой системы. Те же объекты, что не представлены в файловой системе, называются виртуальными. Такие виртуальные папки, как папки рабочего стола (desktop), "Мой Компьютер" (My Computer) и "Сетевое окружение" (Network Neighborhood), позволяют реализовать унифицированное пространство имён.

Каталоги файловой системы, используемые оболочкой в особых целях, называются специальными. Одной из таких папок, например, является папка "Программы" (Programs). Местонахождение специальных папок файловой системы указывается в подразделе ветви HKEY_CURRENT_USER/Software/Microsoft/Windows/CurrentVersion/Explorer/Shell Folders/.

Идентификаторы элементов

Идентификатор элемента является уникальным для той папки, в которой данный элемент (объект пространства имён оболочки) находится, и является двоичной структурой переменного размера, чей формат определяется тем программным обеспечением, которое поддерживает существование папки, владеющей определяемым данным идентификатором объектом. Идентификатор элемента имеет смысл только в контексте той папки, которая его сконструировала.

Идентификатор элемента описывается структурой SHITEMID, для которой определено лишь значение первого поля – размер данной структуры.

Список идентификаторов, уникально идентифицирующих объект в определённом пространстве имён, эквивалентен понятию пути для файловой системы, и определяется как список из последовательно расположенных идентификаторов, за которыми следует завершающее список 16-битное значение 0x0000 (ITEMIDLIST). Список идентификаторов может быть как абсолютным, то есть определяющим положение объекта относительно корневой папки, так и относительным, то есть определяющим положение элемента относительно какой-либо конкретной папки.

Приложение оперирует понятиемуказателя на список идентификаторов (pointer to an identifier list), который кратко именуют как PIDL-указатель. Все глобальные методы (утилиты) оболочки, принимающие в качестве одного из параметров PIDL-указатель, ожидают его в абсолютном формате. В то же время все методы интерфейса IShellFolder, принимающие в качестве одного из параметров pidl-указатель, ожидают его в относительном формате (если только в описании метода не указано иначе).

Ниже представлена функция, позволяющая получить указатель на следующий элемент в списке идентификаторов. В случае неудачи возвращается пустой указатель.

#include <shlobj.h>

LPITEMIDLIST GetNextItemID(const LPITEMIDLIST pidl) {

 size_t cb = pidl->mkid.cb;

 if (cb == 0) {

  return NULL;

 }

 pidl = (LPITEMIDLIST)(((LPBYTE)pidl) + cb);

 if (pidl->mkid.cb == 0) {

  return NULL;

 }

 return pidl;

}

За размещение списков идентификаторов отвечает распределитель памяти оболочки (Shell's allocator), предоставляющий интерфейс IMalloc. Указатель на данный интерфейс распределителя памяти оболочки можно получить через метод SHGetMalloc.

Таким образом, если Ваше приложение получает от оболочки PIDL-указатель, то оно становится ответственным за обязательное в дальнейшем освобождение этого списка с помощью распределителя памяти оболочки.

Ниже представлен пример копирования списка идентификаторов:

#include <shlobj.h>

size_t GetItemIDListSize(const LPITEMIDLIST pidl) {

 size_t size = 0;

 LPBYTE p = LPBYTE(pidl);

 while (p != NULL) {

  if (static_cast(p + size)->mkid.cb == 0) {

   size += sizeof(USHORT); // size of terminator;

   break;

  }

  size += static_cast(p + size)->mkid.cb;

 }

 return size;

}


LPITEMIDLIST CopyItemIDList(const LPITEMIDLIST pidl) {

 LPMALLOC pMalloc;

 LPITEMIDLIST pidlResult;

 if (pidl == NULL) {

  return NULL;

 }

 if (!SUCCEEDED(SHGetMalloc(&pMalloc)) {

  return NULL;

 }

 size_t size = GetItemIDListSize(pidl);

 pidlResult = pMalloc->Alloc(size);

 if (pidlResult!= NULL) {

  CopyMemory(pidlResult, pidl, size);

 }

 pMalloc->Release();

 return pidlResult;

}

Для увеличения эффективности работы Ваших приложений рекомендуется брать ссылку на распределитель памяти оболочки при запуске приложения, и освобождать эту ссылку при выходе из приложения.

Интерфейс IShellFolder предоставляет метод CompareIDs для определения расположения двух идентификаторов относительно друг друга (выше, ниже или равны) в данной папке. При этом параметр lParam определяет критерий упорядочивания, но заранее определённым для всех объектов-папок является только сортировка по имени (значение 0). Если вызов этого метода завершён успешно, то поле CODE возвращаемого значения содержит ноль при равенстве объектов, отрицательно, если первое меньше второго, и положительно в обратном случае.

hr = ppsf->CompareIDs(0, pidlA, pidlB);

if (SUCCEEDED(hr)) {

 iComparisonResult = short(HRESULT_CODE(hr))

}

Местонахождение объектов-папок

Некоторые папки имеют особое значение для оболочки. Для нахождения этих специальных папок, а также для того, чтобы пользователь мог сам искать необходимые ему папки, оболочка предоставляет специализированный набор функций:

SHGetDesktopFolder Возвращает интерфейс IShellFolder объекта-папки "Рабочий стол" (Desktop);
SHGetSpecialFolderLocation Возвращает указатель на список идентификаторов специального объекта-папки.
SHBrowseForFolder Проводит диалог с пользователем и возвращает указатель на список идентификаторов выбранного пользователем объекта-папки;
SHGetSpecialFolderPath Версия 4.71. Возвращает путь файловой системы для специального объекта-папки. Функция предназначена для работы со специальными папками, а не для работы с виртуальными.

При отсутствии нужной папки может, по требованию приложения, её создавать.

Навигация по пространству имён

Каждый объект-папка прдоставляет Вам возможность перебора всех объектов, которыми данный объект владеет. Для этого Вам предоставляется метод EnumObjects интерфейса IShellFolder, который возвращает интерфейс-итератор IEnumIDList. При этом Вы можете ограничить список (включать папки, не папки, скрытые и системные объекты).

Описание методов интерфейса IEnumIDList:

Clone Создаёт новый объект-итератор, идентичный данному;
Next Восстанавливает указанное количество идентификаторов элементов, находящихся в папке;
Reset Возвращает итератор к началу последовательности;
Skip Пропускает указанное количество элементов;

Таким образом Вы сможете получить набор указателей на списки идентификаторов, причём эти списки будут относительными по отношению к папке-владельцу.

Чтобы получить интерфейс IShellFolder для любого из этих объектов, Вам потребуется осуществить привязку, вызвав метод BindToObject интерфейса IShellFolder папки-владельца.

Чтобы узнать атрибуты данного объекта или нескольких объектов, необходимо вызвать метод GetAttributesOf интерфейса IShellFolder папки-владельца. При этом перед вызовом этого метода необходимо установить те атрибуты, значения которых Вы бы хотели выяснить. Если запрошены атрибуты нескольких элементов, то метод вернёт только те значения атрибутов, которые совпадают у всех переданных элементов. В частности, Вы сможете взять интерфейс IShellFolder только от тех объектов, которые имеют атрибут SFGAO_FOLDER. Вы можете обновить информацию об элементах, входящих в папку, использовав флаг SFGAO_VALIDATE.

Дополнительные возможности

Прежде всего, Ваше приложение всегда можете получить строку с именем объекта, представленном в удобном для Вас формате. Для этого интерфейс IShellFolder предоставляет метод GetDisplayNameOf.

Вы можете указать один из следующих требующихся форматов:

SHGDN_NORMAL Обычный формат представления;
SHGDN_INFOLDER Формат представления относительно данной папки;
SHGDN_INCLUDE_NONFILESYS Приложение заинтересовано в именах элементов всех типов. Если этот флаг не установлен, то приложение заинтересовано лишь в тех элементах, которые представляют часть файловой системы. Если этот флаг не установлен, и элемент не представляет собой часть файловой системы, то этот метод может быть выполнен неудачно;
SHGDN_FORADDRESSBAR Имя будет использовано для показа в адресном комбобоксе;
SHGDN_FORPARSING Формат представления, используемый для дальнейшего разбора имени;

Имя элемента, полученное с установленным флагом SHGDN_FORPARSING, имеет особое значение. Вы можете использовать такое имя как командную строку для запуска приложения. Говоря точнее – такое имя эквивалентно понятию пути файловой системы.

Интерфейс IShellFolder предоставляет метод SetNameOf, позволяющий изменить экранное имя файлового объекта или вложенной папки. Изменяя экранное имя элемента, Вы изменяете его идентификатор, поэтому функция возвращает PIDL-указатель на новый идентификатор. Изменение экранного имени файлового объекта приводит к его фактическому переименованию в файловой системе.

Интерфейс IShellFolder также предоставляет метод ParseDisplayName, который позволяет узнать идентификатор элемента по его имени. Этому методу необходимо передавать имя, сгенерированное методом GetDisplayNameOf с установленным флагом SHGDN_FORPARSING.

С помощью глобального метода SHGetPathFromIDList по списку идентификаторов, определяющих объект относительно корня пространства имён, можно определить путь к объекту файловой системы.

С помощью глобального метода SHAddToRecentDocs Ваше приложение может добавить документ к списку последних, с которыми работал пользователь, или очистить этот список.

С помощью глобального метода SHEmptyRecycleBin, появившегося в версии 4.71 оболочки windows, Ваше приложение может очистить корзину (recycle bin). Удаление файла в корзину (то есть – с возможностью дальнейшего восстановления) производится глобальным методом SHFileOperation, подробное описание которого выходит за рамки этого обзора. Вы также можете узнать количество объектов, расположенных в корзине, и их суммарный размер, с помощью метода SHQueryRecycleBin.

Примечания

Microsoft Visual C++ поставляется с файлами заголовков <comip.h> и <comdef.h> поддержки COM, в которых определены шаблон класса _com_ptr_t, инкапсулирующий функциональность ссылки на com-объект, и самые распространённые специализации этого шаблона (в том числе для большинства стандартных интерфейсов пространства имён оболочки). При их использовании освобождение ссылок автоматизируется.

Copyright 1999 by Akzhan Abdulin. При публикации просьба указывать источник и авторство.

Комментарии, исправления, замечания и пожелания приветствуются по адресу: akzhan@beep.ru.

ВОПРОС-ОТВЕТ 

Q. У меня одна проблема: Пишу одну программку (написал уже довольно много) используя Win32API. И у меня возникла проблема со ScrollBar'ами. Вся загвоздка в том, что позиция бегунка прокрутки описана как short int и соответственно лежит в двухбайтном диапазоне. А в моей программе диапазон прокрутки может быть больше чем 32767. В хелпе на сообщение WM_VSCROLL советуют использовать функцию GetScrollPos, у меня че-то не получилось ее использовать. Как решить эту проблему?

Алексей Иванов 

A1 При работе с 32-битными значениями позиции бегунка значение nPos, передаваемое обработчику OnHScroll некорректно, для получения реального значения можно использовать ф-цию GetScrollPos, либо GetScrollInfo [возвращается в scrollinfo.nPos]. Однако, при обработке случая nSBCode==SB_THUMBTRACK, правильное значение текущей позиции возможно получить лишь при вызове GetScrollInfo(). Это значение будет возвращено в поле scrollinfo.nTrackPos;

Для работы с 32-битными значениями могут быть использованы следующие ф-ции: SetScrollPos, SetScrollRange, GetScrollPos, и GetScrollRange, SetScrollInfo, GetScrollInfo

Это все работает – лично проверял.

Bad Sector 

A2 Из вопроса не ясно, использует ли автор стили WS_HSCROLL и WS_VSCROLL или элемент управления scroll bar. Однако и в том, и в другом случае можно использовать одни и те же функции (SetScrollInfo/GetScrollInfo), чтобы управлять полосой прокрутки. Сначала (с помощью SetScrollInfo) для неё задаются 32-разрядные значения основных параметров (положения ползунка, диапазона изменения его положения и размера страницы). Затем в обработчике сообщений WS_HSCROLL и WS_VSCROLL можно использовать GetScrollInfo, чтобы получить значения всех этих параметров (опять же 32-разрядные!).

Допустим, окно имеет стиль WS_VSCROLL. Тогда в указанные функции нужно передавать HWND этого окна и константу SB_VERT (в случае с горизонтальной полосой прокрутки используется SB_HORZ). Например:

// Создаём окно и инициализируем scroll bar.

HWND hWnd = CreateWindow(…);

SCROLLINFO si;

si.cbSize = sizeof(si);

si.fMask = SIF_POS | SIF_RANGE | SIF_PAGE;

si.nMin = 0;

si.nMax = 100000; // больше, чем вмещает short!

si.nPos = 0;

si.nPage = 100;

SetScrollInfo(hWnd, SB_VERT, &si, TRUE);

LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam) {

 switch (message) { // Обрабатываем сообщение WM_VSCROLL.

 case WM_VSCROLL:

{

   SCROLLINFO si;

   si.cbSize = sizeof(si);

   si.fMask = SIF_PAGE | SIF_POS | SIF_RANGE | SIF_TRACKPOS;

   GetScrollInfo(hWnd, SB_VERT, &si);

   int pos = si.nPos;

   switch(LOWORD(wParam)) {

   case SB_LINEUP:

    pos--;

    break;

   case SB_LINEDOWN:

    pos++;

    break;

   case SB_PAGEUP:

    pos -= si.nPage;

    break;

   case SB_PAGEDOWN:

    pos += si.nPage;

    break;

   case SB_TOP:

    pos = si.nMin;

    break;

   case SB_BOTTOM:

    pos = si.nMax;

    break;

   case SB_THUMBPOSITION:

    pos = si.nTrackPos;

    break;

   }

   // Устанавливаем новое положение ползунка.

   SetScrollPos(hWnd, SB_VERT, pos, TRUE);

   break;

  }

 …

 }

 return DefWindowProc(hWnd, message, wParam, lParam);

}

В том случае, когда вместо стилей WS_xSCROLL используется элемент управления scroll bar, код выглядит совершенно аналогично, но функциям SetScrollInfo, GetScrollInfo и пр. передаётся HWND самой полосы прокрутки (а не владеющего ею окна), а в качестве второго параметра передаётся SB_CTL.

Александр Шаргин (rudankort@mail.ru)
В ПОИСКАХ ИСТИНЫ 

Q. Как сделать так, чтобы программа сама себя могла стереть, т.е. свой *.exe файл?

LowFeaR 

Это все на сегодня. Пока! 

Алекс Jenter jenter@mail.ru
Красноярск, 2001.

Программирование на Visual C++ Выпуск №32 от 11 февраля 2001 г.

Приветствую вас, уважаемые подписчики!

СТАТЬЯ Автоматизация и моторизация приложения Акт первый

Автор: Николай Куртов

Редактор журнала СофтТерра

Софт Терра: Технологии Microsoft для разработчиков

Интро

Неслучайно именно эта статья была выбрана мной для начала рубрики, посвященной технологиям Microsoft для разработчиков. Слова OLE и COM (Component Object Model) на устах программистов вот уже 5 лет, тем не менее, парадигма компонентного подхода остается базовым и неизменным моментом в создании приложений. Я помню, насколько широкие горизонты я для себя открыл, осознав идею объектного подхода – с тех пор строю свои программы из компонентов-кирпичиков, объединяя их в более абстрактные модели – сервисы. Программирование давно стало сплавом творчества и строительства, оставляя в прошлом сугубо научно-шаманскую окраску ремесла. И если такой переход уже сделан, то сейчас можно обозначить новый виток – ломание барьеров API и переход к более обобщенному подходу в проектировании, выход на новый уровень абстракции. Немало этому способствовал интернет и его грандиозное творение – XML. Сегодня ключ к успеху приложения сплавляется из способности его создателей обеспечить максимальную совместимость со стандартами и в то же время масштабируемость. Придумано такое количество различных технологий для связи приложений и повторного использования кода, что сегодня прикладные программы не могут жить без такой "поддержки". Под термином "автоматизация" я понимаю настоящее оживление приложений, придание им способности взаимодействовать с внешней средой, предоставление пользователю максимального эффекта в работе с приложениями. Не равняясь на такие гранды технической документации, как MSDN, я, тем не менее, этой статьей хочу указать на путь, по которому сегодня проектируются современные приложения.

Автоматизация как есть

Автоматизация (Automation) была изначально создана как способ для приложений (таких как Word или Excel) предоставлять свою функциональность другим приложениям, включая скрипт-языки. Основная идея заключалась в том, чтобы обеспечить наиболее удобный режим доступа к внутренним объектам, свойствам и методам приложения, не нуждаясь при этом в многочисленных "хедерах" и библиотеках.

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

Для начала обратим внимание на самое дно – интерфейсы COM. Если термин "интерфейс" в этом контексте вам ничего не говорит, то представьте себе абстрактный класс без реализации – это и есть интерфейс. Реальные объекты наследуются от интерфейсов. Компоненты, наследующиеся от интерфейса IUnknown, называются COM-объектами. Этот интерфейс содержит методы подсчета ссылок и получения других интерфейсов объекта.

Автоматизация базируется на интерфейсе IDispatch, наследующегося от IUnknown. IDispatch позволяет запускать методы и обращаться к свойствам вашего объекта через их символьные имена. Интерфейс имеет немного методов, которые являются тем не менее довольно сложными в реализации. К счастью, существует множество шаблонных классов, предлагающих функциональность интерфейса IDispatch, поэтому для создания объекта, готового к автоматизации, необходимо весего лишь несколько раз щелкнуть мышкой в ClassWizard Visual C++.

Что касается способа доступа и динамического создания ваших внутренних dispatch объектов, то тут тут тоже все довольно просто – данные об объекте хранятся в реестре под специальным кодовым именем, которое называется ProgId. Например, progid программы Excel – Excel.Application. Cоздать в любой процедуре на VBScript достаточно легко – надо только вызвать функцию CreateObject, в которую передать нужный ProgID. Функция вернет указатель на созданный объект.

А как оно в MFC

В MFC существует специальный класс, под названием CCmdTarget. Наследуя свои классы от cCmdtarget, вы можете обеспечить для них необходимую функциональность в dispatch виде – как раз как ее понимают скрипты. При созднании нового класса в ClassWizard (View>ClassWizard>Add Class>New), наследуемого от cСmdtarget, просто щелкните на кнопке Automation или Creatable by ID, чтобы обеспечить возможность создания экземпляра объекта по его ProgID. Замечу, что для программ, реализующих внутреннюю автоматизацию, это не нужно. Для приложений, реализующих внешнуюю и смешанную автоматизацию, это необходимо для "корневых" объектов.

После создания такого объекта, ClassWizard создает интерфейс ITestAutomatedClass (это dispatch интерфейс, т.е. наследуется от IDispatch), который реализуется моим CTestAutomatedClass. Теперь к этому интерфейсу я могу добавить методы или свойства, которые автоматически будут реализованы в CTestAutomatedClass. Я добавил свойство Age.

COM-объекты, коим и является наш CTestAutomatedClass, можно создавать только динамически. Это связано с тем, что объект может использоваться несколькими приложениями одновременно, а значит, удаление объекта из памяти не может выполнить ни одно из них. Разумно предположить, что объект сам должен отвечать за свое удаление. Такой механизм реализован при помощи механизма ссылок (reference count). Когда приложение получает указатель на объект, он увеличивает свой внутренний счетчик ссылок, а когда приложение освобождает объект – счетчик ссылок уменьшается. При достижении счетчиком нуля, объект удаляет сам себя. Если наш объект был создан по ProgID другим приложением, то программа CTestApp (другими словами, Automation-Server) не завершится до тех пор, пока счетчик ссылок CTestAutomatedClass не станет равным нулю.

Создаваемые через ProgID COM-объекты, обычно являются Proxy-компонентами. Реально они не содержат никакой функциональности, но имеют доступ к приложению и его внутренним, не доступным извне, функциям. Хотя можно организовать все таким образом, чтобы всегда создавался только один COM-объект, а все остальные вызовы на создание возвращали указатели на него.

Метод интерфейса CCmdTarget GetIDispatch(), позволяет получить указатель на реализованный интерфейс IDispatch. В параметрах можно указать, нужно ли увеличивать счетчик ссылок или нет.

В следующей статье, посвященной использованию функциональности WebBrowser Control, я обращусь к практическому применению dispatch-объектов программы в скриптах. А в дальнейшем, мы поговорим о внедрении процессора скриптов в собственные приложения.

ВОПРОС-ОТВЕТ 

Q. Как сделать так, чтобы программа сама себя могла стереть, т.е. свой *.exe файл?

LowFeaR 

A1 Удалить программу в тот момент, когда она запущена, не представляется возможным (во всяком случае такая возможность мне не знакома), остается удаление после завершения ее выполнения. Идея следующая: при выходе из программы создать BAT-файл, который ждет до тех пор, пока файл можно будет удалить (программа завершит работу), удаляет файл программы и себя, и запустить его:

void MyDlg::OnDestroy() {

 CDialog::OnDestroy();

 const char *AppName=AfxGetApp()->m_pszExeName;

 FILE *f=fopen("selfdel.bat","w+");

 fprintf(f, ":dc\n"

             "del %s.exe\n"

             "if exist %s.exe goto dc\n"

             "del selfdel.bat", AppName, AppName);

 fclose(f);

 WinExec("selfdel.bat",FALSE);

}

Преимущества:

-файл удаляется сразу в тот момент, когда это становится возможно

Недостатки:

-если запустить два экземпляра приложения, то после завершения работы первого мы получаем цикл активного ожидания до тех пор пока не завершится второй экземпляр (это незаметно в W95/98, но в NT в окне Task Manager можно заметить полную загрузку процессора). Также пользователь все это время будет удивляться наличию невесть откуда взявшегося файла sefdel.bat. 

Майкрософт же предлагает свой способ решения проблемы, причем его реализация отличается для WinNT и Win95/98. Удаление (переименование, замещение, и т.д.) файла происходит во время следующей перезагрузки системы. 

Win95/98: В процессе перезагрузки системы запускается утилита wininit.exe, которая осуществляет заданные действия над файлами, указанные в секции [rename] файла wininit.ini. При этом т.к. wininit.exe запускается еще до того как запущена система поддержки длинных имен файлов, все имена должны быть указаны в формате DOS (8.3). 

Последовательность действий для удаления или переименования файла:

1. Проверить наличие файла WININIT.INI в директории Windows

2. Если WININIT.INI существует, открываем его и добавляем новые строки в секцию [rename]. Если файла нет, создаем его и секцию [rename] в нем. 3.Добавляем строки следующего формата в секцию [rename]:

DestinationFileName=SourceFileName

Оба пути DestinationFileName и SourceFileName не должны содержать длинных имен. Приемник и источник должны находится на одном диске. Для удаления файла вместо DestinationFileName использовать NUL.

WinNT:

Здесь все сделано по-человечески. Для удаления файла следует использовать функцию MoveFileEx():

MoveFileEx(szSrcFile, NULL, MOVEFILE_DELAY_UNTIL_REBOOT);

где szSrcFile – имя файла или директории

Преимущества:

-"Лицензированный" метод Майкрософт

Недостатки:

-Чрезмерно утяжеленная процедура редактирования wininit.ini, проблемы при работе с длинными именами Win95/98,

-Удаление происходит только в момент перезагрузки.

Bad Sector 

A2 Программа не может удалить свой exe-файл, пока она работает. Это фундаментальное правило при работе под Windows. Поэтому всё, что остаётся – это поручить удаление другому процессу перед тем как завершить свой. 

Самый простой вариант – создать на лету и запустить bat-файл, который дождётся завершения нашего процесса, а затем удалит его exe-файл. Более сложные варианты подразумевают создание в чужом процессе (например, в Task Manager) рабочего потока, который опять же дождётся завершения нашего процесса и убьёт файл. 

Вот пример функции, которая создаёт bat-файл и запускает его, чтобы убить наш exe-файл. Лучше всего вызывать её непосредственно перед завершением нашего процесса. 

void DelSelf() {

 // Получаем свой путь

 char szExePath[MAX_PATH];

 GetModuleFileName(NULL, szExePath, MAX_PATH);

 // Создаём bat-файл

 static char szBat[] = ":Loop\r\n"

  "del %1\r\n"

  "if exist %1 goto Loop\r\n"

  "del %0";

 HANDLE hFile = CreateFile("__delself.bat", GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, 0, 0);

 DWORD temp;

 WriteFile(hFile, (LPVOID)szBat, strlen(szBat), &temp, NULL);

 CloseHandle(hFile);

 // Запускаем его

 STARTUPINFO si;

 ZeroMemory(&si, sizeof(si));

 si.cb = sizeof(si);

 si.wShowWindow = SW_HIDE;

 si.dwFlags = STARTF_USESHOWWINDOW;

 PROCESS_INFORMATION pi;

 char szCommand[MAX_PATH+15] = "__delself.bat ";

 strcat(szCommand, szExePath);

 CreateProcess(NULL, szCommand, NULL, NULL, FALSE, DETACHED_PROCESS, NULL, NULL, &si, &pi);

 return;

}

 Замечу, что это только пример, который можно улучшать в различных направлениях. Можно, скажем, получать имя bat-файла через GetTempFileName, чтобы гарантировать его уникальность. Или понизить приоритет создаваемого из bat-файла процесса до минимума, чтобы он кушал поменьше ресурсов в процессе циклической проверки существования exe-файла.

Александр Шаргин (rudankort@mail.ru
В ПОИСКАХ ИСТИНЫ 

Q. Есть у меня файлы с расширением .pdb (Microsoft C/C++ program database 2.00) (их MS VC++ делает, в папке Debug проекта создаются), можно ли с их помощью восстановить исходники программы (размер у них такой, что туда не только прога влезет, но и комментарии к ней в HTML (FrontPage Style) формате :)

 Andrey Shtukaturov 

Пока все. До скорого! 

Алекс Jenter jenter@mail.ru
Красноярск, 2001.

Программирование на Visual C++ Выпуск №33 от 18 февраля 2001 г.

Приветствую!

Сегодня хочу предложить вашему вниманию заключительную часть статьи про ODBC нашего постоянного автора Александра Шаргина, которая, если вы помните, открывает цикл статей о технологиях доступа к данным.

СТАТЬЯ Доступ к БД с использованием ODBC Часть 2

Автор: Александр Шаргин 

В предыдущей части статьи мы с вами рассмотрели основы использования ODBC для доступа к базам данных. Но в процессе знакомства с этой технологией у каждого естественным образом возникает целый ряд вопросов. Ответам на самые распространённые из них и будет посвящена вторая часть статьи. 

Перемещение на другие компьютеры

При переносе программы, использующей ODBC, на другой компьютер возникает целый ряд проблем. Во-первых, на нём может не оказаться нужных компонентов ODBC, а значит, их необходимо распространять вместе с программой. Во-вторых, на другом компьютере придётся заново регистрировать источник данных, причём желательно, чтобы пользователь об этом не знал. В этом разделе я расскажу, как всё это делается. 

Необходимые компоненты

Сразу замечу, что некоторые приложения изначально разрабатываются для работы с произвольными БД. К таким приложениям относятся пакеты статистической обработки данных или электронные таблицы, способные импортировать данные из выбранной пользователем БД. Другой характерный пример – среда Visual C++. Если вы разрабатываете подобное приложение, можете смело пропустить этот раздел. Установка компонентов, необходимых для работы с конкретной базой данных – не ваша забота. Любому приложения, использующему ODBC, необходимы основные компоненты ODBC (core components) и ODBC-драйвер. К основным компонентам относятся менеджер драйверов (ODBC32.DLL), библиотека инсталлятора (ODBCCP32.DLL), библиотека курсоров (ODBCCR32.DLL) и администратор источников данных (ODBCAD32.EXE), а также несколько вспомогательных файлов. Драйвер состоит из двух DLL: библиотеки драйвера (driver DLL) и библиотеки настройки (setup DLL). Библиотека драйвера экспортирует все необходимые функции ODBC API, а библиотека настройки – функции ConfigDriver и ConfigDSN, используемые для конфигурирования самого драйвера и связанных с ним источников данных. Иногда обе библиотеки объединяют в одной DLL. Основные компоненты сейчас установлены практически на каждом компьютере, поэтому об их инсталляции я рассказывать не буду. Тем, кого интересует этот вопрос, советую обратиться к описанию функции SQLInstallDriverManager. Драйвер для каждой конкретной СУБД обычно распространяется со своей программой инсталляции. В этом случае вам нужно просто включить её в комплект поставки. Но предположим, что такая программа недоступна. Тогда можно воспользоваться функцией SQLInstallDriverEx, входящей в библиотеку инсталляции. Эта функция вызывается дважды: первый раз, чтобы определить целевую папку для драйвера, а второй раз, чтобы добавить необходимые записи в реестр. Копирование осуществляет вызывающая программа. Предположим, что драйвер "My Driver" состоит из файлов MYDRV.DLL и MYSETUP.DLL. Установку этого драйвера выполнит следующий код. 

#include <windows.h>

#include <odbcinst.h>

#include <stdio.h> :


char szPathIn[301];

char szPathOut[301];

DWORD dwUsageCount;

int i, j;

char szDriver[300] = "My Driver\0Driver=MYDRV.DLL\0Setup=MYSETUP.DLL\0";

SQLInstallDriverEx(szDriver, NULL, szPathIn, 300, NULL, ODBC_INSTALL_INQUIRY, &dwUsageCount);

// Копируем файлы в папку szPathIn.

sprintf(szDriver, "My Driver;Driver=%s\\%s;Setup=%s\\%s;", szPathIn, "MYDRV.DLL", szPathIn, "MYSETUP.DLL");

for (i = strlen(szDriver), j = 0; j < 0; j++) {

 if (szDriver[j] == ';') szDriver[j] = '\0';

}

SQLInstallDriverEx(szDriver, szPathIn, szPathOut, 300, NULL, ODBC_INSTALL_COMPLETE, &dwUsageCount);

Если в дальнейшем вам потребуется удалить установленный таким образом драйвер, сделать это можно так.

DWORD dwUsageCount;

SQLRemoveDriver("My Driver", TRUE, &dwUsageCount); 

Как и в случае с SQLInstallDriverEx, физическое удаление файлов остаётся на вашей совести. Удалять файл следует только если счётчики использования как компонента, так и самого файла равны нулю. 

За подробностями об установке компонентов ODBC следует обратиться к главам 18 и 23 из ODBC Programmer's Reference. 

Программная регистрация источника данных

Для программной регистрации источника данных используется функция SQLConfigDataSource. Вызывайте её с ключом ODBC_ADD_DSN, чтобы создать пользовательский источник данных, или с ключом ODBC_ADD_SYS_DSN для создания системного источника данных. 

Примечание: системный источник данных отличается от пользовательского тем, что он доступен всем пользователям компьютера, в то время как пользовательский доступен только создавшему его пользователю. Соответственно, информация о системных источниках данных хранится в реестре в разделе HKEY_LOCAL_MACHINE, а о пользовательских – в разделе HKEY_CURRENT_USER. 

Функция SQLConfigDataSource получает имя драйвера, а также набор параметров, описывающих создаваемый источник данных. Состав этих параметров изменяется от драйвера к драйверу. Например, драйверу MS Access нужно сообщить, по крайней мере, имя источника данных (DSN) и имя файла БД (DBQ). Вот как выглядит создание источника данных dbFolks для БД: 

SQLConfigDataSource(NULL, ODBC_ADD_DSN, "Microsoft Access Driver (*.mdb)", "DSN=dbFolks\0DBQ=c:\\folks.mdb"); 

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

Как обойтись без источника данных

Хотя источники данных являются удобной абстракцией, иногда хочется обойтись без них. Как это сделать? ODBC не предоставляет стандартной возможности подключаться напрямую к БД. Как мы помним, стандарт определяет только четыре параметра (DSN, UID, PWD и DRIVER) для строки подключения, передаваемой в CDatabase::OpenEx. Среди них нет параметра, в который можно было бы записать имя конкретной БД. Тем не менее, стандарт не запрещает драйверам ODBC распознавать и другие параметры. Используя их, вы жертвуете универсальностью вашей программы, но взамен получаете доступ к дополнительным возможностям драйвера. 

В частности, многие драйверы от Microsoft используют параметр DBQ для задания имени файла БД. Вот как можно подключиться к БД , не создавая для неё источника данных. 

CDatabase Db;

Db.OpenEx("DRIVER={Microsoft Access Driver (*.mdb)};DBQ=f:\\folks.mdb", CDatabase::noOdbcDialog); 

Точно так же можно подключиться к БД, управляемой MS SQL Server, используя параметры SERVER и DATABASE. Вот пример подключения к демонстрационной БД , поставляемой вместе с SQL Server. 

CDatabase Db;

Db.OpenEx("DRIVER={SQL Server};SERVER=(local);DATABASE=pubs;UID=sa;PWD=", CDatabase::noOdbcDialog); 

Описание дополнительных параметров следует искать в документации на каждый конкретный драйвер. В частности, информация о драйверах фирмы Microsoft содержится в MSDN. 

Начинаем с нуля

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

Создание БД

Хотя в ODBC нет стандартных средств для создания новых баз данных, некоторые драйвера предоставляют такую возможность. Например, драйвер MS Access распознаёт дополнительные параметры для уже знакомой нам функции SQLConfigDataSource. Один из них, CREATE_DB, как раз и служит для создания новых баз данных. Для примера рассмотрим создание БД. 

SQLConfigDataSource(NULL, ODBC_ADD_DSN, "Microsoft Access Driver (*.mdb)", "CREATE_DB=c:\\folks.mdb"); 

Обратите внимание, что никакого источника данных в этом случае не создаётся, хотя мы и обращаемся к SQLConfigDataSource.

В некоторых случаях драйвер не поддерживает создания БД, но в диалекте SQL соответствующей СУБД есть необходимые для этого конструкции. В этом случае можно использовать функцию CDatabase::ExecuteSQL для выполнения требуемых операторов языка SQL. Для примера рассмотрим, как создаётся новая база данных в SQL Server.

Db.OpenEx("DRIVER={SQL Server};SERVER=(local);UID=sa;PWD=", CDatabase::noOdbcDialog);

Db.ExecuteSQL("CREATE DATABASE MyDB"); 

Если ни один из перечисленных способов создания БД вам не доступен, всё, что вам остаётся – это распространять вместе с вашей программой пустую БД и копировать её каждый раз, когда требуется создать новую базу данных. 

Создание таблиц

Для создания таблиц в БД используется SQL-оператор CREATE TABLE, который выполняется с помощью функции CDatabase::ExecuteSQL. В простейшем случае CREATE TABLE имеет следующий формат. 

CREATE TABLE table_name (

 {column_name column_type} [,:n]

)

Полное описание формата CREATE TABLE для каждой конкретной СУБД можно найти в документации. Рассмотрим пример создания таблицы tPeople, содержащей поля Name (строка из 50 символов) и DateOfBirth (дата). Запрос будет выглядеть так. 

Db.ExecuteSQL("CREATE TABLE tPeople (Name char(50), DateOfBirth datetime)");

Модификация полей (столбцов)

Иногда приходится не создавать таблицу с нуля, а модифицировать уже существующую. Не останавливаясь на подробностях, скажу, что для этого используется SQL-оператор ALTER TABLE, с помощью которого можно как добавлять в таблицу новые поля, так и изменять или удалять существующие. 

Рассмотрим несколько примеров. Сначала добавим в таблицу tPeople поле DateOfDeath (дата). 

Db.ExecuteSQL("ALTER TABLE tPeople ADD DateOfDeath datetime"); 

Теперь изменим ширину поля Name (с 50 до 100 символов). 

Db.ExecuteSQL("ALTER TABLE tPeople ALTER COLUMN Name char(100)"); 

А теперь удалим только что созданное поле DateOfDeath: 

Db.ExecuteSQL("ALTER TABLE tPeople DROP COLUMN DateOfDeath"); 

В заключение замечу, что SQL предоставляет вам практически неограниченные возможности по манипулированию БД. Если вам не удаётся найти функции ODBC, выполняющей требуемое действие, попробуйте найти подходящий SQL-оператор и выполнить его с помощью CDatabase::ExecuteSQL. 

Работа в незнакомой обстановке

Как я уже говорил, иногда на этапе разработки приложения точно не известно, с какой базой данных ему предстоит работать. В таком случае вам понадобятся средства для поиска доступных источников данных, а также для динамического определения структуры БД. 

В ODBC есть целый набор похожих функций, предназначенных для получения списка доступных драйверов и источников данных, таблиц в БД и столбцов в таблице. Они называются SQLDrivers, SQLDataSources, SQLTables и SQLColumns соответственно. Обратите внимание, что это функции ODBC API, для которых не существует обёртки в MFC. 

Кроме того, в класс CRecordset встроены функции GetODBCFieldCount и GetODBCFieldInfo. Первая возвращает количество полей (столбцов) в наборе записей, а вторая заполняет структуру CODBCFieldInfo информацией о заданном поле. 

Хранимые процедуры

Хранимая процедура – это сценарий на языке SQL, который вызывается клиентом для выполнения некоторых операций и работает на стороне сервера. Хранимые процедуры могут получать входные параметры, а также сообщать о результатах своей работы, возвращая наборы записей или записывая некоторые значения в выходные параметры. Работе с хранимыми процедурами и посвящён данный раздел. 

Вызов процедур

Хранимая процедура вызывается при помощи SQL-оператора CALL. Обратите внимание, что использование этого оператора является обязательным требованием к ODBC-программе, даже если СУБД поддерживает другой оператор вызова процедур (например, EXEC[UTE] в SQL Server). 

Выполнение оператора CALL осуществляется с помощью функции CDatabase::ExecuteSQL. Сам оператор заключается в фигурные скобки. Рассмотрим пример вызова процедуры spClear, не требующей параметров (она очищает таблицу tPeople, выполняя оператор DELETE * FROM tPeople). 

Db.ExecuteSQL("{CALL spClear}"); 

Вызов процедур с параметрами

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

Модифицируем хранимую процедуру из предыдущего примера так, чтобы она принимала параметр paramName и удаляла из таблицы tPeople только людей с заданным именем (то есть выполняла оператор DELETE * FROM tPeople WHERE Name=paramName). Теперь мы можем удалить из таблицы всех Александров, выполнив: 

Db.ExecuteSQL("{CALL spClear('Alexander')}"); 

Это наиболее простой способ, но он имеет ряд ограничений. В частности, невозможно получить доступ к выходным параметрам функции. Чтобы снять эти ограничения, необходимо связать нужные нам параметры с переменными. Связывание производится в функции CDatabase::BindParameter, которую для этой цели нужно перегрузить. Это, в свою очередь, означает, что нам придётся порождать новый класс от CDatabase. Для связывания каждого параметра с переменной используется функция SQLBindParameters из ODBC API. Вместо каждого связанного с переменной параметра в вызов процедуры вставляется вопросительный знак.

Рассмотрим пример вызова хранимой процедуры spCount, которая возвращает количество людей с заданным именем в таблице tPeople. В СУБД SQL Server такую процедуру можно создать, выполнив запрос: 

CREATE PROC spCount(@paramName CHAR(50), @paramCount INT OUTPUT) 

AS SELECT @paramCount = COUNT(*) FROM tPeople WHERE Name=@paramName

Теперь, чтобы посчитать количество Александров, необходимо написать следующий код. 

// Порождаем новый класс от CDatabase

class CMyDatabase : public CDatabase {

public:

 char m_paramName[50];

 int m_paramCount;

 void BindParameters(HSTMT);

};


void CMyDatabase::BindParameters(HSTMT hStmt) {

 SQLBindParameter(  // Связываем @paramName с m_paramName

  hStmt, 1, SQL_PARAM_INPUT, SQL_C_CHAR,

  SQL_CHAR, 50, 0, m_paramName, 50, NULL);

 SQLBindParameter( // Связываем @paramCount с m_paramCount

  hStmt, 2, SQL_PARAM_OUTPUT, SQL_C_SLONG,

  SQL_INTEGER, 0, 4, &m_paramCount, 4, NULL);

}

:


CMyDatabase Db;


Db.OpenEx(

 "DRIVER={SQL Server};SERVER=(local);DATABASE=tPeople;UID=sa;PWD=",

 CDatabase::noOdbcDialog);

strcpy(Db.m_paramName, "Alexander");

Db.ExecuteSQL("{CALL spCount(?,?)}");

// Db.m_paramCount содержит результат!

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

Вызов процедур, возвращающих наборы записей

Процедуры, возвращающие наборы записей, также вызываются с помощью оператора CALL, но в функции CRecordset::Open. Соответственно, полученное множество записей будет связано с объектом класса CRecordset. Если у хранимой процедуры есть параметры, можно передать их напрямую или связать с ними переменные. Связывание переменных, в отличие от предыдущего случая, происходит в функции CRecordset::DoFieldExchange при помощи макросов RFX_* (то есть практически ни чем не отличается от связывания переменных с полями результирующего набора записей). Нужно только вызвать CFieldExchange::SetFieldType с параметром CFieldExchange::inputParam, чтобы сообщить MFC, что мы связываем параметры, а не поля. Важно также записать количество связываемых параметров в переменную CRecordset::m_nParams. Обычно это делается в конструкторе класса. 

Рассмотрим пример вызова хранимой процедуры spGetByName, которая находит в таблице tPeople всех людей с заданным именем. В СУБД SQL Server такую процедуру можно создать, выполнив запрос: 

CREATE PROC spGetByName(@paramName CHAR(50))

AS SELECT * FROM tPeople WHERE Name=@paramName 

Построить набор записей, в который входят все Александры из таблицы, теперь можно так (напоминаю, что нам придётся порождать новый класс от CRecordset). 

class CPeople : public CRecordset {

public:

 CPeople(CDatabase *pDatabase = NULL) : CRecordset(pDatabase) {

  m_nFields = 2, m_nParams = 1;

 };

 CString m_Name;

 Time m_DateOfBirth;

 String m_paramName;

 void DoFieldExchange(CFieldExchange *pFX);

};


void CPeople::DoFieldExchange(CFieldExchange *pFX) {

 pFX->SetFieldType(CFieldExchange::outputColumn);

 RFX_Text(pFX, "Name", m_Name, 50);

 RFX_Date(pFX, "DateOfBirth", m_DateOfBirth);

 pFX->SetFieldType(CFieldExchange::inputParam);

 RFX_Text(pFX, "paramName", m_paramName);

}

:

CPeople Rs(&Db);

Rs.m_paramName = "Alexander";

Rs.Open(CRecordset::snapshot, "{CALL spGetByName(?)}");

О чём ещё полезно знать

В заключительном разделе я рассмотрю несколько не связанных между собою тем, знакомство с которыми может оказаться полезным. 

Транзакции

Транзакция – это блок команд, которые выполняются как единое целое. Другими словами, они либо выполняются все, либо не выполняется ни одна. Транзакция начинается вызовом CDatabase::BeginTrans и завершается вызовом CDatabase::CommitTrans. Все операции по изменению, добавлению и удалению данных вступят в силу только после вызова CommitTrans, причём в любой момент до вызова этой функции транзакцию можно полностью отменить, вызвав функцию CDatabase::Rollback. Используйте CDatabase::CanTransact, чтобы определить, поддерживает ли используемый вами драйвер транзакции.

CRecordset и его потомки

В первой части статьи мы рассмотрели, как использовать CRecordset, порождая от него новые классы. Возникает вопрос: а можно ли использовать этот класс напрямую? Ответ на этот вопрос звучит так: CRecordset может использоваться для доступа к множеству записей, построенному только на основе запроса (а не имени таблицы), и только в режиме read only. Обратиться к значениям конкретных полей в этом случае можно, используя функцию CRecordset::GetFieldValue. Функции CRecordset::Move* используются, как и раньше.

Следующий фрагмент выводит фамилии всех авторов из БД pubs. Так как нам требуется доступ к таблице authors в режиме , мы можем использовать класс CRecordset напрямую.

CRecordset Rs(&Db);

Rs.Open(CRecordset::forwardOnly, "SELECT aau_lname FROM authors");

while (!Rs.IsEOF()) {

 CString lname;

 Rs.GetFieldValue((short)0, lname);

 printf ("%s\n", lname);

 Rs.MoveNext();

}

Как обмануть IntelliSense

Мы уже умеем конструировать объекты класса CRecordset, передавая конструктору указатель на соединение: 

CRecordset Rs(&Db); 

Существует ещё одна эквивалентная форма создания объекта CRecordset: 

CRecordset Rs;

Rs.m_pDatabase = &Db;

Зачем она может понадобиться, спросите вы. Дело в том, что система Microsoft IntelliSense, которая услужливо выдаёт вам списки членов класса и параметров функции прямо, очень болезненно реагирует на конструкторы с параметром: в коде, который следует за вызовом такого конструктора, подсказки попросту перестают появляться. Если вы столкнулись с такой проблемой, смело используйте второй вариант конструирования объекта CRecordset. 

Любые замечания по форме и содержанию статьи вы можете прислать мне по адресу rudankort@mail.ru.

ВОПРОС-ОТВЕТ 

Q. Есть у меня файлы с расширением .pdb (Microsoft C/C++ program database 2.00) (их MS VC++ делает в папке Debug проекта создаются), можно ли с их помощью восстановить исходники программы (размер у них такой, что туда не только прога влезет, но и комментарии к ней в HTML (FrontPage Style) формате :)

Andrey Shtukaturov 

A. Восстановить исходники не удастся, так как их там нет. Зато есть имена классов и глобальных переменных.

Этого вполне достаточно для того чтобы восстановить недокументированный интерфейс COM-объекта.

Дело в том, что согласно реализации COM'а для C++, имена функций членов класса реализующиго интерфейс должны полностью совпадать с именами исходного интерфейса. Плюс свои какие-то матоды. Обычно они не виртуальные так что легко отсекаются.

В .pdb файлах лежат vftable для базовых интерфейсов, так что можно восстановить всю иерархию интерфейсов. И гадать в каком порядке методы в интерфейсе не придется

И собственные методы класса реализующего интерфейс тоже отсекаются.

Для не COM-объектов .pdb файлы тоже могут быть полезны.

Если, например, в перечне экспортируемых из ImgUtil.dll функций содержится скупое "DecodeImage", то в .pdb файле честно написано, что это "_DecodeImage@12", т.е. уже извесно количество параметров. Это для функций описанных как extern "C". Для функций C++ в .pdb файле будет полное задекорированное имя.

Типа "?DecodeImage@@YAJPAVISniffStream@@PAVIMapMIMEToCLSID@@PAVIImageDecodeEventSink@@@Z"

Что после пропускания через утилиту UndName из набора утилит поставляемого MS с PlatformSDK выглядит как "long cdecl DecodeImage(class ISniffStream *, class IMapMIMEToCLSID *, class IImageDecodeEventSink *)".

Более чем достаточно для восстановления не целиком исходников, но хоть декларации функций.

Paul Bludov 
В ПОИСКАХ ИСТИНЫ 

Q. Насколько корректно будут работать методы контроля утечек памяти (в частности объект CMemoryState) в многопоточных приложениях? 

У меня сложилось впечатление, что объект CMemoryState не делает различия в каком потоке вызывались операторы new с момента обращения к memState.Checkpoint() до обращения к memState.DumpAllObjectsSince(). 

Видимо "моментальные снимки" распределённой памяти в данном случае не информативны, ведь несколько потоков работают в одном адресном пространстве?

Николай Турпитко 

Это все на сегодня. Успехов! 

Алекс Jenter jenter@mail.ru
Красноярск, 2001.

Программирование на Visual C++ Выпуск №34 от 25 февраля 2001 г.

Добрый день, уважаемые подписчики!

Многие из вас в своих письмах спрашивали о том, как можно включить функциональность Internet Explorer в свои приложения. На этот вопрос призвана ответить вторая часть статьи Николая Куртова, первая часть которой была опубликована в выпуске №32.

СТАТЬЯ Автоматизация и моторизация приложения Акт второй

Автор: Николай Куртов

Редактор журнала СофтТерра

Софт Терра: Технологии Microsoft для разработчиков

Интро

Помните, какой революцией был Windows 95, с его новыми элементами: list view, tree view, sliders, tabs ? Радикально отличаясь от своего предшественника, он представлял дизайнерам пользовательского интерфейса новые гибкие возможности. Сегодня требования к программному обеспечению растут, информации становится больше, информация становится разнообразнее. Теперь, древовидными списками с закладками не обойтись. И вот, выходит Windows 98, где папки можно просматривать в режиме web, работая с наглядной информации. Круговая диаграмма, дополнительная информация о папке, Outlook today – все это на самом деле реализовано в HTML, а еще точнее, в DHTML (т.е. Dynamic HTML, оживший, при помощи скриптов, HTML). Все help системы Windows 98/2000 уже представлены в HTML виде.

Зачастую оказывается, что web-интерфейсы значительно дружественнее, чем обычные диалоговые окна, ведь они ориентированы больше на документ, нежели на приложение. Да и разработчику они обходятся дешевле, чем поддержание многозакладочных информационных диалогов. Дизайн приложений в стиле Web предлагает множество преимуществ, такие как богатая визуализация и концепция навигации через гиперссылки. Хорошо сконструированный пользовательский интерфейс не только приносит эстетическое удовлетворение, но и является ключом к успеху всего приложения.. И все это вызывает энтузиазм, до тех пор, пока дело не доходит до реализации. Красота дело тонкое, потому сегодня я попытаюсь рассказать о некоторых аспектах реализации web-интерфейсов. […]

Как это работает

Internet Explorer (c версии 4.0 и позже) предоставляет технологии, при помощи которых программисты могут встраивать всю функциональность браузера в свои приложения. Эти технологии реализуются в ActiveX компонентах, как визуальных так и невидимых. Основной компонент, представляющий элемент web-browser control, содержится в библиотеке shdocvw.dll, использующей средства парсинга и рендринга HTML кода, а также выполнение DHTML скриптов от другого компонента – mshtml.dll. По сути, web-browser control является обычным ActiveX компонентом, с множеством стандартных свойств. Тем не менее, каждая загруженная страничка внутри такого элемента представляется в виде объектной модели документа HTML. Это значит, что любой элемент HTML, такой как параграф или ячейка таблицы, доступен разработчику в виде COM-объекта, со множеством свойств и методов.

По-правде говоря, библиотеки shdocvw.dll, а особенно mshtml.dll не такие уж и легковесные относительно памяти. Тем не менее следует учитывать, что обычно webbrowser control подгружается системой на запуске, а все повторные запросы на загрузку этих библиотек перенаправляются на уже загруженные ранее модули. Таким образом использование webbrowser control не влечет чрезмерного расходования системных ресурсов, если конечно, ваш html документ не имеет сверхсложной структуры и гигантстких размеров.

Internet Explorer версии 5.5 предоставляет поистине громадное количество новых возможностей для разработчика, что позволяет создавать мультимедийные системы на основе браузера. Подробное описание нововведений можно найти в последних выпусках MSDN.

Web browser control

Прежде, чем приступать к реализации, отмечу, что буду использовать в примерах классы MFC. Естественно, существует множество путей для внедрения web-компонента в приложения на Visual Basic, C++ ATL или Delphi. Я надеюсь, пользователи этих средств, найдут эту статью столь же полезной, сколь и пользователи MFC.

Вставка компонента

Использовать компонент можно "напрямую", вставляя OLE-объект на форму, или косвенно, через вызов к CWnd::CreateControl. Важным фактом является наличие уже созданной обертки для webbrowser в MFC, реализованной в классе CHTMLView. При создании приложений по схеме В, я рекомендую пользоваться именно им. Встроенные визарды Visual Studio уже содержат все средства для начальной генерации таких приложений. Ежели все-таки душе роднее тернистый путь, то внедрение компонента будет выглядит следующим образом:

CRect rectClient(10,10,200,200);

CWnd m_wndBrowser;

CComQIPtr<IWebBrowser2, &IID_IWebBrowser2> m_pBrowserApp;

if (!m_wndBrowser.CreateControl(CLSID_WebBrowser, _T("Window"), WS_VISIBLE | WS_CHILD, rectClient, this, AFX_IDW_PANE_FIRST)) {

 DestroyWindow();

}

if (m_pBrowserApp = m_wndBrowser.GetControlUnknown()) {

 CComBSTR bstrURL = _T("http://www.microsoft.com");

 m_pBrowserApp->Navigate(bstrURL, NULL, NULL, NULL, NULL);

}

Замечу, что CLSID_WebBrowser — идентификатор объекта webbrowser, описанный в файле comdef.h. Этот файл имеет ключевое значение, поскольку в нем отражены идентификаторы основных интерфейсов объектной модели Windows, в частности WebBrowser и объектной модели HTML. Для большинства элементов объявлены smart-pointers, что особенно актуально для работы с DHTML из приложения, где просто море различных интерфейсов. Помимо стандартных для ActiveX элементов интерфейса, webbrowser компонент экспортирует также два собственных интерфейса:

• IWebBrowser2. Этот интерфейс реализует управление элементом: внешним видом, параметрами, а также позволяет производить навигацию.

• DWebBrowserEvents2. Объект webbrowser использует события для уведомления приложения о состоянии компонента. Например, перед навигацией на новый URL, вызывается событие BeforeNavigate2.

Описание этих интерфейсов exdisp.h/exdispid.h. Оглядываясь на практический опыт, замечу, что ссылки на все описанные файлы лучше прописывать в stdafx.h.

Подключение событий

Механизм подключения событий через точки соединения стандартный, поэтому не имеет смысла его здесь описывать. Тем более, что MFC предоставляет более удобный способ для отлова событий webbrowser через DECLARE_EVENTSINK_MAP макрос.

Запишем в заголовочном файле класса, содержащего webbrowser control:

// Web browser event sink

DECLARE_EVENTSINK_MAP()

virtual void OnDownloadComplete();

virtual void DocumentComplete(LPDISPATCH pDisp, VARIANT* URL);

А в .cpp файле добавим строки:

BEGIN_EVENTSINK_MAP(CChatChannelDialog, CDialog)

 ON_EVENT(CChatChannelDialog, AFX_IDW_PANE_FIRST, DISPID_NAVIGATECOMPLETE, OnDownloadComplete, VTS_NONE)

 ON_EVENT(CChatChannelDialog, AFX_IDW_PANE_FIRST, DISPID_DOCUMENTCOMPLETE, DocumentComplete, VTS_DISPATCH, VTS_PVARIANT)

END_EVENTSINK_MAP()

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

Модель объектов DHTML

Интерфейс DWebBrowserEvents2 при помощи события DISPID_NAVIGATECOMPLETE позволяет определить тот момент, когда HTML документ полностью сгенерирован внутри webbrowser control. После того, как это происходит, весь HTML документ доступен через функцию IWebBrowser2::get_Document. Также, как и webbrowser control, HTML документ поддерживает события, такие как click, mouseover. Для того, чтобы использовать объектную модель DHTML, нужно подключить заголовок mshtml.h.

CComQIPtr<IHTMLDocument2, &IID_IHTMLDocument2> pADocument;

IDispatch* pdispTmpVal;

m_pBrowserApp->get_Document(&pdispTmpVal);

pADocument = pdispTmpVal;

pdispTmpVal->Release();

Интерфейс IHTMLDocument2 предоставляет возможность получать и модифицировать содержимое документа. Вы можете использовать множество методов, таких как get_body, get_all, get_activeElement чтобы извлекать элементы или коллекции элементов внутри документа. Базовой основой для любого тэга внутри HTML-документа является интерфейс IHTMLElement. Меняя содержимое тэга при помощи свойств innerHTML и outerHTML мы реализуем принцип динамического содержания, который нами и преследовался. К любому элементу можно адресоваться при помощи идентификатора id через вызов IHTMLElementCollection::Item. Итак, c визуализацией ясно, а как же теперь обеспечить интерактивность? Как избавиться от ненужных клавишных комбинаций и меню? Как получить доступ из скриптов к внутренней модели объектов нашей программы?

Расширение объектной модели DHTML

Компания Microsoft предоставила возможность расширения объектной модели через механизм window.external. Приложение, использующее web-browser control может реализовывать собственную логику через переопределение объекта external. Естественно, чтобы иметь возможноть работать со своим приложением из скрипта, программа должна реализовывать dispatch-интерфейсы. При помощи ClassWizard, добавить поддержку автоматизации к своим объектам не составляет труда. Единственным замечанием здесь может служить лишь то, что объекты должны наследоваться от CCmdTarget. Чтобы передать указатель на свой объект самому объекту webbrowser, а заодно установить целую кучу дополнительных параметров, необходимо реализовать cлужебный интерфейс IDocHostUIHandler, который описан в mshtmhst.h. Этот интерфейс представляет собой некий call-back, или интерфейс обратной связи, к которому обращается webbrowser в следующих случаях:

• Необходимо показать контекстное меню. Как раз здесь можно заменить стандартное меню Internet-explorer на свое собственное. Либо вообще сделать так, чтобы меню не показывалось.

• Есть возможность подменить элементы пользовательского интерфейса браузера.

• Нужно обработать нажатие горячей клавиши.

• Нужно обработать URL, по которому совершается переход.

• Нужно обработать события drag-and-drop.

• Необходимо получить указатель на объект window.external.

После реализации этого call-back объекта, его можно "инсталлировать", используя метод интерфейса ICustomDoc SetUIHandler. Интерфейс IСustomDoc экспортируется обычно реализуется тем же объектом, что реализует IHTMLDocument2.

// код из OnNavigateComplete

CComQIPtr<ICustomDoc, &IID_ICustomDoc> m_pBrowserCustomDoc;

CComQIPtr<IHTMLDocument2, &IID_IHTMLDocument2> pADocument;

CDocHostUIHandler m_DocHostImpl;

m_DocHostImpl.AddRef();

m_DocHostImpl.m_pAppDisp = m_pApp->GetIDispatch(FALSE);

m_pBrowserCustomDoc = pADocument;

m_pBrowserCustomDoc->SetUIHandler((IDocHostUIHandler*)&m_DocHostImpl);

В данном коде фигурирует класс CDocHostUIHandler, который реализует все методы интерфейса IDocHostUIHandler (и конечно же AddRef, QueryInterface и Release от IUnknown). В базовом варианте, реализация этого объекта сводится лишь к созданию процедур-заглушек для каждого метода IDocHostUIHandler, возвращающих E_NOTIMPL. А если хочется, чтобы Internet Explorer не показывал своего конекстного меню, нужно возвращать из метода ShowContextMenu S_OK.

Если наш объект CDocHostUIHandler возвращает указатель в методе get_External, то этот указатель и используется как объект расширения и тогда где-нибудь внутри самой html странички можно будет написать такие строки:

<script language="JavaScript">

function ShowSettingsDialog() {

 if (window.external.ShowSettings() == true) {

  document.body.bgcolor = window.external.BackColor;

 }

}

</script>

<body>

<a href="javascript:ShowSettingsDialog()">Settings</a>

</body>

В приведенном примере, функция ShowSettings и свойство BackColor запрашиваются из недр нашего собственного приложения.

Где хранить свои HTML

В ресурсах! К счастью, Internet explorer умеет грузить из ресурсов, нужно только в качестве префикса URL написать res://<путь к модулю>/<название ресурса>. Я привожу реализацию этого метода, выдранную из исходного текста CHTMLView.

HINSTANCE hInstance = AfxGetResourceHandle();

CString strResourceURL;

BOOL bRetVal = TRUE;

LPTSTR lpszModule = new TCHAR[_MAX_PATH];

if (GetModuleFileName(hInstance, lpszModule, _MAX_PATH)) {

 // lpszResource - строкое название ресурса

 strResourceURL.Format(_T("res://%s/%s"), lpszModule, lpszResource);

 m_pBrowserApp->Navigate(strResourceURL, NULL, NULL, NULL, NULL);

} else bRetVal = FALSE;

delete [] lpszModule;

return bRetVal;

HTML ресурсы можно вынести в отдельный подкаталог, например html. Тогда в файле описания ресурсов (например, myapp.rc) необходимо добавить строки следующего вида:

IDR_MAIN HTML DISCARDABLE "html\\main.html"

DEL.GIF HTML DISCARDABLE "html\\del.gif"

LEFTARR.GIF HTML DISCARDABLE "html\\leftarr.gif"

RIGHTARR.GIF HTML DISCARDABLE "html\\rightarr.gif"

TITLE.GIF HTML DISCARDABLE "html\\title.gif"

NEWMSG.GIF HTML DISCARDABLE "html\\newmsg.gif"

Реализация доступа к ресурсам в IE достаточно умна, чтобы автоматически найти все необходимые объекты в ресурсах, на которые ссылается страничка, поэтому достаточно знать лишь ресурс-имя основной странички.

ВОПРОС-ОТВЕТ 

Q. Насколько корректно будут работать методы контроля утечек памяти (в частности объект CMemoryState) в многопоточных приложениях?

У меня сложилось впечатление, что объект CMemoryState не делает различия в каком потоке вызывались операторы new с момента обращения к memState.Checkpoint() до обращения к memState.DumpAllObjectsSince().

Видимо "моментальные снимки" распределённой памяти в данном случае не информативны, ведь несколько потоков работают в одном адресном пространстве?

Николай Турпитко 

A. Действительно, вне зависимости от потока, все распределения памяти попадают в один большой двусвязный список блоков памяти, который поддерживает отладочная версия CRT (если задан макрос _DEBUG). Что касается MFC-класса CMemoryState, он является просто тонкой обёрткой вокруг структуры _CrtMemState и функций для диагностики утечек памяти CRT. Поэтому он также не делает различий между потоками.

Хотя функции отладочной библиотеки очень полезны, они не отличаются гибкостью. Научить класс CMemoryState выдавать список блоков, выделенных текущим потоком, возможно, только используя недокументированные возможности CRT. Но кое-что в этом направлении можно сделать и легальными средствами. 

При распределении памяти в отладочной версии программы каждому блоку назначается тип. По умолчанию блок получает тип _NORMAL_BLOCK. Существуют и другие типы: _CRT_BLOCK (блок, распределяемый для внутренних нужд CRT), _CLIENT_BLOCK (блок, к которому применяется пользовательская функция построения дампа), _FREE_BLOCK (блок, который уже освобождён с помощью free; такие блоки остаются в памяти, чтобы отладочная библиотека могла отследить ошибки, связанные с записью в уже освобождённый блок памяти) и _IGNORE_BLOCK (блок, который игнорируется при построении списка распределённых объектов). В стандартную библиотеку входит версия оператора new с четырьмя параметрами, которой можно передать тип распределяемого блока.

Соответственно, мы можем сохранить идентификатор потока, который нас интересует, в глобальной переменной, а затем передавать оператору new тип  _NORMAL_BLOCK, если идентификатор текущего потока совпадает с сохранённым в переменной, и _IGNORE_BLOCK в противном случае. Чтобы облегчить эту задачу, можно написать небольшой модуль, который будет всем этим заниматься. Например: 

//------------------------------

// threadmem.h

void DumpOnlyThisThread(DWORD id);

extern DWORD __DumpThread;


#ifdef _DEBUG

#define THREAD_DEBUG_NEW \

 new((__DumpThread == ::GetCurrentThreadId() ? \

 _IGNORE_BLOCK : _NORMAL_BLOCK), THIS_FILE, __LINE__)

#else

#define THREAD_DEBUG_NEW new

#endif /* _DEBUG */


//------------------------------

// threadmem.cpp

void DumpOnlyThisThread(DWORD id) {

#ifdef _DEBUG

 InterlockedExchange((LONG *)&__DumpThread, id);

#endif /* _DEBUG */

}


DWORD __DumpThread;

Теперь функция потока, в котором мы хотим отслеживать утечки памяти, может выглядеть так:

#include "threadmem.h"

#define new THREAD_DEBUG_NEW

UINT ThreadFunc(LPVOID) {

 DumpOnlyThisThread(::GetCurrentThreadId());

 CMemoryState st;

 st.Checkpoint();

 // Распределяем и освобождаем память в процессе работы…

 new int[100];

 new CPoint[200];

 …

 st.DumpAllObjectsSince();

 return 0;

}

Объекты, распределённые во всех остальных потоках, не попадут в отчёт об утечках памяти.

Александр Шаргин (rudankort@mail.ru
В ПОИСКАХ ИСТИНЫ 

Q. Как создать окно ввода текста, переключаясь в которое устанавливался бы заданный язык. Например необходим ввод только русских слов в строке по которой ищется перевод на английский, а язык по умолчанию в виндовс английский. Хотелесь бы при запуске программы когда пользователь ткнет мышкой в поле ввода чтобы он не переключал язык по умолчанию на русский.

Alexander Shinkevich

Это все на сегодня. До встречи!

Алекс Jenter jenter@mail.ru
Красноярск, 2001.

Программирование на Visual C++ Выпуск №35 от 4 марта 2001 г.

Здравствуйте!

В сегодняшнем выпуске мы рассмотрим тему, которая также весьма и весьма часто фигурирует в ваших письмах – работа с электронной почтой из программы. Тема эта хорошо описывается в статье Михаила Плакунова, которую я и хочу предложить вашему вниманию.

СТАТЬЯ MAPI. Добавь почту в свое приложение.

Автор: Михаил Плакунов

Источник: Софт Терра

Введение

В последние годы электронная почта является неотъемлемой составляющей персональных информационных средств. С большой степенью вероятности верно то, что, если у человека на столе стоит компьютер, то на нем установлена та или иная система электронной почты. Вместе с тем типичные приложения для работы с электронной почтой в чистом виде далеко не всегда отвечают требованиям автоматизации трудовой деятельности пользователя. В связи с этим существует потребность в создании различного рода приложений, не являющихся частью почтовых систем, но вместе с тем предоставляющих пользователю некоторые средства для работы с электронной почтой. Программный интерфейс MAPI, о котором пойдет речь в этой статье, является одним из средств, позволяющим создавать подобные приложения на платформе Windows.

Что есть MAPI?

В широком понимании MAPI (Messaging Application Programming Interface) – это целая архитектура, специфицирующая процессы взаимодействия отдельных приложений с различными почтовыми системами. Архитектура MAPI описывает так называемую подсистему MAPI, которая обеспечивает взаимодействие клиентских приложений с различными службами почтовой системы, такими как служба хранения информации, служба адресной книги, служба транспорта и т.д. С другой стороны MAPI – это прикладной интерфейс, который был создан для того, чтобы разработчики на C, C++, Visual Basic (а в последствии и Visual Basic Script) имели возможность добавлять в свои приложения функциональность для работы с электронной почтой. С точки зрения прикладной программы подсистема MAPI – это набор динамических библиотек, содержащих функции и объектно-ориентированные интерфейсы, благодаря которым взаимодействуют клиентские и серверные части почтовых приложений. О MAPI можно говорить много и долго (благо компания Microsoft постаралась сделать из MAPI очередного программного  «монстра»), но наибольший интерес для разработчиков представляют так называемые клиентские прикладные программные интерфейсы, среди которых следует выделить в первую очередь Simple MAPI, MAPI и CDO.

Начнем с простого – Simple MAPI

Simple MAPI предоставляет в распоряжение разработчиков всего 12 простейших функций. Они позволяют выполнять такие действия, как «сформировать сообщение», «указать адрес получателя», «отправить», «получить».  Причем все операции с сообщениями можно производить только в рамках одной папки, являющейся папкой для входящих сообщений текущего контейнера доставки (в почтовой системе MS Exchange Server это обычно или в русскоязычной версии). Разработчик не имеет доступа к полной структуре папок почтового сервера, то есть может контролировать сообщение лишь до тех пор, пока пользователь не переместит его из папки в какую-либо другую.

Другим недостатком Simple MAPI является то, что он позволяет работать только со стандартными полями сообщения, такими как «Тема», «Отправитель», «Получатель», «Дата отправки», «Текст сообщения», «Класс сообщения», а также с вложенными файлами.

При всей своей ограниченности Simple MAPI подкупает имено простотой в освоении и использовании. Тому, кто имеет даже небольшой опыт программирования на C или Visual Basic достаточно нескольких минут для, того чтобы научиться использовать этот интерфейс.

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

MAPILogon(0,"My Profile", NULL, MAPI_NEW_SESSION, 0, &pSession);

MAPIResolveName(pSession, 0, "Bill Gates", 0, 0, &pRecipient);

ZeroMemory(&pMessage, sizeof(pMessage));

pMessage.lpszSubject = " Greeting";

pMessage.lpszNoteText = "Hello Bill!";

pMessage.nRecipCount = 1;

pMessage.lpRecips = Recipient;

MAPISendMail(pSession, 0, &pMessage, 0, 0);

MAPILogoff(pSession, 0, 0, 0);

В приведенном примере формируется сообщение с темой , содержащее текст и отправляется адресату, видимое имя которого в адресной книге. Сейчас мы разберем по шагам как это делается.

Первым делом клиентской программе необходимо начать сеанс работы с почтовой системой, для чего при помощи функции MAPILogon открывается сессия Simple MAPI. Затем из видимого имени ("Bill Gates") функция MAPIResolveName формирует структуру, содержащую точную и полную информацию об адресате (в частности его электронный адрес). Полученная информация об адресате наряду с темой и текстом формирует структуру, содержащую почтовое сообщение, готовое к отправке. Функция MAPISendMail отправляет сообщение по электронной почте. Наконец, функция MAPILogoff завершает сеанс работы с почтовой системой, закрывая сессию Simple MAPI.

Просто, не правда ли? Немного модифицировав программу, можно дать ей возможность отправлять сообщения, содержащие не только текст, но и вложенные файлы. Изучив еще пару-тройку функций Simple MAPI, можно с легкостью запрограммировать получение анализ и удаление сообщений, содержащихся в почтовом ящике пользователя.

Simple MAPI позволяет запрограммировать две основные функции электронной почты – отправку и прием сообщений. Зачастую это вся функциональность, необходимая приложению для работы с электронной почтой. Типичными примерами использования Simple MAPI являются приложения, производящие рассылку сообщений (возможно однотипных, по шаблону) множеству адресатов, а также приложения, время от времени сканирующие почтовый ящик пользователя и производящие анализ и обработку поступающей в него корреспонденции.

Программисты на C найдут определения всех функций, структур и констант Simple MAPI в файле MAPI.H, входящем в состав Microsoft Visual Studio. Его аналогом для Visual Basic является файл MAPI.BAS. Сами функции находятся в динамической библиотеке MAPI.DLL. Как правило Simple MAPI входит в состав клиентских почтовых программ, причем не только работающих в архитектуре (MS Outlook, MS Exchange Client), но и обычных (MS Outlook Express, Eudora Pro, а в скором будущем и The Bat!).

MAPI 1.0 – для продвинутых

Simple MAPI на то и simple, что накладывает серьезные ограничения на разработчика как в плане функциональности, так и в плане производительности приложения. Полностью снять эти оковы позволяет гибкий и мощный программный интерфейс MAPI 1.0 (в прошлом – Extended MAPI по аналогии с Simple MAPI). MAPI 1.0 – это совокупность более ста функций и нескольких десятков COM-интерфейсов, предоставляющих программистам на C и C++ богатый инструментарий для создания приложений, работающих с электронной почтой. Simple MAPI можно назвать оберткой MAPI 1.0, которая скрывает множество деталей и нюансов взаимодействия приложений с почтовыми системами.

MAPI 1.0 предоставляет разработчику не только возможность реализации таких простых функций как отправка или прием почтовых сообщений, но и механизмы для более тесного взаимодействия с отдельными частями систем электронной почты – с адресной книгой, иерархической структурой папок на почтовом сервере, службой транспорта и т.д. Более того, с помощью MAPI 1.0 можно создавать даже части почтовых систем – программные шлюзы, различные службы обработки информации, которые являются частью MAPI-совместимых почтовых серверов. Не будет преувеличением сказать, что, используя MAPI 1.0 можно создать свою собственную клиентскую почтовую программу, аналогичную MS Oulook со всеми ее богатыми возможностями.

Вместе с тем создание приложений на базе MAPI 1.0 – более трудоемкий процесс, нежели программирование с использованием Simple MAPI. MAPI 1.0 требует от разработчика дополнительной квалификации, в частности знания технологии COM. Перепишем уже имеющийся пример с использованием MAPI 1.0. Для наглядности каждый блок кода сопоставлен с соответствующим фрагментом из предыдущего примера.

// Begin MAPILogon(:);

MAPILogonEx(0, "My Profile", NULL, MAPI_NEW_SESSION, &lpSession);

// End MAPILogon(:);

lpSession->GetMsgStoresTable(0, &StoresTable);

HrQueryAllRows(StoresTable, (LPSPropTagArray)&tagDefaultStore, NULL, NULL, 0, &lpRow);

for(i = 0; i < lpRow -> cRows; i++) {

 if (lpRow->aRow[i].lpProps[0].Value.b == TRUE) break;

}

lpSession->OpenMsgStore(0, lpRow->aRow[i].lpProps[1].Value.bin.cb,

 (LPENTRYID)lpRow->aRow[i].lpProps[1].Value.bin.lpb, NULL,

 MDB_WRITE, &lpMDB);

lpMDB->OpenEntry(lpPropValue->Value.bin.cb, (LPENTRYID)lpPropValue->Value.bin.lpb,

 NULL, MAPI_MODIFY, &ulObjType, (LPUNKNOWN *)&lpFolder);

lpFolder->CreateMessage(NULL, 0, &lpMsg);

SInitPropValue MsgProps[] = {

 {PR_DELETE_AFTER_SUBMIT, 0, TRUE},

 {PR_MESSAGE_CLASS, 0, (ULONG)"IPM.NOTE "},

 {PR_SUBJECT, 0, (ULONG)"Greeting"},

 {PR_BODY, 0, (ULONG)" Hello Bill!"}

};

lpMsg->SetProps(4, (LPSPropValue)&MsgProps, NULL);


// Begin MAPIResolveName(:);

lpSession->OpenAddressBook(0, NULL, AB_NO_DIALOG, &lpAdrBook);

MAPIAllocateBuffer(CbNewADRLIST(1), (LPVOID*)&lpAdrList);

MAPIAllocateBuffer(2*sizeof(SPropValue), (LPVOID*)&(lpAdrList->aEntries->rgPropVals));

ZeroMemory(lpAdrList->aEntries->rgPropVals, 2*sizeof(SPropValue));

lpAdrList->cEntries = 1;

lpAdrList->aEntries[0].ulReserved1 = 0;

lpAdrList->aEntries[0].cValues = 2;

lpAdrList->aEntries[0].rgPropVals[0].ulPropTag = PR_DISPLAY_NAME;

lpAdrList->aEntries[0].rgPropVals[0].Value.lpszA = "Bill Gates";

lpAdrList->aEntries[0].rgPropVals[1].ulPropTag  = PR_RECIPIENT_TYPE;

lpAdrList->aEntries[0].rgPropVals[1].Value.l = MAPI_TO;

lpAdrBook->ResolveName(0, 0, NULL, lpAdrList);

lpMsg->ModifyRecipients(MODRECIP_ADD, lpAdrList);

// End MAPIResolveName(:);


// Begin MAPISendMail(:);

lpMsg->SubmitMessage(0);

// End MAPISendMail(:);


// Begin MAPILogoff (:);

lpSession->Logoff(0, 0, 0);

// End MAPILogoff (:);

Как видно из этого примера большинство операций, являющихся примитивными для Simple MAPI, в MAPI 1.0 состоят из последовательностей вызовов тех или иных методов различных интерфейсов. Так, для того, чтобы создать сообщение в MAPI 1.0 требуется получить доступ и открыть контейнер с сообщениями, отыскать в нем папку для исходящих сообщений и только потом собственно создать в ней само сообщение и начинить его всей необходимой информацией. В Simple MAPI все эти промежуточные шаги скрыты от разработчика. С другой стороны MAPI 1.0 позволяет создавать сообщения в любой папке (да и не только сообщения, а объекты календаря, задачи и т.д.). Таким образом, взамен простоте использования появляются новые возможности.

Интерфейс MAPI 1.0, в отличие от Simple MAPI можно использовать при создании служб Windows NT. Это очень полезное свойство позволяет создавать различного рода почтовые мониторы. Типичная задача почтового монитора может заключаться в сканировании почтового ящика пользователя на предмет поступающей в него корреспонденции, ее разбор, анализ и последующие действия по результатам этого анализа.

Отдельного обсуждения заслуживает такая возможность MAPI 1.0 как создание всевозможных расширений (extensions) к клиентским программам почтовой системы MS Exchange Server (MS Outlook или MS Exchange Client). Расширения позволяют автоматизировать различные функции обработки сообщений, не реализованные в базовом наборе функций клиентской программы. В частности, механизм расширений позволяет создавать модули для обработки входящих сообщений, так называемые правила (rules), добавлять к клиентской программе дополнительные команды и пункты меню, а также обработчики событий, изменяющие поведение системы при определенных событиях и многое другое.

CDO – разумный компромисс

Интерфейс CDO (Collaboration Data Objects), ранее известный как OLE Messaging и Active Messaging представляет собой библиотеку, обеспечивающую доступ приложений к несколько ограниченному набору функция MAPI 1.0 через вызовы Automation. Функции работы с сообщениями могут быть встроены в приложения, созданные с помощью любого средства разработки, являющегося контроллером Automation. К таковым относятся C/C++, Visual Basic, Visual Basic for Applications, VBScript, Javascript. Использование CDO существенно упрощает разработку приложений, работающих с электронной почтой, вместе с тем оставляя разработчику широкие возможности MAPI. Наибольшее применение CDO находит в скриптовых языках. Так, например, в комбинации с APS использование CDO позволяет достаточно легко создать почтового Web-клиента.

Сухой остаток

Итак, мы кратко рассмотрели 3 программных интерфейса, позволяющих встраивать в приложения на платформе Windows функциональность для работы с электронной почтой. У каждого из них есть свои преимущества и недостатки. Ничего универсального не существует – окончательный выбор того или иного средства зависит от конкретной задачи и является прерогативой разработчика. Более подробную информацию на эту тему можно получить на http://msdn.microsoft.com/library/psdk/mapi/.

ВОПРОС-ОТВЕТ 

Q. Как создать окно ввода текста переключаясь в которое устанавливался бы заданный язык. Например, необходим ввод только русских слов в строке, по которой ищется перевод на английский, а язык по умолчанию в виндовс английский. Хотелесь бы при запуске программы, когда пользователь ткнет мышкой в поле ввода, чтобы он не переключал язык по умолчаню на русский.

Alexander Shinkevich 

A1 Для переключения раскладок необходимо вызвать функцию LoadKeyboardLayout. 

Ниже приводится пример ее использования: 

1) Добавить в проект с помощью Class Wizard'а новый класс CMyEdit на основе CEdit.

2) Добавить в класс переменную, хранящую предыдущую установленную раскладку клавиатуры: 

TCHAR m_PreviousLayout[KL_NAMELENGTH];

3) Добавить обработчики WM_SETFOCUS и WM_KILLFOCUS: 

void CMyEdit::OnSetFocus(CWnd* pOldWnd) {

 CEdit::OnSetFocus(pOldWnd);

// запоминаем предыдущую раскладку клавиатуры

 ::GetKeyboardLayoutName(m_PreviousLayout);

 // устанавливаем новую раскладку для языка "Русский"

 ::LoadKeyboardLayout(_T("00000419"), KLF_ACTIVATE);

}


void CMyEdit::OnKillFocus(CWnd* pNewWnd) {

 CEdit::OnKillFocus(pNewWnd);

 // восстанавливаем предыдущую раскладку клавиатуры

 ::LoadKeyboardLayout(m_PreviousLayout, KLF_ACTIVATE);

}

4) Использовать CMyEdit вместо CEdit (на примере диалога): 

class CMyDlg : public CDialog {

 // ...

 CMyEdit m_Edit;

 // ...

};


void CMyDlg::DoDataExchange(CDataExchange* pDX) {

 CDialog::DoDataExchange(pDX);

 //{{AFX_DATA_MAP(CTestKeyboardDlg)

 DDX_Control( pDX, IDC_EDIT, m_Edit );

 //}}AFX_DATA_MAP

}

Алексей Гончаров 

A2 […] Также можно активизировать т.н. keyboard layout (раскладку клавиатуры) с помощью функции ActivateKeyboardLayout, активизирующей раскладку, загруженную предварительно с помощью указанной выше функции LoadKeyboardLayout. Хотя LoadKeyboardLayout сама может активизировать раскладку (при использовании флага KLF_ACTIVATE), но при частой смене языка оптимальнее использовать ActivateKeyboardLayout. Т.е. в начале загрузить раскладку с помощью LoadKeyboardLayout, а многократно переключать язык ввода функцией ActivateKeyboardLayout.

Igor Sukharev 
В ПОИСКАХ ИСТИНЫ 

Q. Можно ли из моей программы управлять окном которое создано другим приложением (закрывать, сворачивать, нажимать в нем кнопки и т.д.), если да то как?

Alhim 

А на сегодня это все. До встречи через неделю! 

Алекс Jenter jenter@mail.ru
Красноярск, 2001.

Программирование на Visual C++ Выпуск №36 от 11 марта 2001 г.

Здравствуйте!

Ну вот, готова моя первая статья из серии, посвященной межпроцессному обмену данными. Эта статья является обзорной, ее цель – познакомить вас со всем многообразием механизмов Windows для обмена данными между процессами. В последующих статьях я остановлюсь на основных методах поподробнее. Хотя, к сожалению не могу обещать что эти статьи появятся скоро. Вы, однако, можете повлиять на мой выбор тем для подробного рассмотрения, если сообщите мне заранее, какая именно из них вас особенно интересует.

СТАТЬЯ
IPC: основы межпроцессного взаимодействия
Обзор технологий

Введение

Любая операционная система была бы весьма ущербна, если бы замыкала выполняющееся приложение в собственном темном мирке без окон и дверей, без какой-либо возможности сообщить другим программам какую-либо информацию. Если посмотреть внимательно, можно заметить, что далеко не все приложения являются самодостаточными. Очень многим, если не большей части, требуется информация от других приложений, либо они должны эту информацию сообщать. Именно поэтому в операционную систему встраивается множество механизмов, которые обеспечивают т.н. Interproccess Communication (IPC) – то есть межпроцессное взаимодействие.

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

Рассмотрим подробнее несколько ключевых примеров, демонстрирующих важность IPC. Вам, возможно это покажется неправдоподобным, но зачатки IPC существовали еще в MS-DOS – и это несмотря на то, что MS-DOS при всем желании трудно назвать многозадачной средой. В самом деле, когда вы в командной строке вводили подобную инструкцию:

C:\>DIR|MORE

происходило следующее: выполнялась команда DIR и ее вывод записывался во временный текстовый файл. После этого содержимое файла подавалось на вход команды MORE. В результате вы получали листинг каталогов, который в случае большого количества каталогов не уезжал мгновенно за экран, а мог скроллироваться с помощью клавиши Enter. Конечно же это очень примитивный IPC, но его наличие показывает, что уже тогда такой механизм был востребован и в какой-то мере реализован.

Примеры использования IPC охватывают гораздо большее количество программ и приложений, чем вы скорее всего думаете. Когда вы выходите в интернет, ваш браузер – одна программа (процесс) – взаимодействует с web-сервером – другой программой (процессом). Эти программы выполняются на разных компьютерах; браузер на вашем, сервер – где-то еще. И вас не волнует, какая ОС установлена на сервере и какая там платформа.

Или, например, вы работаете с удаленной базой данных. Ваше клиентское приложение – это один процесс, на сервере базы данных запущен другой процесс. Процесс на сервере выполняет запросы к БД, поступающие от вашего процесса.

ПРИМЕЧАНИЕ

Вообще, для сетевых форм IPC (но не обязательно только для них) очень часто используется концепция "клиент-сервер". Как вы понимаете, "клиент" – это приложение, которому требуются данные, "сервер" – приложение, предоставляющее данные.

А если брать только взаимодействие программ, выполняющихся на одном компьютере, самым банальным примером будет следующий: текст из вашего текcтового редактора передается в электронную таблицу или программу для верстки. Да-да, наш старый знакомый буфер обмена – это тоже один из механизмов IPC!

И еще можно было бы привести очень много примеров.

Средств, обеспечивающих взаимодействие между процессами, создано достаточно много. Огромное их количество реализовано в Windows 9x, еще больше – в Windows NT/2000. Теперь нужно приличное количество времени, чтобы хотя бы познакомиться со всеми! Замечу, что нет, и наверное в принципе не может быть универсального способа обмена данными, который годился бы на все случаи жизни – все равно в некоторых случаях использование другого способа будет предпочтительнее. Но я надеюсь, что после прочтения этой статьи вы сможете достаточно уверенно ориентироваться в мире IPC и обоснованно выбирать тот или иной метод.

Тот факт, что механизмы IPC работают на уровне операционной системы, положительно сказывается на скорости и надежности программ и программных комплексов, построенных с их использованием. Эффективность приложений соответственно возрастает.

Вообще, правильнее было бы называть эти механизмы "Interthread Communication" – межпотоковое взаимодействие. Если вы помните, выполняются именно потоки, они же и обмениваются данными. Однако, смысл для отдельных механизмов взаимодействия появляется только в том случае, если эти потоки принадлежат разным процессам. Ведь потоки, выполняющиеся в рамках одного процесса, вовсе не нуждаются в дополнительных средствах для общения между собой. Так как они разделяют одно адресное пространство, обмен данными могут обеспечить обычные переменные. Таким образом, IPC становится необходим в том случае, если поток одного процесса должен передать данные потоку другого процесса.

Теперь давайте рассмотрим основные виды IPC и случаи, в которых они используются.

Буфер обмена (clipboard)

Это одна из самых примитивных и хорошо известных форм IPC. Он появился еще в самых ранних версиях Windows. Основная его задача – обеспечивать обмен данными между программами по желанию и под контролем пользователя. Впрочем, вы наверняка сами неплохо знаете, как используется буфер обмена… ;-) Не рекомендуется использовать его для внутренних нужд приложения, и не стоит помещать туда то, что не предназначено для прямого просмотра пользователем.

Сообщение WM_COPYDATA

Стандартное сообщение для передачи участка памяти другому процессу. Работает однонаправленно, принимающий процесс должен расценивать полученные данные как read only. Посылать это сообщение необходимо только с помощью SendMessage, которая (напомню) в отличие от PostMessage ждет завершения операции. Таким образом, посылающий поток "подвисает" на время передачи данных. Вы сами должны решить, насколько это приемлемо для вас. Это не имеет значения для небольших кусков данных, но для больших объемов данных или для real-time приложений этот способ вряд ли подходит.

Разделяемая память (shared memory)

Этот способ взаимодействия реализуется не совсем напрямую, а через технологию File Mapping – отображения файлов на оперативную память. Вкраце, этот механизм позволяет осуществлять доступ к файлу таким образом, как будто это обыкновенный массив, хранящийся в памяти (не загружая файл в память явно). "Побочным эффектом" этой технологии является возможность работать с таким отображенным файлом сразу нескольким процессам. Таким образом, можно создать объект file mapping, но не ассоциировать его с каким-то конкретным файлом. Получаемая область памяти как раз и будет общей между процессами. Работая с этой памятью, потоки обязательно должны согласовывать свои действия с помощью объектов синхронизации.

Библиотеки динамической компоновки (DLL)

Библиотеки динамической компоновки также имеют способность обеспечивать обмен данными между процессами. Когда в рамках DLL объявляется переменная, ее можно сделать разделяемой (shared). Все процессы, обращающиеся к библиотеке, для таких переменных будут использовать одно и то же место в физической памяти. (Здесь также важно не забыть о синхронизации.)

Протокол динамического обмена данными (Dynamic Data Exchange, DDE)

Этот протокол выполняет все основные функции для обмена данными между приложениями. Он очень широко использовался до тех пор, пока для этих целей не стали применять OLE (впоследствии ActiveX). На данный момент DDE используется достаточно редко, в основном для обратной совместимости.

Больше всего этот протокол подходит для задач, не требующих продолжительного взаимодействия с пользователем. Пользователю в некоторых случаях нужно только установить соединение между программами, а обмен данными происходит без его участия. Замечу, что все это в равной степени относится и к технологии OLE/ActiveX.

OLE/ActiveX

Это действительно универсальная технология, и одно из многих ее применений – межпроцессный обмен данными. Хотя cтоит думаю отметить, что OLE как раз для этой цели и создавалась (на смену DDE), и только потом была расширена настолько, что пришлось поменять название ;-). Специально для обмена данными существует интерфейс IDataObject. А для обмена данными по сети используется DCOM, которую под некоторым углом можно рассматривать как объединение ActiveX и RPC.

Каналы (pipes)

Каналы – это очень мощная технология обмена данными. Наверное, именно поэтому в полной мере они поддерживаются только в Windows NT/2000. В общем случае канал можно представить в виде трубы, соединяющей два процесса. Что попадает в трубу на одном конце, мгновенно появляется на другом. Чаще всего каналы используются для передачи непрерывного потока данных.

Каналы делятся на анонимные (anonymous pipes) и именованные (named pipes).

Анонимные каналы используются достаточно редко, они просто передают поток вывода одного процесса на поток ввода другого.

Именованные каналы передают произвольные данные и могут работать через сеть. (Именованные каналы поддерживаются только в WinNT/2000.)

Сокеты (sockets)

Это очень важная технология, т.к. именно она отвечает за обмен данными в Интернет. Сокеты также часто используются в крупных ЛВС. Взаимодействие происходит через т.н. разъемы-"сокеты", которые представляют собой абстракцию конечных точек коммуникационной линии, соединяющей два приложения. С этими объектами программа и должна работать, например, ждать соединения, посылать данные и т.д. В Windows входит достаточно мощный API для работы с сокетами.

Почтовые слоты (mailslots)

Почтовые слоты – это механизм однонаправленного IPC. Если приложению известно имя слота, оно может помещать туда сообщения, а приложение-хозяин этого слота (приемник) может их оттуда извлекать и соответствующим образом обрабатывать. Основное преимущество этого способа – возможность передавать сообщения по локальной сети сразу нескольким компьютерам за одну операцию. Для этого приложения-приемники создают почтовые слоты с одним и тем же именем. Когда в дальнейшем какое-либо приложение помещает сообщение в этот слот, приложения-приемники получают его одновременно.

Объекты синхронизации

Как ни странно, объекты синхронизации тоже можно отнести к механизмам IPC. Конечно, объем передаваемых данных в данном случае очень невелик ;) Но именно эти объекты следует использовать, если одному процессу нужно передать другому что-то вроде "я закончил работу" или "я начинаю работать с общей памятью".

Microsoft Message Queue (MSMQ)

Этот протокол действительно оправдывает свое название – он обеспечивает посылку сообщений между приложениями с помощью очереди сообщений. Основное его отличие от стандартной очереди сообщений Windows в том, что он может работать с удаленными процессами и даже с процессами, которые на данный момент недоступны (например, не запущены). Доставка сообщения по адресу гарантируется. Оно ставится в специальную очередь сообщений и находится там до тех пор, пока не появляется возможность его доставить.

Удаленный вызов процедур (Remote Procedure Call, RPC)

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

Резюме

Конечно, я перечислил далеко не все способы обмена данными. Если бы это было так, то это было бы не так интересно ;-) За рамками данной статьи остались такие вещи, как глобальная таблица атомов, хуки и некоторые другие технологии, которые с некоторой натяжкой можно признать механизмами IPC. Но главное, как я считаю, сделано: теперь вы знаете, что это за непонятные аббревиатуры и как из всего многообразия методов IPC выбрать наиболее подходящий.

ВОПРОС-ОТВЕТ

Q. Можно ли из моей программы управлять окном которое создано другим приложением (закрывать, сворачивать, нажимать в нем кнопки и т.д.), если да то как?

Alhim

A. Выполнение этой задачи распадается на два этапа.

Сначала нужно каким-то образом определить хэндл окна, которым мы собираемся манипулировать. Основным инструментом здесь являются функции FindWindow(Ex), которые ищут окно по заданному классу и/или заголовку. В определении и того, и другого сильно помогает программа Spy++. Рассмотрим пример поиска HWND стандартной кнопки "Пуск". Сначала используем Spy++, чтобы определить классы панели задач и самой кнопки; оказывается, их имена "Shell_TrayWnd" и "Button" соответственно. Затем используем FindWindow(Ex).

HWND hWnd;

hWnd = FindWindow("Shell_TrayWnd", NULL);

hWnd = FindWindowEx(hWnd, NULL, "Button", NULL);

if (IsWindow(hWnd)) {

 // Кнопка найдена, работаем с ней

}

Ещё один набор функций, которые могут помочь в поиске хэндла чужого окна – это EnumChildWindows, EnumThreadWindows и EnumWindows, перечисляющие все окна, принадлежащие заданному окну, все окна заданного потока и все окна в системе соответственно. За описанием этих функций следует обратиться к документации.

Кроме перечисленного можно упомянуть случай, когда приложение специально проектируется для взаимодействие с другим посредством обмена сообщениями. Например, одно приложение запускает другое, а затем обменивается с ним данными посредством WM_COPYDATA. В этом случае вполне уместно передать хэндл окна (это 4-хбайтовое целое) как параметр командной строки.

После того, как хэндл окна определён, можно переходить ко второму этапу – управлению окном. Многие функции позволяют работать с окном, вне зависимости от того, какому процессу оно принадлежит. Характерные примеры таких функций – ShowWindow и SetForegroundWindow. Для примера рассмотрим, как спрятать кнопку "Пуск", получать хэндл которой мы уже научились.

HWND hWnd;

hWnd = FindWindow("Shell_TrayWnd", NULL);

hWnd = FindWindowEx(hWnd, NULL, "Button", NULL);

if (IsWindow(hWnd)) {

 ShowWindow(hWnd, SW_HIDE);

 Sleep(5000);

 ShowWindow(hWnd, SW_SHOW); // Показываем обратно

}

Кроме использования подобных функций, можно посылать окну сообщения. Например, послав кнопке BM_CLICK (с помощью PostMessage), мы как бы нажимаем на неё.

Проблемы возникают с функциями, которые позволяют работать только с окнами, созданными в том же потоке, в котором вызывается функция. В качестве примера приведу функцию DestroyWindow. Похожая проблема возникает, когда нужно "сабкласить" окно чужого процесса. В этих случаях необходимо внедрить свой код в чужой процесс и выполнить его в чужом потоке; удобнее всего сделать эт о, если код оформлен в виде DLL.

Существует несколько способов внедрить DLL в чужой процесс. Я покажу один из них; он достаточно прост и работает на всех Win32-платформах (Windows 9x, Windows NT), но в некоторых случаях недостаточно точен. Этот способ подразумевает установку хука на поток, создавший интересующее нас окно. При этом DLL, содержащая функцию хука, загружается системой в адресное пространство чужого процесса. Это как раз то, что нам нужно. А функцию хука вполне можно оставить пустой.

Рассмотрим пример DLL, которая уничтожает окно чужого процесса. (Такие вещи нужно делать, только полностью отдавая себе отчёт о возможных последствиях. Процесс, оставленный без окна, имеет хорошие шансы "рухнуть").

// _KillDll.cpp : Defines the entry point for the DLL application.

//


#include <windows.h>


// Создаём переменную в разделяемом сегменте,

// чтобы передать HWND из программы в DLL в чужом процессе.

#pragma comment(linker, "/SECTION:SHARED,RWS")

#pragma data_seg("SHARED")

__declspec(allocate("SHARED")) HWND hWndToKill = NULL;

#pragma data_seg()


BOOL APIENTRY DllMain(HANDLE hModule, DWORD ul_reason_for_call, LPVOID lpReserved) {

 if (ul_reason_for_call == DLL_PROCESS_ATTACH &&

  IsWindow(hWndToKill) &&

  GetWindowThreadProcessId(hWndToKill, NULL) == GetCurrentThreadId()) {

  // Если окно существует и принадлежит текущему потоку, убиваем его.

  HANDLE hEvent = OpenEvent(NULL, FALSE, "{1F6C5480-155E-11d5-93A8-444553540000}");

  DestroyWindow(hWndToKill);

  SetEvent(hEvent);

  CloseHandle(hEvent);

 }

 return TRUE;

}


// Пустая функция хука.

LRESULT CALLBACK GetMsgProc(int code, WPARAM wParam, LPARAM lParam) {

 return 1;

}


extern "C" __declspec(dllexport) void KillWndNow(HWND hWnd) {

 if (!IsWindow(hWnd)) return;

 hWndToKill = hWnd;

 HANDLE hEvent = CreateEvent(NULL, TRUE, FALSE, "{1F6C5480-155E-11d5-93A8-444553540000}");

 DWORD dwThread = GetWindowThreadProcessId(hWnd, NULL);

 HHOOK hHook =

  SetWindowsHookEx(WH_GETMESSAGE, GetMsgProc, GetModuleHandle("_KillDll.dll"), dwThread);

 PostThreadMessage(dwThread, WM_NULL, 0, 0);

 WaitForSingleObject(hEvent, INFINITE);

 CloseHandle(hEvent);

 UnhookWindowsHookEx(hHook);

}

Чтобы использовать эту DLL, просто подключите её к программе (проще всего сделать это неявным методом), а затем выполните код:

extern "C" void KillWndNow(HWND hWnd);

HWND hWnd;

// Ищем окно

KillWndNow(hWnd);

Хотя код DLL сам по себе и небольшой, в нём есть несколько тонкостей, на которые я хотел бы обратить ваше внимание. Во-первых, я поместил переменную hWndToKill в разделяемый сегмент. Поскольку функция DestroyWindow вызывается в потоке чужого процесса, необходимо предусмотреть некоторый способ передачи хэндла окна через границы процессов. Разделяемая переменная – наиболее простое средство достичь цели. Во-вторых, DLL, содержащая функцию хука, не будет спроектирована на адресное пространство чужого процесса, пока функция хука реально не понадобится. В нашем случае хук имеет тип WH_GETMESSAGE, а значит DLL не загрузится, пока поток не получит какое-либо сообщение. Поэтому я посылаю ему сообщение WM_NULL (с кодом 0), чтобы вынудить ОС загрузить DLL. В-третьих, обратите внимание на применение события для синхронизации потоков в нашем и целевом процессах. Разумеется, для этой цели можно использовать и любой другой механизм синхронизации потоков.

Александр Шаргин (rudankort@mail.ru)
 ПОИСКАХ ИСТИНЫ

Q. Хотелось бы побольше узнать о предварительном просмотре. В русской программе он смотрится инородным телом на своем иностранном языке. Можно ли его как-то настраивать под себя?

В этой же связи: не могу решить проблему.

В программе 3 меню и, соответственно, 3 панели инструментов, которые создал в Create. Переключая меню, вызываю ShowControlBar – прячу ненужные панели и показываю необходимую. Но после вызова PRINT PREVIEW, в окне появляются сразу все 3 панели инструментов.

Попутно: что означает AFX_IDS_PREVIEW_CLOSE в String Table?

Serg Petukhov

Успехов!

Алекс Jenter jenter@mail.ru
Красноярск, 2001.

Программирование на Visual C++ Выпуск №37 от 18 марта 2001 г.

Приветствую, уважаемые подписчики!

Сегодня нас ждет новая статья нашего постоянного автора Александра Шаргина, на этот раз посвященная стандартной библиотеке шаблонов C++.

СТАТЬЯ Введение в STL Часть 1

Автор: Александр Шаргин

rudankort@mail.ru 

Стандартная библиотека шаблонов (Standard Template Library, STL) входит в стандартную библиотеку языка "C++". В неё включены реализации наиболее часто используемых контейнеров и алгоритмов, что избавляет программистов от рутинного переписывания их снова и снова. При разработке контейнеров и применяемых к ним алгоритмов (таких как удаление одинаковых элементов, сортировка, поиск и т. д.) часто приходится приносить в жертву либо универсальность, либо быстродействие. Однако разработчики STL поставили перед собой сверхзадачу – сделать библиотеку одновременно эффективной и универсальной. Надо признать, что им удалось достичь цели, хотя для этого и пришлось использовать наиболее продвинутые возможности языка C++, такие как шаблоны и перегрузка операторов.

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

Стандарт языка C++ не регламетнирует реализацию контейнеров и алгоритмов STL. Поэтому с каждым компилятором поставляется своя реализация этой библиотеки. В последующем изложении я буду опираться на реализацию, поставляемую фирмой Microsoft вместе с компилятором Visual C++ 6.0. Тем не менее, большая часть сказанного будет справедлива и для других реализаций STL.

Основные концепции STL

Краеугольными камнями STL являются понятия контейнера (container), алгоритма (algorithm) и итератора (iterator).

• Контейнер – это хранилище объектов (как встроенных, так и определённых пользователем типов). Простейшие виды контейнеров (статические и динамические массивы) встроены непосредственно в язык C++. Кроме того, стандартная библиотека включает в себя реализации таких контейнеров, как вектор (vector), список (list), очередь (deque), ассоциативный массив (map), множество (set), и некоторых других.

• Алгоритм – это функция для манипулирования объектами, содержащимися в контейнере. Типичные примеры алгоритмов – сортировка и поиск. В STL реализовано порядка 60 алгоритмов, которые можно применять к различным контейнерам, в том числе к массивам, встроенным в язык C++.

• Итератор – это абстракция указателя, то есть объект, который может ссылаться на другие объекты, содержащиеся в контейнере. Основные функции итератора – обеспечение доступа к объекту, на который он ссылается (разыменование), и переход от одного элемента контейнера к другому (итерация, отсюда и название итератора). Для встроенных контейнеров в качестве итераторов используются обычные указатели. В случае с более сложными контейнерами итераторы реализуются в виде классов с набором перегруженных операторов.

Рассмотрим эти концепции более подробно.

Итераторы

Итераторы используются для доступа к элементам контейнера так же, как указатели – для доступа к элементам обычного массива. Как мы знаем, в языке C++ над указателями можно выполнять следующий набор операций: разыменование, инкремент/декремент, сложение/вычитание и сравнение. Соответственно, любой итератор реализует все эти операции или некоторое их подмножество. Кроме того, некоторые итераторы позволяют работать с объектами в режиме "только чтение" или "только запись", тогда как другие предоставляют доступ и на чтение, и на запись. В зависимости от набора поддерживаемых операций различают 5 типов итераторов, которые приведены в следующей таблице.

Тип итератора Доступ Разыменование Итерация Сравнение
Итератор вывода (output iterator) Только запись * ++  
Итератор ввода (input iterator) Только чтение *, –> ++ ==, !=
Прямой итератор (Forward iterator) Чтение и запись *, –> ++ ==, !=
Двунаправленный итератор (bidirectional iterator) Чтение и запись *, –> ++, -- ==, !=
Итератор с произвольным доступом (random-access iterator) Чтение и запись *, –>, [] ++, --, +, –, +=, –= ==, !=, <, <=, >, >=

Итератор с произвольным доступом реализует полный набор операций, применимых к обычным указателям.

Контейнеры

Как мы уже знаем, контейнер предназначен для хранения объектов. Хотя внутреннее устройство контейнеров очень сильно различается, каждый контейнер обязан предоставить строго определённый интерфейс, через который с ним будут взаимодействовать алгоритмы. Этот интерфейс обеспечивают итераторы. Каждый контейнер обязан иметь соответствующий ему итератор (и только итератор). Важно подчеркнуть, что никакие дополнительные функции-члены для взаимодействия алгоритмов и контейнеров не используются. Это сделано потому, что стандартные алгоритмы должны работать в том числе со встроенными контейнерами языка C++, у которых есть итераторы (указатели), но нет ничего, кроме них. Таким образом при написании собственного контейнера реализация итератора – необходимый минимум.

Каждый контейнер реализует определённый тип итераторов. При этом выбирается наиболее функциональный тип итератора, который может быть эффективно реализован для данного контейнера. "Эффективно" означает, что скорость выполнения операций над итератором не должна зависеть от количества элементов в контейнере. Например, для вектора реализуется итератор с произвольным доступом, а для списка – двунаправленный. Поскольку скорость выполнения операции [] для списка линейно зависит от его длины, итератор с произвольным доступом для списка не реализуется.

Вне зависимости от фактической организации контейнера (вектор, список, дерево) хранящиеся в нём элементы можно рассматривать как последовательность. Итератор первого элемента в этой последовательности вгозвращает функция begin(), а итератор элемента, следующего за последним – функция end(). Это очень важно, так как все алгоритмы в STL работают именно с последовательностями, заданными итераторами начала и конца.

Кроме обычных итераторов в STL существуют обратные итераторы (reverse iterator). Обратный итератор отличается тем, что просматривает последовательность элементов в контейнере в обратном порядке. Другими словами, операции + и – у него меняются местами. Это позволяет применять алгоритмы как к прямой, так и к обратной последовательности элементов. Например, с помощью функции find можно искать элементы как "с начала", так и "с конца" контейнера.

Каждый класс контейнера, реализованный в STL, описывает набор типов, связанных с контейнером. При написании собственных контейнеров следует придерживаться этой же практики. Вот список наиболее важных типов:

• value_type — тип элемента

• size_type — тип для хранения числа элементов (обычно size_t)

• iterator — итератор для элементов контейнера

• key_type — тип ключа (в ассоциативном контейнере)

Помимо типов можно выделить набор функций, которые реализует почти каждый контейнер в STL. Они не требуются для взаимодействия с алгоритмами, но их реализация улучшает взаимозаменяемость контейнеров в прграмме. Если, к примеру, какой-то контейнер реализует набор характерных для списка функций, то его можно будет вставить в программу вместо списка, изменив в ней всего одну строчку. Список основных функций приведён в таблице.

Функция Описание
begin, end Возвращают итераторы начала и конца прямой последовательности.
rbegin, rend Возвращают итераторы начала и конца обратной последовательности.
front, back Возвращают ссылки на первый и последний элемент, хранящийся в контейнере.
push_back, pop_back Позволяют добавить или удалить последний элемент в последовательности.
push_front, pop_front Позволяют добавить или удалить первый элемент в последовательности.
size Возвращает количество элементов в контейнере.
empty Проверяет, есть ли в контейнере элементы.
clear Удаляет из контейнера все элементы.
insert, erase Позволяют вставить или удалить элемент(ы) в середине последовательности.
Алгоритмы

Мы уже установили две важные вещи. Во-первых, алгоритмы предназначены для манипулирования элементами контейнера. Во-вторых, любой алгоритм рассматривает содержимое контейнера как последовательность, задаваемую итераторами первого и следующего за последним элементов. Итераторы обеспечивают интерфейс между контейнерами и алгоритмами, благодаря чему и достигается гибкость и универсальность библиотеки STL.

Каждый алгоритм использует итераторы определённого типа. Например, алгоритм простого поиска (find) просматривает элементы подряд, пока нужный не будет найден. Для такой процедуры вполне достаточно итератора ввода. С другой стороны, алгоритм более быстрого двоичного поиска (binary_search) должен иметь возможность переходить к любому элементу последовательности, и поэтому требует итератора с произвольным доступом. Вполне естественно, что вместо менее функционального итератора можно передать алгоритму более функциональный, но не наоборот.

Все стандартные алгоритмы описаны в файле algorithm, в пространстве имён std.

Вспомогательные компоненты STL

Помимо уже рассмотренных элементов в STL есть ряд второстепенных понятий, с которыми следует познакомиться.

Аллокаторы

Аллокатор (allocator) – это объект, отвечающий за распределение памяти для элементов контейнера. С каждым стандартным контейнером связывается аллокатор (его тип передаётся как один из параметров шаблона). Если какому-то алгоритму требуется распределять память для элементов, он обязан делать это через аллокатор. В этом случае можно быть уверенным, что распределённые объекты будут уничтожены правильно.

В состав STL входит стандартный класс allocator (описан в файле xmemory). Именно его по умолчанию используют все контейнеры, реализованные в STL. Однако никто не мешает вам реализовать собственный. Необходимость в этом возникает очень редко, но иногда это можно сделать из соображений эффективности или в отладочных целях.

Объекты-функции

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

template<class T, class CmpFn>

T &max(T &x1, T &x2, CmpFn cmp) {

 return cmp(x1, x2) ? x1 : x2;

}

Что такое CmpFn? Естественнее всего предположить, что это указатель на функцию. Однако вызов функции по указателю – операция довольно долгая. В нашем примере вызов займёт больше времени, чем выполнение всех остальных инструкций в функции max. Проблема в том, что при таком подходе к передаче функции её не удаётся объявить как встроенную (inline).

Вместо указателя на функцию можно передать в max объект любого класса с перегруженным оператором (). При этом operator() можно объявить как встроенный, что при большом количестве обращений к max даст очевидный выигрыш в производительности.

Таким образом, объекты-функции используются в целях оптимизации

Предикаты

Термин "предикат" довольно часто фигурирует в книгах по STL. В действительности предикат – это просто функция (в частности объект-функция), которая возвращает bool. Различают унарные и бинарные предикаты. Унарные получают один параметр, бинарные – два.

Предикаты широко используются в STL. Унарные предикаты используются для задания подмножества элементов контейнера, удовлетворяющих некоторому условию. Например, функция count_if считает количество элементов последовательности, для которых заданный унарный предикат возвращает true. Бинарные предикаты чаще всего используются для сравнения двух элементов.

Адаптеры

Адаптер (adapter) – это класс, который не реализует собственную функциональность, а вместо этого предоставляет альтернативный интерфейс к функциональности другого класса.

В STL адаптеры применяются для самых различных классов (контейнеров, объектов-функций и т.д.). Наиболее типичный пример адаптера – стек. Стек может использовать в качестве нижележащего класса различные контейнеры (очередь, вектор, список), обеспечивая для них стандартный стековый интерфейс (функции push/pop).

После такой обстоятельной теоретической подготовки можно перейти к практическим аспектам работы с STL, которые я рассмотрю во второй части статьи.

ОБРАТНАЯ СВЯЗЬ 

Александру Шаргину от читателя пришло интересное письмо. Он решил, что его было бы полезно прочитать всем. 

В №36 рассылки "Программирование на Visual C++" я прочитал ваш пример убивания чужого окна, использующий DLL. Однако, мне показалось, что пример не полный, поскольку может возникнуть ситуация, когда сразу несолько процессов вызовут функцию DLL KillWndNow. В этом случае может сложиться ситуация, когда сначала первый процесс запишет в shared-переменную hWndToKill хэндл убиваемого окна, затем второй процесс запишет тужа же, но уже другой хэндл, потом первый запустит механизм убивания, но в результате убьется окно, на которое уже успел указать второй процесс. 

Более корректно было бы поместить весь код функции KillWndNow в критическую секцию. Но, поскольку критические секции могут использоваться только в рамках одного процесса, для синхронизации здесь уместно использоваться мютекс. 

Еще один нюанс. В функции KillWndNow где-нибудь после строчки

WaitForSingleObject(hEvent, INFINITE);

нужно вставить оператор hWndToKill=NULL, иначе при любой загрузке DLL (например, другим процессом, который вызвал KillWndNow) в функции DllMain будет исполняться ветка кода, пытающаяся убивать окно, хотя фактически запрос на такую операцию не поступал. 

И, наконец, последнее. Все это будет работать только в том случае, если эта DLL еще не была загружена процессом, окно которого мы хотим убить. А если была? Придется использовать какой-то другой механизм, или все-таки можно как-нибудь усовершенствовать существующий? Самое плохое даже не то, что чужое окно не будет убиваться, а то, что функция KillWndNow подвиснет на вызове WaitForSingleObject, поскольку это событие никогда не реализуется. А если еще и добавить мютекс, как я описал выше, то повиснут и все последующие вызовы этой функции, но уже на ожидании освобождения мютекса.

Dmitry Batsuro 

Остальных рубрик сегодня не будет. За неделю мне не пришло НИ ОДНОГО ответа на вопрос, так что я решил его оставить на следующую неделю. 

До встречи! 

Алекс Jenter jenter@mail.ru
Красноярск, 2001.

Программирование на Visual C++ Выпуск №38 от 24 марта 2001 г.

Приветствую!

Сегодня мы с вами углубимся в особенности систем Windows NT/2000 – а именно, научимся создавать под них особые программы, называемые службами или сервисами.

СТАТЬЯ Службы Windows NT: назначение и разработка Зачем и как создавать службы (сервисы) Windows NT/2000

Автор: Михаил Плакунов

Источник: СофтТерра

Службы Windows NT, общие понятия

Служба Windows NT (Windows NT service) – специальный процесс, обладающий унифицированным интерфейсом для взаимодействия с операционной системой Windows NT. Службы делятся на два типа – службы Win32, взаимодействующие с операционной системой посредством диспетчера управления службами (Service Control Manager – SCM), и драйвера, работающие по протоколу драйвера устройства Windows NT. Далее в этой статье мы будем обсуждать только службы Win32.

Применение служб

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

• Сервера в архитектуре клиент-сервер (например, MS SQL, MS Exchange Server)

• Сетевые службы Windows NT (Server, Workstation);

• Серверные (в смысле функциональности) компоненты распределенных приложений (например, всевозможные программы мониторинга).

Основные свойства служб

От обычного приложения Win32 службу отличают 3 основных свойства. Рассмотрим каждое из них.

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

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

И, наконец, возможность работы в произвольном контексте безопасности. Контекст безопасности Windows NT определяет совокупность прав доступа процесса к различным объектам системы и данным. В отличие от обычного приложения Win32, которое всегда запускается в контексте безопасности пользователя, зарегистрированного в данный момент в системе, для службы контекст безопасности ее выполнения можно определить заранее. Это означает, что для службы можно определить набор ее прав доступа к объектам системы заранее и тем самым ограничить сферу ее деятельности. Применительно к службам существует специальный вид контекста безопасности, используемый по умолчанию и называющийся Local System. Служба, запущенная в этом контексте, обладает правами только на ресурсы локального компьютера. Никакие сетевые операции не могут быть осуществлены с правами Local System, поскольку этот контекст имеет смысл только на локальном компьютере и не опознается другими компьютерами сети.

Взаимодействие службы с другими приложениями

Любое приложение, имеющее соответствующие права, может взаимодействовать со службой. Взаимодействие, в первую очередь, подразумевает изменение состояния службы, то есть перевод ее в одно из трех состояний – работающее (Запуск), приостанов (Пауза), останов и осуществляется при помощи подачи запросов SCM. Запросы бывают трех типов – сообщения от служб (фиксация их состояний), запросы, связанные с изменением конфигурации службы или получением информации о ней и запросы приложений на изменение состояния службы.

Для управления службой необходимо в первую очередь получают ее дескриптор с помощью функции Win32 API OpenService. Функция StartService запускает службу. При необходимости изменение состояния службы производится вызовом функции ControlService.

База данных службы

Информация о каждой службе хранится в реестре – в ключе HKLM\SYSTEM\CurrentControlSet\Services\ServiceName. Там содержатся следующие сведения:

• Тип службы. Указывает на то, реализована ли в данном приложении только одна служба (эксклюзивная) или же их в приложении несколько. Эксклюзивная служба может работать в любом контексте безопасности. Несколько служб внутри одного приложения могут работать только в контексте LocalSystem.

• Тип запуска. Автоматический – служба запускается при старте системы. По требованию – служба запускается пользователем вручную. Деактивированный – служба не может быть запущена.

• Имя исполняемого модуля (EXE-файл).

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

• Контекст безопасности выполнения службы (сетевое имя и пароль). По умолчанию контекст безопасности соответствует LocalSystem.

Приложения, которым требуется получить информацию о какой-либо службе или изменить тот или иной параметр службы, по сути должны изменить информацию в базе данных службы в реестре. Это можно сделать посредством соответствующих функций Win32 API:

• OpenSCManager, CreateService, OpenService, CloseServiceHandle – для создания (открытия) службы;

• QueryServiceConfig, QueryServiceObjectSecurity, EnumDependentServices, EnumServicesStatus – для получения информации о службе;

• ChangeServiceConfig, SetServiceObjectSecurity, LockServiceDatabase, UnlockServiceDatabase, QueryServiceLockStatus – для изменения конфигурационной информации службы.

Внутреннее устройство службы.

Для того, чтобы «быть службой», приложение должно быть устроено соответствующим образом, а именно – включать в себя определенный набор функций (в терминах C++) с определенной функциональностью. Рассмотрим кратко каждую из них.

Функция main

Как известно функция main – точка входа любого консольного Win32 приложения. При запуске службы первым делом начинает выполняться код этой функции. Втечение 30 секунд с момента старта функция main должна обязательно вызвать StartServiceCtrlDispatcher для установления соединения между приложением и SCM. Все коммуникации между любой службой данного приложения и SCM осуществляются внутри функции StartServiceCtrlDispatcher, которая завершает работу только после остановки всех служб в приложении.

Функция ServiceMain

Помимо общепроцессной точки входа существует еще отдельная точка входа для каждой из служб, реализованных в приложении. Имена функций, являющихся точками входа служб (для простоты назовем их всех одинаково – ServiceMain), передаются SCM в одном из параметров при вызове StartServiceCtrlDispatcher. При запуске каждой службы для выполнения ServiceMain создается отдельный поток.

Получив управление, ServiceMain первым делом должна зарегистрировать обработчик запросов к службе, функцию Handler, свою для каждой из служб в приложении. После этого в ServiceMain обычно следуют какие-либо действия для инициализации службы – выделение памяти, чтение данных и т.п. Эти действия должны обязательно сопровождаться уведомлениями SCM о том, что служба все еще находится в процессе старта и никаких сбоев не произошло. Уведомления посылаются при помощи вызовов функции SetServiceStatus. Все вызовы, кроме самого последнего должны быть с параметром SERVICE_START_PENDING, а самый последний – с параметром SERVICE_RUNNING. Периодичность вызовов определяется разработчиком службы, исходя их следующего условия: продолжительность временного интервала между двумя соседними вызовами SetServiceStatus не должна превышать значения параметра dwWaitHint, переданного SCM при первом из двух вызовов. В противном случае SCM, не получив во-время очередного уведомления, принудительно остановит службу. Такой способ позволяет избежать ситуации «зависания» службы на старте в результате возникновения тех или иных сбоев (вспомним, что службы обычно неинтерактивны и могут запускаться в отсутствие пользователя). Обычная практика заключается в том, что после завершения очередного шага инициализации происходит уведомление SCM.

Функция Handler

Как уже упоминалось выше, Handler – это прототип callback-функции, обработчика запросов к службе, своей для каждой службы в приложении. Handler вызывается, когда службе приходит запрос (запуск, приостанов, возобновление, останов, сообщение текущего состояния) и выполняет необходимые в соответствии с запросом действия, после чего сообщает новое состояние SCM.

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

Система безопасности служб

Любое действие над службами требует наличия соответствующих прав у приложения. Все приложения обладают правами на соединение с SCM, перечисление служб и проверку заблокированности БД службы. Регистрировать в сиситеме новую службу или блокировать БД службы могут только приложения, обладающие административными правами.

Каждая служба имеет дескриптор безопасности, описывающий какие пользователи имеют права на ту или иную операцию. По умолчанию:

• Все пользователи имеют права SERVICE_QUERY_CONFIG, SERVICE_QUERY_STATUS, SERVICE_ENUMERATE_DEPENDENTS, SERVICE_INTERROGATE и SERVICE_USER_DEFINED_CONTROL;

• Пользователи, входящие в группу Power Users и учетная запись LocalSystem дополнительно имеют права SERVICE_START, SERVICE_PAUSE_CONTINUE и SERVICE_STOP;

• Пользователи, входящие в группы Administrators и System Operators имеют право SERVICE_ALL_ACCESS.

Службы и интерактивность

По умолчанию интерактивные службы могут выполняться только в контексте безопасности LocalSystem. Это связано с особенностями вывода на экран монитора в Windows NT, где существует, например, такой объект как "Desktop", для работы с которым нужно иметь соответствующие права доступа, которых может не оказаться у произвольной учетной записи, отличной от LocalSystem. Несмотря на то, что в подавляющем большинстве случаев это ограничение несущественно однако иногда существует необходимость создать службу, которая выводила бы информацию на экран монитора и при этом выполнялась бы в контексте безопасности отличном от LocalSystem, например, серверная компонента приложения для запуска приложений на удаленном компьютере.

Следующий фрагмент кода иллюстрирует такую возможность.

// Функция, аналог MessageBox Win32 API

int ServerMessageBox(RPC_BINDING_HANDLE h, LPSTR lpszText, LPSTR lpszTitle, UINT fuStyle) {

 DWORD dwThreadId;

 HWINSTA hwinstaSave;

 HDESK hdeskSave;

 HWINSTA hwinstaUser;

 HDESK hdeskUser;

 int result;

 // Запоминаем текущие объекты "Window station" и "Desktop".

 GetDesktopWindow();

 hwinstaSave = GetProcessWindowStation();

 dwThreadId = GetCurrentThreadId();

 hdeskSave = GetThreadDesktop(dwThreadId);

 // Меняем контекст безопасности на тот,

 // который есть у вызавшего клиента RPC

 // и получаем доступ к пользовательским

 // объектам "Window station" и "Desktop".

 RpcImpersonateClient(h);

 hwinstaUser = OpenWindowStation("WinSta0", FALSE, MAXIMUM_ALLOWED);

 if (hwinstaUser == NULL) {

  RpcRevertToSelf();

  return 0;

 }

 SetProcessWindowStation(hwinstaUser);

 hdeskUser = OpenDesktop("Default", 0, FALSE, MAXIMUM_ALLOWED);

 RpcRevertToSelf();

 if (hdeskUser == NULL) {

  SetProcessWindowStation(hwinstaSave);

  CloseWindowStation(hwinstaUser);

  return 0;

 }

 SetThreadDesktop(hdeskUser);

 // Выводим обычное текстовое окно.

 result = MessageBox(NULL, lpszText, lpszTitle, fuStyle);

 // Восстанавливаем сохраненные объекты

 // "Window station" и "Desktop".

 SetThreadDesktop(hdeskSave);

 SetProcessWindowStation(hwinstaSave);

 CloseDesktop(hdeskUser);

 CloseWindowStation(hwinstaUser);

 return result;

}

В этом фрагменте в ответ на запрос, посланный клиентской частью приложения последством RPC, служба выводит текстовое сообщение на экран монитора.

Пример службы (ключевые фрагменты)

Рассмотрим на примере ключевые фрагменты приложения на языке C++, реализующего службу Windows NT. Для наглядности несущественные части кода опущены.

Функция main

Вот как выглядит код функции main:

void main() {

 SERVICE_TABLE_ENTRY steTable[] = {

  {SERVICENAME, ServiceMain}, {NULL, NULL}

 };

 // Устанавливаем соединение с SCM. Внутри этой функции

 // происходит прием и диспетчеризация запросов.

 StartServiceCtrlDispatcher(steTable);

}

Функция ServiceMain

Особенностью кода, содержащегося в ServiceMain, является то, что часто невозможно заранее предсказать время выполнения той или иной операции, особенно, если учесть, что ее выполнение происходит в операционной системе с вытесняющей многозадачностью. Если операция продлится дольше указанного в параметре вызова SetServiceStatus интервала времени, служба не сможет во-время отправить следующее уведомление, в результате чего SCM остановит ее работу. Примерами потенциально операций могут служить вызовы функций работы с сетью при больших таймаутах или единовременное чтение большого количества информации с медленного носителя. Кроме того, такой подход совершенно не применим при отладке службы, поскольку выполнение программы в отладчике сопровождается большими паузами, необходимыми разработчику.

Для преодоления этой проблемы все операции по взаимодействию с SCM следует выполнять в отдельном потоке, не зависящем от действий, происходящих на этапе инициализации.

Алгоритм корректного запуска службы, использующий вспомогательный поток:

void WINAPI ServiceMain(DWORD dwArgc, LPSTR *psArgv) {

 // Сразу регистрируем обработчик запросов.

 hSS = RegisterServiceCtrlHandler(SERVICENAME, ServiceHandler);

 sStatus.dwCheckPoint = 0;

 sStatus.dwControlsAccepted = SERVICE_ACCEPT_STOP | SERVICE_ACCEPT_PAUSE_CONTINUE;

 sStatus.dwServiceSpecificExitCode = 0;

 sStatus.dwServiceType = SERVICE_WIN32_OWN_PROCESS;

 sStatus.dwWaitHint = 0;

 sStatus.dwWin32ExitCode = NOERROR;

 // Для инициализации службы вызывается функция InitService();

 // Для того, чтобы в процессе инициализации система не

 // выгрузила службу, запускается поток, который раз в

 // секунду сообщает, что служба в процессе инициализации.

 // Для синхронизации потока создаётся событие.

 // После этого запускается рабочий поток, для

 // синхронизации которого также

 // создаётся событие.

 hSendStartPending = CreateEvent(NULL, TRUE, FALSE, NULL);

 HANDLE hSendStartThread;

 DWORD dwThreadId;

 hSendStartThread = CreateThread(NULL, 0, SendStartPending, NULL, 0, &dwThreadId);

 //Здесь производится вся инициализация службы.

 InitService();

 SetEvent(hSendStartPending);

 if (WaitForSingleObject(hSendStartThread, 2000) != WAIT_OBJECT_0) {

  TerminateThread(hSendStartThread, 0);

 }

 CloseHandle(hSendStartPending);

 CloseHandle(hSendStartThread);

 hWork = CreateEvent(NULL, TRUE, FALSE, NULL);

 hServiceThread = CreateThread(NULL, 0, ServiceFunc, 0, 0, &dwThreadId);

 sStatus.dwCurrentState = SERVICE_RUNNING;

 SetServiceStatus(hSS, &sStatus);

}


// Функция потока, каждую секунду посылающая уведомления SCM

// о том, что процесс инициализации идёт. Работа функции

// завершается, когда устанавливается

// событие hSendStartPending.

DWORD WINAPI SendStartPending(LPVOID) {

 sStatus.dwCheckPoint = 0;

 sStatus.dwCurrentState = SERVICE_START_PENDING;

 sStatus.dwWaitHint = 2000;

 // "Засыпаем" на 1 секунду. Если через 1 секунду

 // событие hSendStartPending не перешло

 // в сигнальное состояние (инициализация службы не

 // закончилась), посылаем очередное уведомление,

 // установив максимальный интервал времени

 // в 2 секунды, для того, чтобы был запас времени до

 // следующего уведомления.

 while (true) {

  SetServiceStatus(hSS, &sStatus);

  sStatus.dwCheckPoint++;

  if (WaitForSingleObject(hSendStartPending, 1000) != WAIT_TIMEOUT) break;

 }

 sStatus.dwCheckPoint = 0;

 return 0;

}


// Функция, инициализирующая службу. Чтение данных,

// распределение памяти и т.п.

void InitService() {

 ...

}


// Функция, содержащая «полезный» код службы.

DWORD WINAPI ServiceFunc(LPVOID) {

 while (true) {

  if (!bPause) {

   // Здесь содержится код, который как правило

   // выполняет какие-либо циклические операции...

  }

  if (WaitForSingleObject(hWork, 1000) != WAIT_TIMEOUT) break;

  sStatus.dwCheckPoint = 0;

  return 0;

 }

}

Функция Handler

А вот код функции Handler и вспомогательных потоков:

// Обработчик запросов от SCM

void WINAPI ServiceHandler(DWORD dwCode) {

 switch (dwCode) {

 case SERVICE_CONTROL_STOP:

 case SERVICE_CONTROL_SHUTDOWN:

  ReportStatusToSCMgr(SERVICE_STOP_PENDING, NO_ERROR, 0, 1000);

  hSendStopPending = CreateEvent(NULL, TRUE, FALSE, NULL);

  hSendStopThread = CreateThread(NULL, 0, SendStopPending, NULL, 0, & dwThreadId);

  SetEvent(hWork);

  if (WaitForSingleObject(hServiceThread, 1000) != WAIT_OBJECT_0) {

   TerminateThread(hServiceThread, 0);

  }

  SetEvent(hSendStopPending);

  CloseHandle(hServiceThread);

  CloseHandle(hWork);

  if(WaitForSingleObject(hSendStopThread, 2000) != WAIT_OBJECT_0) {

   TerminateThread(hSendStopThread, 0);

  }

  CloseHandle(hSendStopPending);

  sStatus.dwCurrentState = SERVICE_STOPPED;

  SetServiceStatus(hSS, &sStatus);

  break;

 case SERVICE_CONTROL_PAUSE:

  bPause = true;

  sStatus.dwCurrentState = SERVICE_PAUSED;

  SetServiceStatus(hSS, &sStatus);

  break;

 case SERVICE_CONTROL_CONTINUE:

  bPause = true;

  sStatus.dwCurrentState = SERVICE_RUNNING;

  SetServiceStatus(hSS, &sStatus);

  break;

 case SERVICE_CONTROL_INTERROGATE:

  SetServiceStatus(hSS, &sStatus);

  break;

 default:

  SetServiceStatus(hSS, &sStatus);

  break;

 }

}


// Функция потока, аналогичная SendStartPending

// для останова службы.

DWORD WINAPI SendStopPending(LPVOID) {

 sStatus.dwCheckPoint = 0;

 sStatus.dwCurrentState = SERVICE_STOP_PENDING;

 sStatus.dwWaitHint = 2000;

 while (true) {

  SetServiceStatus(hSS, &sStatus);

  sStatus.dwCheckPoint++;

  if (WaitForSingleObject(hSendStopPending, 1000) != WAIT_TIMEOUT) break;

 }

 sStatus.dwCheckPoint = 0;

 return 0;

}

Для запросов "Stop" и "Shutdown" используется алгоритм корректного останова службы, аналогичный тому, который используется при старте службы, с той лишь разницей, что вместо параметра SERVICE_START_PENDING в SetserviceStatus передается параметр SERVICE_STOP_PENDING, а вместо SERVICE_RUNNING — SERVICE_STOPPED.

В идеале для запросов "Pause" и "Continue" тоже следует использовать этот подход. Любознательный читатель без труда сможет реализовать его, опираясь на данные примеры.

Заключение

В заключение хотелось бы отметить, что с переходом на Windows 2000 разработка служб не претерпела изменений. Службы по-прежнему остаются важной частью программного обеспечения на платформе Windows, что предоставляет разработчикам широкое поле деятельности.

ВОПРОС-ОТВЕТ

Q. Хотелось бы побольше узнать о предварительном просмотре. В русской программе он смотрится инородным телом на своем иностранном языке. Можно ли его как-то настраивать под себя?

В этой же связи: не могу решить проблему.

В программе 3 меню и, соответственно, 3 панели инструментов, которые создал в Create. Переключая меню, вызываю ShowControlBar – прячу ненужные панели и показываю необходимую. Но после вызова PRINT PREVIEW, в окне появляются сразу все 3 панели инструментов.

Попутно: что означает AFX_IDS_PREVIEW_CLOSE в String Table?

Serg Petukhov 

A. Отвечу по порядку. 

1. Все языко-зависимые компоненты для печати и предварительного просмотра (панель инструментов, диалог и строки) в соответствии с идеологией MFC оформлены как ресурсы. Эти ресурсы лежат в файле MFC42.DLL, но программа будет искать их там только если они отсутствуют в головной программе. Если же программа статически линкуется с MFC, ресурсы для печати/предварительного просмотра берутся из файла afxprint.rc. Чтобы в этом всём убедиться, достаточно открыть rc-файл, сгенерённым визардом, и найти там строчки: 

#if !defined(AFX_RESOURCE_DLL) || defined(AFX_TARG_RUS)

#include "afxprint.rc" // printing/print preview resources

#endif 

Теперь понятно, как поправить ситуацию.

– Копируем ресурсы из файла afxprint.rc (без окантовочных директив, то есть от строчки "// Printing Resources") в файл ресурсов нашей программы. При этом нужно проследить, чтобы новые ресурсы попали между директивами #ifdef APPSTUDIO_INVOKED и соответствующего #endif (иначе новые ресурсы нельзя будет изменить в редакторе).

– Убираем из файла ресурсов строчку #include "afxprint.rc" (вручную или через View→Resource includes). На самом деле, это необходимо сделать только при статической линковке с MFC, так как при динамической линковке эта строчка не используется (как я уже говорил, в этом случае ресурсы берутся из MFC42.DLL).

– Затем запускаем редактор ресурсов Visual Studio и русифицируем новые ресурсы. Не забудьте предварительно установить для каждого ресурса в свойствах Language:Russian, иначе вместо русского языка получите иероглифы!

– Пересобираем проект и убеждаемся, что теперь предварительный просмотр говорит по-русски. 

2. После выхода из Print Preview запускается функция CView::OnEndPrintPreview (файл viewcore.cpp). Из неё вызывается ещё одна функция – CFrameWnd::OnSetPreviewMode (файл winfrm.cpp). Просмотрев код этой функции, нетрудно убедиться, что она делает видимыми все стандартные панели с идентификаторами от AFX_IDW_CONTROLBAR_FIRST до AFX_IDW_CONTROLBAR_FIRST+31 включительно. Таким образом, чтобы MFC не вмешивалась в вашу работу с панелями инструментов, нужно назначить им идентификаторы за пределами этого диапазона (например, AFX_IDW_CONTROLBAR_LAST-N, где N = 0, 1, 2, …):

m_wndToolBar.CreateEx(..., AFX_IDW_CONTROLBAR_LAST);  

3. Что касается строки AFX_IDS_PREVIEW_CLOSE, она просто содержит подсказку для команды Close предварительного просмотра. Если вам интересно, где она появляется, запустите режим предварительного просмотра, а затем наведите курсор на пункт Close из системного меню программы (которое раскрывается по щелчку на иконке в левом верхнем углу главного окна). При этом текст подсказки о закрытии предварительного просмотра появится в строке состояния. Можете заменить его на любой другой (на русском языке).

Александр Шаргин (rudankort@mail.ru
В ПОИСКАХ ИСТИНЫ 

Q. Есть приложение на базе диалога. По некоторым причинам необходимо уже внутрь этого диалога вставить закладки (страницы свойств, как хотите). Все это нормально делается и проблем тут не возникает. Но вот при использовании клавиши Tab для прогулки по диалогу фокус с последнего контрола, не принадлежащего Property Page, перемещается не на закладку страницы, а на ее первый определенный в Tab Layout контрол, и только после пробегания по всем элементам Property Page попадает на закладку. Как это вылечить?

George Orlov 

Это все на сегодня. Счастливо! 

Алекс Jenter jenter@mail.ru
Красноярск, 2001.

Программирование на Visual C++ Выпуск №39 от 1 апреля 2001 г.

Добрый день, уважаемые подписчики! С праздником вас!

СТАТЬЯ Диагностические средства MFC

Автор: Олег Быков 

Библиотека MFC предоставляет программисту мощный набор средств для отладки приложений любой сложности. Данная статья ставит своей целью последовательное рассмотрение диагностических средств для помощи начинающим MFC-программистам в выборе и более полном их использовании.

Разработка коммерческих приложений всегда подразумевает написание стабильно работающих систем, и, как следствие, наличие в коде тотальной проверки всего на свете – входных параметров функций, возвращенных значений, полученных указателей и т.д. Но за стабильность приходится платить замедлением работы программы. MFC предлагает следующий подход к проблеме: разработчик вставляет в код набор диагностических макроопределений, которые при невыполнении заданных условий сообщают имя исходного файла с ошибкой, номер строки, и останавливают работу программы. При этом данные макроопределения выполняются только при отладочной сборке проекта (Debug build).

Иными словами, в код помещаются проверки, которые выполняются только в отладочной версии программы, и не включаются в код при окончательной сборке (Release build). За время работы с отладочной версией программы (в идеале) выясняются и устраняются все возможные ошибочные ситуации и надобность в замедляющих работу проверках отпадает (здесь не имеются в виду ошибки, на которые программа должна реагировать определенными действиями. В частности, не стоит проверять таким образом результаты работы API-функций, так как нельзя гарантировать корректность возвращаемых ими значений и в отладочной сборке, и в окончательной). Чтобы стало понятней, рассмотрим несколько диагностических макроопределений.

ASSERT и VERIFY

ASSERT – пожалуй, один из самых часто употребляемых макросов. Принимая в качестве аргумента булево значение, ASSERT продолжает работу программы, если это значение равно TRUE, и прерывает работу программы в ином случае. При этом ASSERT выводит информационное окно с именем исходного файла и номером строки, содержащей сработавший макрос, и предоставляет разработчику выбор – окончательно прервать работу программы (Abort), переключиться в окно отладчика (Retry) или продолжить работу (Ignore).

В качестве примера использования ASSERT можно привести проверку входного значения функции:

void CPerson::SetPersonAge(int nAge) {

 ASSERT((nAge>=0) && (nAge<200)); // сработает при любых x, меньших 0

 m_nAge = x;                      // или больших 199

}

При срабатывании макроса (то есть, при передаче неверного nAge) у разработчика есть возможность переключиться в окно отладчика и через список вызовов (Call Stack) определить, откуда был передан ошибочный параметр.

ПРИМЕЧАНИЕ

ASSERT развернется в код только при Debug-сборке. Чтобы обеспечить вычисление параметра и в окончательной версии проекта (в случае, когда в ASSERT вызывается нужная функция), используйте макроопределение VERIFY. При Debug-сборке этот макрос полностью идентичен ASSERT, но, в отличие от него, при Release-сборке VERIFY разворачивается в код и вычисляет значение своего аргумента, хотя при этом никак не влияет на ход выполнения программы.

В MFC определен вспомогательный макрос DEBUG_ONLY, который служит для обеспечения выполнения своего параметра только при Debug-сборке. В Release-версии приложения выражение внутри DEBUG_ONLY будет проигнорировано.

ASSERT_KINDOF и ASSERT_VALID

Эти макросы предназначены для диагностики состояния объектов. ASSERT_KINDOF принимает два параметра — имя класса и указатель на объект - и срабатывает (прерывая выполнение программы подобно ASSERT) в случае, когда объект, переданный по указателю, не является объектом данного класса или одного из потомков данного класса. Пример использования макроса:

CPerson::CPerson(CPerson &newPerson) {

 ASSERT_KINDOF(CPerson, &newPerson); // сработает, если в конструктор

                                     // был передан объект не того класса

}

ASSERT_KINDOF полностью идентичен следующей конструкции (для нашего примера):

ASSERT(newPerson.IsKindOf(RUNTIME_CLASS(CPerson)));

Для того, чтобы получить информацию о классе в процессе исполнения, этот класс должен быть унаследован от CObject (или одного из его потомков), и для него должны быть использованы макросы DECLARE_DYNAMIC(classname) и IMPLEMENT_DYNAMIC(classname, baseclass) (иначе обращение к ASSERT_KINDOF приведет к ошибке нарушения защиты). Это относится и к проверяемому объекту, и к классу.

ASSERT_VALID служит для проверки внутреннего состояния объектов. Этот макрос принимает один параметр – указатель на проверяемый объект – и проделывает с ним следующее: проверяет валидность указателя, проверяет его на равенство NULL, и вызывает функцию объекта AssertValid.

AssertValid реализована почти во всех классах MFC (унаследованных от CObject), но разработчик может реализовать ее и в своем классе, соблюдая определенные правила. Во-первых, AssertValid должна быть переопределенной виртуальной функцией класса CObject. Эта функция описана как const, поэтому внутри нее нельзя изменять данные класса. Во-вторых, для индикации факта невалидности объекта функция должна использовать макрос ASSERT. И в-третьих, в AssertValid желательно вызвать эту же функцию класса-родителя.

Таким образом, разработчик может использовать ASSERT_VALID для реализации любых алгоритмов проверки состояния объекта. Например, вот так:

void CPerson::AssertValid() const {

 CObject::AssertValid(); // подразумевается, что CPerson унаследован

                         // от CObject

 ASSERT((m_nAge>=0) && (m_nAge<200));

}

ПРИМЕЧАНИЕ

ASSERT_KINDOF и ASSERT_VALID развернутся в код только при Debug-сборке.

В MFC определены два вспомогательных макроса для тестирования указателей: ASSERT_POINTER и ASSERT_NULL_OR_POINTER. Оба они принимают в качестве параметров два значения — указатель и его тип. ASSERT_POINTER сначала проверяет указатель на NULL, затем тестирует память по этому указателю на валидность. По непрохождении хотя бы одной проверки макрос срабатывает и останавливает работу программы. ASSERT_NULL_OR_POINTER также проверяет память, на которую ссылается указатель, но не прерывает выполнение программы, если тестируемый указатель равен NULL (хотя указатель при этом и является невалидным).

Работа с отладочной информацией (Output window)

При отладке приложений у разработчика часто возникает необходимость узнать значение какой-нибудь переменной или результат, возвращенный функцией. Для этого используют либо пошаговое исполнение интересующего участка кода с просмотром переменных в Watch-окне отладчика, либо вывод информации с помощью информационных окон (функции MessageBox и AfxMessageBox).

В Windows предусмотрен еще один способ получить информацию от программы во время ее исполнения – функция OutputDebugString. Функция принимает LPCTSTR-строку и посылает ее отладчику, под управлением которого исполняется приложение. В случае запуска приложения из Visual C++ посланная строка попадает в окно Output последнего (закладка Debug). Преимущество данного способа в том, что он не требует прерывать работу программы для отслеживания значений (что иногда критично – например, при отлаживании обработчика сообщения WWM_TIMER или асинхронного выполнения функций), и не требует убирать лишний код после отлаживания нужного участка (в отличие, скажем, от метода с MessageBox).

OutputDebugString можно использовать следующим образом:

void CPerson::SetPersonAge(int nAge) {

 ASSERT((nAge>=0) && (nAge<200));

 m_nAge = x;

 CString str;

 str.Format(_T("New age = %d\n"), nAge);

 OutputDebugString(str);

}

MFC упрощает вывод отладочной информации, определяя глобальный объект afxDump класса CDumpContext. Информация при этом выводится таким образом:

void CPerson::SetPersonAge(int nAge) {

 ASSERT((nAge>=0) && (nAge<200));

 m_nAge = x;

 afxDump << _T("New age = ") << nAge << _T("\n");

}

Отладочную информацию можно также выводить макросами TRACE, TRACE0, TRACE1, TRACE2 и TRACE3 (для таких целей обычно их и используют). Все они выводят переданную им информацию через afxDump, при этом принимают те же параметры, что и функция printf:

void CPerson::SetPersonAge(int nAge) {

 ASSERT((nAge>=0) && (nAge<200));

 m_nAge = x;

 TRACE(_T("New age = %d\n"), nAge);

}

Макросы TRACEn аналогичны макросу TRACE, с той лишь разницей, что их первый параметр имеет тип LPCSTR (а не LPCTSTR), и они принимают не произвольное число параметров, а определенное цифрой в их имени. Длина первого параметра всех TRACE-макросов (после всех подстановок) не должна превышать 512 символов, иначе макрос сгенерирует ASSERT.

Макросы TRACEn оставлены в MFC для обратной совместимости, при написании приложений рекомендуется пользоваться макросом TRACE.

ПРИМЕЧАНИЕ

Вывод отладочной информации и через afxDump, и через TRACE-макросы работает только в Debug-версии приложения.

В поставку Visual Studio 6.0 входит утилита для настройки вывода информации через TRACE-макросы – "MFC Tracer" (tracer.exe). С ее помощью можно отключить вывод отладочной информации (даже при Debug-сборке), заставить MFC выводить перед каждым сообщением в окне Output имя сгенерировавшего это сообщение проекта (полезно при отладке проекта, использующего DLL или состоящего из нескольких приложений), включить вывод уведомлений MFC об обработке определенных оконных сообщений и т.д.

Заканчивая обсуждение отладочной информации, нельзя не упомянуть утилиту TRACEWIN, написанную Paul DiLascia, также доступную в исходных текстах в апрельском номере MSJ за 1997 год. Эта утилита внедряется во все запускаемые процессы, и для MFC Debug-проектов перенаправляет весь TRACE-вывод в отдельное окно (причем перенаправление автоматически включается даже для уже запущенных приложений). Очень удобный инструмент. Более того, в той же статье Paul DiLascia доходчиво разъясняет принципы внедрения DLL в чужой процесс и приводит C++-класс, облегчающий эту задачу.

Вывод информации о внутреннем состоянии объектов

afxDump позволяет выводить в окне отладчика не только переменные, но и целые объекты (порожденные от CObject). Конструкция afxDump << &myPerson (или afxDump << myPerson) развернется в вызов myPerson.Dump(afxDump) (виртуальная функция класса CObject). Разрабатывая собственный класс, программист может переопределить эту функцию, реализовав свой метод вывода внутренней информации объекта, например, вот так:

// CPerson унаследован от CObject

void CPerson::Dump(CDumpContext &dc) const {

 CObject::Dump(dc);

 dc << T("Age = ") << m_nAge;

}

Вызов родительской функции CObject::Dump(dc) выведет на контекст имя класса, в случае, если для реализации этого класса (CPerson в примере выше) используется связка макросов DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC (или DECLARE_SERIAL/IMPLEMENT_SERIAL). Обратите внимание, что посылка символа перевода строки в переопределенной Dump не требуется.

ПРИМЕЧАНИЕ

Вывод отладочной информации об объекте через функцию Dump будет работать только в Debug-версии приложения, но здесь разработчик должен сам позаботиться о выполнении этого ограничения – и объявление, и реализацию, и вызовы функции Dump следует обрамлять проверками на Debug-сборку проекта:

class CPerson : public CObject {

 ...

public:

#ifdef _DEBUG

 void Dump(dc) const;

 void AssertValid() const; // это же касается объявления AssertValid

                           // (но не использования макроса ASSERT_VALID!)

#endif

 ...

};

После выполнения всех этих действий остается только скинуть в afxDump указатель на наш объект, и изучать полученную информацию в Output-окне отладчика. Многие классы MFC реализуют функцию Dump для диагностики их внутреннего состояния, что особенно полезно при отладке работы с классами-коллекциями C*Array, C*List и C*Map. Чтобы получить и состояние объектов, содержащихся в коллекции, нужно установить глубину вызова Dump-функции, отличную от 0, функцией SetDepth(int newDepth) класса CDumpContext:

CArray<CPerson, CPerson> arrPersons;

WorkWithArray(arrPersons); // здесь идет работа с массивом

#ifdef _DEBUG

afxDump.SetDepth(1);    // вывести информацию не только о коллекции,

afxDump << &arrPersons; // но и о всех ее членах (будет вызвана

                        // CPerson::Dump для каждого элемента массива)

#endif

Диагностика ошибок работы с памятью

Одна из самых распространенных ошибок при работе с памятью – выделение блока памяти (к примеру, при создании нового объекта) без его последующего освобождения (так называемые утечки памяти). Сами по себе эти утечки нефатальны ни для работы приложения, ни для работы системы (по завершению работы приложения Windows все равно освободит все занятые приложением блоки памяти), но это может привести к нехватке памяти, если приложение исполняется относительно долгое время (например, если это WinNT-сервис). Обычно для отслеживания утечек памяти используют специализированные программы, например, NuMega BoundsChecker, но и в MFC предусмотрены некоторые возможности для диагностики подобных ситуаций.

Класс CMemoryState предназначен для обнаружения динамически выделенных и не освобожденных впоследствии блоков памяти. Алгоритм работы с этим классом сводится к запоминанию списка созданных объектов функцией CMemoryState::Checkpoint, и последующим сравнением двух классов функцией CMemoryState::Difference. Например, вот так:

#ifdef _DEBUG

 CMemoryState msStart, msEnd, msDiff;

 msStart.Checkpoint(); // начало подозрительного блока

#endif

 ...

 CPerson *pPerson = new CPerson();

 ...

#ifdef _DEBUG

 msEnd.Checkpoint(); // конец подозрительного блока

 if (msDiff.Difference(msStart, msEnd) {

  TRACE0("Memory leaked!\n");

  msDiff.DumpAllObjectsSince(); //в Output-окне отладчика выведется

  msDiff.DumpStatistics();      //информация о созданных объектах

                                //и о динамической памяти вообще

 }

#endif

ПРИМЕЧАНИЕ

Обратите внимание на скобки #ifdef/endif – с классом CMemoryState можно работать только в Debug-версии библиотеки MFC.

Разработчики используют класс CMemoryState для проверки подозрительных кусков кода на корректность работы с динамической памятью. Библиотека MFC имитирует использование CMemoryState с помощью глобального объекта класса  _AFX_DEBUG_STATE, в деструкторе которого вызывается функция _CrtDumpMemoryLeaks (подробнее об этом можно почитать в статье "Обнаружение и локализация утечек памяти").

Функции DumpAllObjectsSince и DumpStatistics выводят в окне отладчика информацию о всех выделенных объектах со времени последнего вызова Checkpoint() и информацию о состоянии динамической памяти, соответственно. Информация о памяти выводится в следующем виде:

0 bytes in 0 Free Blocks

22 bytes in 1 Object Blocks

45 bytes in 4 Non-Object Blocks

Largest number used: 67 bytes

Total allocations: 67 bytes

Первая строка показывает число блоков памяти в объектах с отложенным удалением (в MFC имеется способ сделать так, чтобы delete не удаляла объекты сразу, а откладывала бы эту процедуру до конца работы программы. Это делается для тестирования программ в условиях нехватки памяти). Вторая и третья строки показывают размер занимаемой памяти и число объектов, соответственно, порожденных и не порожденных от CОbject. Последние две строки показывают максимальный и общий размер выделенной памяти.

Для того, чтобы MFC включила в отчет о состоянии памяти имя файла и номер строки, на которой был выделен неосвобожденный объект, в программе должен присутствовать следующий код:

#ifdef _DEBUG

#define new DEBUG_NEW

#endif

Эти строки MFC по умолчанию вставляет в исходные файлы при генерации нового проекта.

Надеюсь, этот обзор помог читателю сориентироваться в многообразии отладочных средств библиотеки MFC. Более подробную информацию по данной тематике можно найти в MSDN или исходных кодах примеров (в том числе исходных кодах самой MFC). Удачи!

Автор выражает благодарность Александру Шаргину за ценные советы и замечания.

ВОПРОС-ОТВЕТ 

Ну, господа, пришло время что-то решать… Так как мне опять не пришло ни одного ответа на вопрос, думаю что рубрика "Вопрос-Ответ", в том виде в каком она сейчас существует вам не интересна. Поэтому со следующего выпуска и вопросы, и ответы будут публиковаться одновременно. Это будет больше похоже на HOWTO.


Это все на сегодня. Пока! 

Алекс Jenter jenter@mail.ru
Красноярск, 2001.

Программирование на Visual C++ Выпуск №40 от 15 апреля 2001 г.

Здравствуйте, уважаемые подписчики!

Сегодня я хочу сделать очень важное объявление. Важное потому, что касается рассылки в целом и непосредственно каждого из вас.

Начиная с сентября 2000 года, подписчики не переставали спрашивать меня о том, есть ли у рассылки сайт, где можно посмотреть архив выпусков и другие материалы по программированию. Сайта тогда не было, и я отвечал соответственно, что собираюсь его сделать. Он тогда планировался просто как сайт рассылки и ничего больше. Однако чуть позже у нас с Александром Шаргиным возникла идея сделать полноценный сайт для наших разработчиков. Вернее, идея эта витала в воздухе, ей была фактически пропитана каждая конференция по программированию.

И мы решили попробовать ее реализовать. Работа над этим проектом началась несколько месяцев назад, и за это время к нам примкнуло большое количество людей. Сейчас над сайтом работает целая команда.

Вы наверное уже поняли к чему я веду. ;) Но вы ошибаетесь, все еще полагая, что у рассылки теперь появился сайт. Потому что все как раз наоборот – у сайта теперь есть рассылка! Потому как сайт превратился поистине в глобальное начинание. И начинание это называется RSDN – russian software developer network.

Cайт проекта RSDN отныне и всегда доступен по адресу www.rsdn.ru или просто rsdn.ru.

В настоящий момент RSDN состоит из шести основных разделов. В будущем их число, возможно, будет увеличиваться.

• Проект RSDN. В этом разделе собраны страницы, относящиеся к сайту в целом. Новости сайта, рассылки, авторы, контактная информация – все это вы найдете в этом разделе.

• Статьи. Здесь вы найдете библиотеку статей различной тематики. Вы сможете узнать много нового про различные технологии (Win32, COM, ADO), библиотеки классов (MFC, ATL, WTL), инструменты (Visual C++) и языки программирования (C, C++).

• Вопросы и ответы (Q&A). В этом разделе собраны вопросы, которые наиболее часто задаются как начинающими, так и более продвинутыми программистами. На каждый вопрос приводится исчерпывающий ответ, сопровождаемый пояснениями, фрагментами кода, а в некоторых случаях и демонстрационным проектом.

• Форумы. В этом разделе собраны форумы по самым различным тематикам, в которых вы можете обмениваться опытом с коллегами, разбросанными по всему земному шару. Если у вас есть вопрос, задайте его, и вам непременно помогут.

• Файлы. Здесь вы найдете самые различные утилиты, библиотеки, классы, готовые компоненты и множество других полезных файлов, доступных для скачивания.

• Ресурсы. В этом разделе содержится описание самых различных ресурсов, которые помогут вам в нелегкой работе. Вас ждет огромная коллекция ссылок на другие сайты, книги на русском и иностранных языках, доступные в бумажном и электронном виде, журналы, рассылки и конференции. Словом, этот раздел может служить отправной точкой для поиска необходимой информации.

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

Конечно, сайт еще только-только родился, и поэтому материалов на нем пока не очень много. Но база будет постоянно пополняться и, надеюсь, достаточно быстро.

Пара слов о рассылке. Рассылка теперь стала частью проекта RSDN. Это значит, что начиная со следующей недели, в ней будут публиковаться самые отборные и интересные материалы сайта, посвященные программированию на Visual C++. А уже сейчас на сайт выложен полный архив рассылки, где собраны практически все выпуски, вышедшие за время ее существования.

Что еще хочу заметить. На нашем сайте НЕТ БАННЕРОВ. Это полностью некоммерческий проект, именно поэтому вы не найдете на наших страницах никакой рекламы.

И еще – наше специальное предложение. RSDN – некоммерческий проект, и таковым и останется. Его авторы порой находятся в разных уголках Земли. Мы приглашаем и вас присоединиться к нашей команде. Мы обладаем технической возможностью разместить значительно большее количество материалов и разделов. У сайта есть хороший движок, отличный дизайн, форум, качественный хостинг, ведется разработка новых сервисов, все это будет и в вашем распоряжении, если вы решите примкнуть к RSDN. Например, вы могли бы открыть новый раздел на RSDN и стать его ведущим. Объединившись, значительно проще раскручивать и развивать ресурс.

Если вас заинтересовало это предложение, обращайтесь за дополнительной информацией по адресу team@rsdn.ru. Мы открыты для любых начинаний.

Ну ладно, что дальше говорить, когда надо смотреть! Итак, приглашаю всех познакомиться с новым сайтом, созданным программистами для программистов, познакомиться с RSDN!

Алекс Jenter jenter@rsdn.ru
RSDN Developer

Программирование на Visual C++ Выпуск №41 от 22 апреля 2001 г.

Добрый день, уважаемые подписчики!

Ну что ж, похоже старт у проекта RSDN получился достаточно хороший, особенно если судить по вашим откликам. Большое спасибо всем, кто заглянул на сайт – я уверен, что вы не остались разочарованы. А тем, кто еще не видел RSDN, настоятельно рекомендую посмотреть – наверняка вы найдете что-то интересное для себя. К тому же теперь на сайте появилась полноценная поисковая система.

Как я и обещал, с этого выпуска рассылка начинает публиковать статьи из RSDN, касающиеся программирования на Visual C++. Но не надо думать, что рассылка будет вам бесполезной, если вы  регулярно читаете статьи на сайте. Рассылка будет экономить ваши усилия и ваше время; кроме того, некоторые статьи в рассылке будут появляться даже раньше, чем на сайте. 

СТАТЬЯ  Использование парсера MSXML для работы с XML-документами

Автор: Кен Скрибнер (Kenn Scribner)

Перевод: Александр Шаргин

Источник: "Visual C++ Developer", Ноябрь 2000

Демонстрационный проект XMLNodeExerciser 

Парсер MSXML основывается на объектной модели документа XML (XML Document Object Model, XML DOM). Поэтому важно в первую очередь рассмотреть различные объекты, связанные с документом. Они приведены в таблице 1. Эти объекты позаимствованы прямо из спецификаций XML. MSXML предпренимает дополнительные усилия для стыковки объектов XML DOM с моделью COM. Благодаря этому достаточно просто установить, какому объекту модели XML DOM соответствует тот или иной COM-интерфейс MSXML. Например, IXMLDOMNode представляет DOM-объект Node (узел).

Таблица 1. Объекты XML DOM и их использование

Объект DOM Назначение
DOMImplementation Объект, который можно запросить об уровне поддержки модели DOM
DocumentFragment Представляет часть дерева (хорошо подходит для операций Вырезать/Вставить)
Document Представляет узел верхнего уровня в дереве
NodeList Объект-итератор для доступа к узлам XML
Node Расширяет базовое понятие помеченного элемента (tagged element) в XML
NamedNodeMap Поддержка пространства имён и итерации для коллекций атрибутов
CharacterData Объект для манипулирования текстом
Attr Представляет атрибут(ы) элемента
Element Узел, представляющий элемент XML (удобен для доступа к атрибутам)
Text Представляет текст, содержащийся в элементе или атрибуте
CDATASection Используется для отключения разбора и валидации некоторых разделов XML
Notation Содержит нотацию, расположенную в DTD (Document Type Definition, описание типов документа) или в схеме
Entity Представляет разобранную или неразобранную сущность
EntityReference Представляет узел, ссылающийся на некоторую сущность
ProcessingInstruction Представляет инструкцию обработки

Иногда это может сбивать с толку, но объекты XML-документа могут быть (и часто бывают) полиморфными. Так, узел (Node) в то же самое время является элементом (Element). Это вносит путаницу, когда вы решаете, какой объект DOM требуется для совершения некоторого действия. Вы создаёте узлы, используя объект документа (Document), но если вам требуется добавить атрибуты к только что созданному узлу, вам придётся поработать с ним как с одним из элементов. Если в отношениях между объектами и действиями над ними и существует какая-то закономерность, мне пока не удалось открыть её в процессе каждодневной работы. Я постоянно обращаюсь к документации в MSDN, чтобы посмотреть, какой интерфейс предоставляет методы, нужные мне для решения той или иной задачи. Методы различных объектов логически сгруппированы, и, по-видимому, именно этот принцип (группировка логически связанных операций) был использован при проектировании DOM.

Таким образом, весь фокус состоит в том, чтобы получить у парсера MSXML нужный DOM-объект, реализацию которого предоставляет объект COM. Обычная последовательность действий подразумевает создание COM-объекта самого MSXML, у которого затем можно запросить (или получить каким-то другим способом) указатели на другие объекты XML DOM (которые в свою очередь тоже являются COM-объектами).

Демонстрационное приложение, использующее XML DOM

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

• Загружает XML-файл с диска.

• Отыскивает определённый узел и добавляет к нему дочерний узел.

• Находит ещё один узел и отображает содержащийся в нём текст.

• Сохраняет изменённый документ на диск.

Чтобы ещё больше упростить задачу, я жёстко "зашил" в программу имена XML-файлов и узлов. Понятно, что в реальном приложении вы вряд ли примените эту тактику. Но в нашем случае она имеет смысл, так как ещё больше упрощает код, связанный с использованием MSXML.

Как и во многих других случаях, я использовал в своём примере библиотеку ATL как удобную обёртку для всех операций, связанных с COM. Поэтому вы непременно увидете, как я использую объекты CComPtr и CComQIPtr. Для ровного счёта я добавил к ним также объекты CComBSTR и CComVariant. Если они вам не знакомы, просто запомните, что они являются шаблонами и сами заботятся о многих деталях, которые для наших целей несущественны. Для нас важно рассмотреть, каким образом искать узлы XML, добавлять новые узлы и отображать содержащийся в них текст.

Моё консольное приложение будет загружать XML-документ под названием xmldata.xml (предполагается, что он лежит в одном каталоге с исполняемым файлом), содержащий следующие данные:

<?xml version="1.0"?>

<xmldata>

 <xmlnode />

 <xmltext>Hello, World!</xmltext>

</xmldata>

Сначала мы будем искать узел xmlnode, и если найдём, добавим к нему новый узел (с атрибутом) в качестве дочернего. В результате получится документ следующего вида:

<?xml version="1.0"?>

<xmldata>

 <xmlnode>

  <xmlchildnode xml="fun" />

 </xmlnode>

 <xmltext>Hello, World!</xmltext>

</xmldata>

Далее мы напечатаем сообщение, содержащееся в узле xmltext ("Hello, World!"), и сохраним полученный документ в файл updatedxml.xml. После этого вы сможете посмотреть результаты, используя текстовый редактор или Internet Explorer 5.x. Давайте займёмся кодом.

Прежде всего приложение инициализирует библиотеку COM, а затем создаёт экземпляр парсера MSXML:

CComPtr<IXMLDOMDocument> spXMLDOM;

HRESULT hr = spXMLDOM.CoCreateInstance(uuidof(DOMDocument));

if (FAILED(hr)) throw "Unable to create XML parser object";

if (spXMLDOM.p == NULL) throw "Unable to create XML parser object";

Если нам удалось создать экземпляр парсера, мы загружаем в него XML-документ:

VARIANT_BOOL bSuccess = false;

hr = spXMLDOM->load(CComVariant(L"xmldata.xml"), &bSuccess);

if (FAILED(hr)) throw "Unable to load XML document into the parser";

if (!bSuccess) throw "Unable to load XML document into the parser";

Поиск узла осуществляется через объект документа, поэтому мы используем IXMLDOMDocument::selectSingleNode() для обнаружения нужного узла по его имени. Есть и другие способы, но этот наиболее прост, в том случае, если вы точно знаете, какой узел вам требуется.

CComBSTR bstrSS(L"xmldata/xmlnode");

CComPtr<IXMLDOMNode> spXMLNode;

hr = spXMLDOM->selectSingleNode(bstrSS, &spXMLNode);

if (FAILED(hr)) throw "Unable to locate 'xmlnode' XML node";

if (spXMLNode.p == NULL) throw "Unable to locate 'xmlnode' XML node";

Другие методы, о которых вам следует знать, – это IXMLDOMDocument::nodeFromID() и IXMLDOMElement::getElementsByTagName(), которые вы можете использовать, чтобы получить список узлов в документе. Вы также можете обратиться к документу как к дереву и просканировать его (получая дочерний узел, все узлы одного уровня и т. д.).

В любом случае, результатом поиска станет объект узла MSXML, IXMLDOMNode. Узел должен существовать где-то в документе, иначе поиск закончится неудачей. Моё приложение использует его как родителя для совершенно нового узла, который создаётся объектом XML-документа:

CComPtr<IXMLDOMNode> spXMLChildNode;

hr = spXMLDOM->createNode(CComVariant(NODE_ELEMENT), CComBSTR("xmlchildnode"), NULL, &spXMLChildNode);

if (FAILED(hr)) throw "Unable to create 'xmlchildnode' XML node";

if (spXMLChildNode.p == NULL) throw "Unable to create 'xmlchildnode' XML node";

Если парсеру удалось создать новый узел, следующий шаг – разместить его в дереве XML. Метод IXMLDOMNode::appendChild() – как раз то, что нам нужно.

CComPtr<IXMLDOMNode> spInsertedNode;

hr = spXMLNode->appendChild(spXMLChildNode, &spInsertedNode);

if (FAILED(hr)) throw "Unable to move 'xmlchildnode' XML node";

if (spInsertedNode.p == NULL) throw "Unable to move 'xmlchildnode' XML node";

Если родительский узел принял только что созданный узел в качестве дочернего, он вернёт вам ещё один экземпляр IXMLDOMNode, который представляет новый узел. На самом деле, этот новый узел и узел, который вы передали в appendChild(), в точности совпадают. Тем не менее, проверка указателя на добавленный дочерний узел может быть полезной, так как в случае ошибки он примет значение NULL.

Итак, мы уже нашли требуемый узел и добавили к нему дочерний узел; теперь посмотрим, как работать с атрибутами. Представьте себе, что вам нужно добавить к новому дочернему узлу атрибут:

xml="fun"

Сделать это не сложно, но вам придётся переключиться с IXMLDOMNode на IXMLDOMElement, чтобы поработать с узлом как с элементом. На практике это означает, что вам придётся запросить у интерфейса IXMLDOMNode связанный с ним интерфейс IXMLDOMElement, а потом, получив его, вызвать IXMLDOMElement::setAttribute():

CComQIPtr<IXMLDOMElement> spXMLChildElement;

spXMLChildElement = spInsertedNode;

if (spXMLChildElement.p == NULL)

 throw "Unable to query for 'xmlchildnode' XML element interface";

hr = spXMLChildElement->setAttribute(CComBSTR(L"xml"), CComVariant(L"fun"));

if (FAILED(hr)) throw "Unable to insert new attribute";

Ну вот, мы модифицировали исходное XML-дерево, как нам этого хотелось. Приложение уже может сохранить документ на диск, но может сделать и что-нибудь ещё. Например, разыскать ещё один узел и отобразить на экране содержащийся в нём текст. Поскольку искать узлы мы уже умеем, перейдём прямо к извлечению данных.

Для извлечение данных предназначен метод IXMLDOMNode::get_nodeTypedValue(). Данные, которые содержит узел, можно задавать с использованием схемы типов фирмы Microsoft, поэтому вы без труда можете сохранять числа с плавающей точкой, целые числа, строки или любые другие поддерживаемые схемой данные. Тип данных задаётся с использованием атрибута dt:type, например:

<model dt:type="string">SL-2</model>

<year dt:type="int">1992</year>

Если некоторый узел содержит данные заданного типа, вы сможете извлечь их в нужном формате, используя get_nodeTypedValue().  Если тип не задан, по умолчанию он считается текстовым, и парсер вернёт вам VARIANT с содержащимся в нём BSTR. В нашем случае этого достаточно, поскольку узел, который мы ищем, является текстовым и действительно содержит строку. Если нужно, мы всегда сможем отконвертировать её в другое представление, используя средства типа atoi(). А пока просто извлечём строку и отобразим её.

CComVariant varValue(VT_EMPTY);

hr = spXMLNode->get_nodeTypedValue(&varValue);

if (FAILED(hr)) throw "Unable to retrieve 'xmltext' text";

if (varValue.vt == VT_BSTR) {

 // Display the results... since we're not using the

 // wide version of the STL, we need to convert the

 // BSTR to ANSI text for display...

 USES_CONVERSION;

 LPTSTR lpstrMsg = W2T(varValue.bstrVal);

 std::cout << lpstrMsg << std::endl;

} else {

 // Some error

 throw "Unable to retrieve 'xmltext' text";

}

Если нам удалось извлечь значение, связанное с узлом, и если оно оказалось именно того типа, который мы ожидаем (BSTR), мы выводим текст на экран. В противном случае просто выводится сообщение об ошибке. Но вы, в зависимости от ситуации, можете предпринять и другие действия.

Наша последняя задача – сохранить обновлённое XML-дерево на диск, что мы и делаем, используя IXMLDOMDocument::save():

hr = spXMLDOM->save(CComVariant("updatedxml.xml"));

if (FAILED(hr)) throw "Unable to save updated XML document";

Сохранив документ, программа выдаёт на экран короткое сообщение и завершается.

Эта демонстрационная программа вряд ли поразит ваше воображение. Вы могли бы сделать ещё очень много, но я надеюсь, что этот простой пример показал вам, как использовать MSXML в программах на языке C++. Сам по себе парсер – сложный продукт, и я настоятельно рекомендую вам использовать MSDN как справочное руководство по нему. Парсер предоставляет множество интерфейсов, каждый из которых обычно содержит большое количество методов. Несмотря на это, я широко использую парсер в своих про