Применение Windows API
Краткий обзор представленных материалов
Разработка программ зачастую напоминает священный ритуал, построенный на произнесении ряда обязательных магических заклинаний. Особенно это касается Windows приложений. Windows-заклинания позволяют вывести графическое окно, обработать поступающие сообщения. Порядок их следования предопределен священными руководствами. Часто эти руководства заменяются шпаргалкой, кратко фиксирующей основной каркас:
// Каркасное приложение Windows 95
#include <windows.h>
LRESULT CALLBACK WindowFunc(HWND, UINT, WPARAM, LPARAM);
char szWinName[] = "SimpleWin";
int WINAPI WinMain (HINSTANCE hThisInst,HINSTANCE hPrevInst, LPSTR lpszArgs,int nWinMode) {
HWND hwnd;
MSG msg;
WNDCLASS wcl;
wcl.hInstance = hThisInst;
wcl.lpszClassName = szWinName;
wcl.lpfnWndProc = WindowFunc;
wcl.style = 0;
wcl.hIcon = LoadIcon(NULL,IDI_APPLICATION);
wcl.hCursor = LoadCursor(NULL, IDC_ARROW);
wcl.lpszMenuName = NULL;
wcl.cbClsExtra = 0;
wcl.cbWndExtra = 0;
wcl.hbrBackground= (HBRUSH)GetStockObject (WHITE_BRUSH);
if ( !RegisterClass (&wcl) ) return 0;
hwnd = CreateWindow(szWinName, "Kаркас программы для Windows 95", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, CW_USEDEFAULT, HWND_DESKTOP, NULL, hThisInst, NULL);
ShowWindow(hwnd,nWinMode);
UpdateWindow(hwnd);
while (GetMessage(&msg, NULL,0,0) ) {
TranslateMessage (&msg);
DispatchMessage (&msg);
}
return msg.wParam;
}
// Оконная процедура
LRESULT CALLBACK WindowFunc(HWND hwnd,UINT message, WPARAM wParam,LPARAM lParam) {
switch (message) {
case WM_DESTROY:
PostQuitMessage (0);
break;
default:
return DefWindowProc(hwnd,message,wParam,lParam);
}
return 0;
}
Зачастую начинающие шаманы обходятся и без шпаргалок. Обратившись к волшебникам и мастерам, они получают нужный каркас и целую кучу дополнительных наворотов. Каждый из этих подходов имеет свои положительные и отрицательные стороны. И каждый из них постоянно совершенствется впитывая в себя последние достижения технологии программирования. Ряд этих подходов, как мне кажется являются достаточно интересными как для изучения, так и для практического использования.
Почему плохо использовать MFC Как программировать и как не программировать
Библиотека классов MFC является вредной для программиста
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Программирование для Windows считается трудным. Библиотеки классов делают программирование для Windows легче. Это истина или ложь?
bool IsWinProgEasier (Method method) {
if (method == WIN_CLASS_LIBRARIES) return false;
else return true;
}
Поговорим серьезно. Если все, чего Вы хотите — это писать программы, которые являются производными от MFC или OWL, и Вы не заботитесь о непроизводительных затратах, то использование библиотек классов и мастеров приложений — это способ, которым можно идти. Но как только Вы захотите шагнуть вне этого пути, вы окажетесь перед огромными проблемами.
Позвольте привести аналогию. Представьте, что вы покупаете набор Lego блоков. Вы можете купить универсальный набор, или специализированный набор для построения пиратского судна. Если все, что Вы хотите сделать, это создать пиратское судно, то второй вариант предпочтительнее. Но если Вы вдруг попробуете попробуете сделать из него Lego автомобиль, то Вам придется преодолеть несколько проблем. В конечном счете вы придумаете нечто, похожее на автомобиль, который будет иметь забавное колесо управления, использовать якорь для торможения, а водитель будет иметь деревянную культю и черную повязку на его глазе.
После работы с этим набором "пиратского" Лего в течении некоторого времени, Вы станете специалистом в формировании почти всего того, что могло бы быть сделано из универсального комплекта. Вы усвоите разные приемы, подобно тому, как удалить заплату с глаза пирата, как закрасить череп и кости и т.д. В конечном счете вы достигнете таких высот, когда количество знания, которое вы ассимилировали относительно Пиратского набора, будет намного больше, чем базисные принципы и техника, которые вы должны были бы узнать, чтобы использовать универсальный Lego. С той вершины вы будете выбрасывать большие деньги после первых малых затрат, вкладывая капитал во все более сложные (и сложные) Пиратские наборы.
Что же Вам делать? Мой совет: накоротко урезать ваши потери, начав сейчас же изучать программирование для Windows. API Windows – не является красивой или простой вещью. Именно поэтому все эти библиотеки классов стали настолько популярными в первое время. Но если Вы хотите выращивать красивые цветы, вам необходимо будет испачкать ваши руки. Объектное программирование и Windows далеки друг от друга, но я не хочу, чтобы Вы повторно изобретали колесо. Имеются некоторые простые OO методы, которые помогут Вам инкапсулировать уродливое лицо Windows API.
Побочный эффект окажется то, что вы будете способны создавать Windows программы, которые являются достаточно малыми, чтобы быть легко загружаемыми из Интернета. Малые программы загружаются очень быстро – они не нуждаются в чем-либо, имеющемся в MFC dll библиотеках. Я спорю с любым MFC энтузиастом, что он не напишет игру "Морской бой", которая будет меньше по размеру, чем наша, и будет обладать теми же функциональным возможностям.
Давайте же начнем наш просмотр Win32 API с самой простой возможной Windows программы … Hello Windows!.
Рекомендуемая литература:[1]
Brent E. Rector, Joseph M. Newcomer. Win32 Programming. Addison-Wesley
Очень полное и детализированное представление Win32 API. Превосходные ссылки.
И имеется письмо от одного из наших посетителей, Дейва Линенберга (Dave Linenberg).
Я потратил приблизительно 20 минут, просматривая ваш сайт, и действительно наслаждался вашими взглядами на программирование — особенно относительно вздутого характера MFC. Я не мог не поделиться своими наблюдениями.
Я начал писать Windows-программы, использующие API в 1991-1992 годах (обучаясь по первой книги Петцолда)… а затем, слушая все эти разговоры об объектно ориентированном программном обеспечении, я попробовал изучать MFC. Я пролистал книгу Просиса, и проработал все упражнения. Я просмотрел пару сотен страниц исходного текста MFC, и наткнулся на большое количество неописанного наполнения. Я изучил внутреннюю организацию MFC. Я был подготовлен, чтобы действительно понять MFC…., но я этого не смог сделать. Эта библиотека вызывала довольно сильное отвращение. MFC, которая делает простые вещи, является чрезвычайно сложной. Потратив 1 год на сырой API, и на увязку его с некоторыми хорошими объектно ориентированными парадигмами, образцами и книгами по программированию на C++, таким как книги Экела (Eckel) или Майераса (Meyers), можно получить намного больше, чем пытаться заняться MFC. Каждый думает, что написание 5 строк программы в MFC или некотором каркасе, чтобы создать окно — это лучше или проще, чем изучение API. Я согласился бы с этим в том случае, если бы каркас был полностью понят – потому что те 5 строк, сцепленные в тысячи строк программы с небольшими возможностями делают намного больше, чем маломасштабные SDI/MDI книжные примеры программ.
Почему Microsoft не может инкапсулировать библиотеки для C эффективно? К чему все эти непроизводительные затраты?
Сначала я был очарован архитектурой документ/вид. Я еще не знал то, что до этого был соответствующий "образец" (pattern). А через MFC было мое первое с ним столкновение. Поскольку мои программы стали беспорядочными циклическими зависимостями, я, реализуя парадигму документ-вид, понял, что MFC ужасна. По крайней мере, в их реализации этой идеи!! Когда-либо обратите внимание, что примеры программ очень малы в книгах. Большинство книг никогда не касается того, как реализовать взаимодействия больших наборов классов. Что было бы, если бы я имел большую программу с 1000 видами, и 1000 документами, и все они находились бы во взаимосвязи. Все передавли бы сообщения. Что, если бы это была многопотчная или распределенная программа…., Какой был бы беспорядок при использовании архитектуры документ/вид, реализованной с использованием MFC. Вот такие пироги!
«Hello Windows!» в классовой обертке
Простейшая Windows программа
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Прежде, чем приступить к программированию для Windows, необходимо понять, как выполняется представленная здесь самая простая программа. Обратите внимание: это — Win32-программа. Она будет выполняться под управлением Windows 95 и Windows NT (если кто-то хочет, чтобы Вы программировали для 16-разрядной платформы, то он должен платить Вам вдвое больше!). Windows API вызовы окрашены в синий цвет, а специфические для Windows типы данных окрашены зеленым. Я буду также ставить два двоеточия перед обращениями к функциям API. В C++ это означает вызов глобальной функции и позволяет, в ряде случаев, избавиться от неоднозначности.
Исходные тексты программы расположены на сервере Reliable software (чужого стараюсь не держать [А.Л.]). Не забудьте откомпилировать его как приложение Windows. Например, в Visual C++ выберите File.New.Projects.Win32 Application. Иначе вы получите ошибку: нерешенный внешний _main. (я обеспечил проектным файлом тех, кто используют MS VC++ 6.0)
Сначала Вы должны определить классы окон, которые будут отображаться вашим приложением. В данном случае мы отобразим только одно окно (WinClass), но тем не менее, мы должны дать Windows некоторую минимальную информацию относительно его класса. Наиболее важная часть WinClass — адрес процедуры обратного вызова, или оконной процедуры (WindowProcedure). Windows, в соответствии с внутренней организацией, вызывает нас — он посылает сообщения нашей программе, вызывая оконную процедуру.
Обратите внимание на объявление оконной процедуры. Windows будет вызывать ее, передавая дескриптор текущего окна и два элемента данных, связанных с сообщением (параметры сообщения): WPARAM и LPARAM.
В WinClass мы также должны определить дескриптор экземпляра программы HINSTANCE, курсор мыши (мы лишь загружаем стандартный курсор – стрелку), кисть, чтобы закрасить фон окна (мы выбрали заданный по умолчанию цвет окна) и имя нашего класса.
После заполнения всех полей структуры WNDCLASS мы регистрируем класс окна в Windows.
#include <windows.h>
LRESULT CALLBACK WindowProcedure(HWND hwnd, unsigned int message, WPARAM wParam, LPARAM lParam);
class WinClass {
public:
WinClass (WNDPROC winProc, char const * className, HINSTANCE hInst);
void Register() {
::RegisterClass (&_class);
}
private:
WNDCLASS _class;
};
WinClass::WinClass(WNDPROC winProc, char const * className, HINSTANCE hInst) {
_class.style = 0;
_class.lpfnWndProc = winProc; // оконная процедура: обязательна
_class.cbClsExtra = 0;
_class.cbWndExtra = 0;
_class.hInstance = hInst; // владелец класса: обязательный
_class.hIcon = 0;
_class.hCursor = ::LoadCursor (0, idc_arrow); // optional
_class.hbrBackground = (HBRUSH) (COLOR_WINDOW + 1); // optional
_class.lpszMenuName = 0;
_class.lpszClassName = className; // обязательно
}
Как только Класс Окна зарегистрирован, мы можем продолжить создание окна. Для этого вызываем функцию API CreateWindow. У нее много параметров: имя только что зарегистрированного класса окна, заголовок, появляющийся в названии окна, стиль, положение на экране и размер, а также дескриптор экземпляра приложения. Остальные параметры в данный момент оставлены обнуленными.
Окно не будет появляться на экране до тех пор, пока Вы не скажете, чтобы Windows показал его.
class WinMaker {
public:
WinMaker(): _hwnd (0) {}
WinMaker (char const* caption, char const* className, HINSTANCE hInstance);
void Show (int cmdShow) {
::ShowWindow(_hwnd, cmdshow);
::UpdateWindow(_hwnd);
}
protected:
HWND _hwnd;
};
WinMaker::WinMaker(char const * caption, char const * className, HINSTANCE hInstance) {
_hwnd = :: CreateWindow(
className, // имя регистрируемого оконного класса
caption, // заголовок окна
WS_OVERLAPPEDWINDOW, // стиль окна
CW_USEDEFAULT, // позиция x
CW_USEDEFAULT, // позиция y
CW_USEDEFAULT, // ширина
CW_USEDEFAULT, // высота
0, // handle to parent window
0, // handle to menu
hInstance, // дескриптор экземпляра
0); // дата создания (window creation data)
}
Windows программа управляется событиями. Это означает, что Вам, как программисту, полагается находиться в обороне. Пользователь будет бомбардировать Windows различными внешними действиями, а Windows будет бомбардировать вашу программу сообщениями, соответствующими этим действиям. Все, что Вы должны делать — это отвечать на сообщения. Рисунок ниже схематично показывает как все это работает.
Каждое сообщение адресовано определенному окну. Когда Вы запрашиваете сообщение у Windows, система выяснит класс вашего окна, найдет связанную с ним оконную процедуру, и вызовет ее. Любое сообщение, посланное нашему окну может обрабатываться в нашей оконной процедуре. Нам остается только отреагировать на его. И что? Мы должны отвечать соответстветствующим образом на всевозможные сообщения Windows? Там их сотни! К счастью, нет! Мы должны перехватывать только те сообщения, в которых заинтересованы. Все остальные мы возвращаем обратно в Windows для обработки по умолчанию, используя DefWindowProc.
Windows получает различные события от клавиатуры, мыши, портов, и т.д. Каждое событие быстро преобразуется в сообщение. Windows посылает сообщения, соответствующим окнам. Например, все сообщения от клавиатуры идут к окну, которое в настоящее время имеет фокус ввода (активное окно). Сообщения мыши посылаются согласно позиции курсора мыши. Они обычно идут к окну, которое расположено непосредственно под курсором (если какая-нибудь программа не захватила мышь).
Все эти сообщения заканчиваются в очередях сообщений. Windows поддерживает очередь сообщений для каждой выполняющейся прикладной программы (фактически, для каждого потока). Ваша задача состоит в последовательном получении этих сообщений в так называемом цикле сообщений (message loop). Для этого программа должна вызывать GetMessage. Затем вызывается DispatchMessage, чтобы отдать сообщение обратно Windows. Разве сама Windows не может посылать все эти сообщения самостоятельно? В принципе это возможно, но цикл сообщений дает вашей программе возможность посмотреть на них и, если это необходимо, выполнить некоторые дополнительные действия перед возвратом. Или не выполнять…
Давайте рассмотрим WinMain. Выполнение Windows программы не начинается с функции main — оно начинается с WinMain. Сначала, мы создаем winclass и регистрируем его. Затем мы создаем экземпляр окна (на основе только что зарегистрированного класса) и отображаем его. В общем случае WinMain вызывается с соответствующей директивой show. Пользователь может запустить приложение со свернутым или развернутым окном. Так что мы только следуем этой директиве. Затем мы запускаем цикл сообщения, в котором обрабатываем и посылаем сообщения до тех пор, пока GetMessage не возвратит 0. В этот момент параметр wparam сообщения будет содержать код возврата для всей программы.
int WINAPI WinMain(hinstance hinst, hinstance hprevinst, char * cmdParam, int cmdShow) {
char className [] = "Winnie";
WinClass winClass(WindowProcedure, className, hInst);
winClass.Register();
WinMaker win("Hello Windows!", className, hInst);
win.Show(cmdShow);
MSG msg;
int status;
while ((status = ::GetMessage(&msg, 0, 0, 0)) != 0) {
if (status == –1) return –1;
::DispatchMessage(&msg);
}
return msg.wParam;
}
Функция API GetMessage – интересный пример причудливой troolean (в противоположность традиционной Boolean) логики Microsoft. GetMessage определена таким образом, чтобы возвратить BOOL, но в документации определяется три варианта возвращаемых значений: ненулевых, нуля и –1. Я это не выдумал! Приведу цитату из справки:
Если функция передает сообщение, иное чем WM_QUIT, возвращаемое значение отлично от нуля.
Если же функция выдает сообщение WM_QUIT, возвращаемое значение — нуль.
При возникновении ошибки возвращаемое значение равно –1.
Другая часть Windows программы — оконная процедура. Помните, что Windows вызывает ее при обработке всех сообщений. Эти сообщения могут игнорироваться, если их пересылать к DefWindowProc. Только одно сообщение мы всегда обязаны перехватывать. Это WM_DESTROY, посылаемое самой Windows в тот момент, когда пользователь закрывает окно (нажимая кнопку закрытия в заголовке окна). Стандартный ответ на WM_DESTROY заключается в посылке сообщения о выходе из программы со значением нуля в качестве кода возврата. Вот и все, что можно сказать по данной теме.
// Window Procedure called by Windows
LRESULT CALLBACK WindowProcedure(HWND hwnd, unsigned int message, WPARAM wParam, LPARAM lParam) {
switch (message) {
case WM_DESTROY:
::PostQuitMessage (0);
return 0;
}
return ::DefWindowProc(hwnd, message, wparam, lparam);
}
Выше рассмотрена самая "уродливая" и менее всего поддающаяся инкапсуляции (при попытке использовать объектно-ориентированный подход) часть Windows . Она станет гораздо лучше, если разрабатывать программу так, как это предлагается в обобщенной Windows программе.
(обратно)Windows и «Модель-Вид-Контроллер»
Обобщенная Windows программа
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Эта программа использует набор базовых классов, которые инкапсулируют Windows API
• Controller (Контроллер) — Мост между оконной процедурой и объектно-ориентированным миром.
• View (Вид) — Инкапсулирует вывод Windows программы.
• Canvas (Холст) — Инкапсулирует различные контексты устройств и действия, которые Вы можете сделать с их использованием.
• Model (Модель) — Работник и мозг вашей программы. Вообще не имеет дело с Windows.
Обратите внимание: это Win32 программа — она м.б. запущена под Windows 95, 98, NT, 2000, Me.
Обратите внимание: _set_new_handler — это специфика Microsoft. Если вы используете другой компилятор, то скорее удалите эту строку из кода. Согласно текущему стандарту C++, оператор new должен выбрасывать исключения в любом случае (VC++ сейчас тоже поддерживает стандарт. А.Л. ).
Обратите внимание: Старые компиляторы могут иметь проблемы с шаблонами (Вряд ли кто использует такие старые компиляторы для программирования под Windows. А.Л. ). В этом случае вы можете заменить используемые шаблоны типа Win[Get/Set]Long прямыми вызовами Get/SetWindowLong. Например, вместо вызова
Controller * pCtrl = WinGetLong<CONTROLLER *> (hwnd);
вы можете записать
Controller * pCtrl = reinterpret_cast<Controller *> (::GetWindowLong (hwnd, GWL_USERDATA));
Загрузка упакованных исходных текстов Generic (11 кб).
WinMain
При запуске WinMain, создается класс окна и главное окно нашего приложения. Я инкапсулировал эти действия внутри двух классов: WinClass и WinMaker. WinClass может также сообщать нам о том, что уже выполняются другие экземпляры нашей программы. Когда подобное случается в нашем примере, мы просто активизируем уже выполняющийся экземпляр программы и выходим из запускаемого приложения. Так необходимо поступать тогда, когда Вы хотите, чтобы в один момент времени выполнялся только один экземпляр вашей программы.
При успешном создании главного окна, мы входим в цикл обработки сообщений. Обратите внимание, что в этот раз функцией TranslateMessage обрабатываются клавиатурные сообщения. Дело в том, что наша программа имеет пункты меню, к которым можно обращаться, используя комбинации Alt+key.
Другим интересным моментом этой программы является то, что мы больше не используем строки для обозначения наших ресурсов. Мы используем числовые идентификаторы (ids). Более того, мы используем их даже тогда, когда осуществляются API вызовы таких строк, как имя класса окна или заголовок окна. Мы сохраняем все строки в строковых ресурсах и обращаемся к ним через идентификаторы (ids). Ваша среда разработки для Windows скорее всего имеет редактор ресурсов, который позволяет Вам создавать иконки, меню, строковые ресурсы и назначать им соответствующие числовые идентификаторы. Символические имена этих ids сохранены в файле заголовка, сгенерированном таким редактором. В нашем случае он назван "resource.h".
Константа, ID_MAIN, например, ссылается на иконки основной программы (большую и малую в том же самом ресурсе), главное меню, и строку с именем оконного класса. ID_CAPTION ссылается на строку заголовка окна. Такая организация данных поддерживает возможность многократного использования кода, не говоря уже о легкости локализации.
int WINAPI WinMain (HINSTANCE hInst, HINSTANCE hPrevInst, char* cmdParam, int cmdShow) {
_set_new_handler(&NewHandler);
// Using exceptions here helps debugging your program
// and protects from unexpected incidents.
try {
// Create top window class
TopWinClass topWinClass(ID_MAIN, hInst, MainWndProc);
// Is there a running instance of this program?
HWND hwndOther = topWinClass.GetRunningWindow ();
if (hwndOther != 0) {
::SetForegroundWindow(hwndOther);
if (::IsIconic(hwndOther)) ::ShowWindow(hwndOther, SW_RESTORE);
return 0;
}
topWinClass.Register();
// Create top window
ResString caption(hInst, ID_CAPTION);
TopWinMaker topWin(topWinClass, caption);
topWin.Create();
topWin.Show(cmdShow);
// The main message loop
MSG msg;
int status;
while ((status = ::GetMessage(&msg, 0, 0, 0)) != 0) {
if (status == –1) return –1;
::TranslateMessage(&msg);
::DispatchMessage(&msg);
}
return msg.wParam;
} catch(WinException e) {
char buf [50];
wsprintf(buf, "%s, Error %d", e.GetMessage(), e.GetError());
::MessageBox(0, buf, "Exception", MB_ICONEXCLAMATION | MB_OK);
}
catch (…) {
::MessageBox(0, "Unknown", "Exception", MB_ICONEXCLAMATION | MB_OK);
}
return 0;
}
WinClass
Давайте, рассмотрим WinClass. Он инкапсулирует предопределенную в Windows структуру WNDCLASSEX и обеспечивает приемлемые значения по умолчанию для всех ее полей. Этот класс получен из более простого класса WinSimpleClass, который Вы могли бы использовать, чтобы инкапсулировать некоторые встроенные в Windows классы (такие как кнопки, списки просмотров, и т.д.).
Я обеспечил примеры методами, которые могут использоваться, чтобы перестроить значения, устанавливаемые по умолчанию. Например, SetBgSysColor изменяет заданный по умолчанию цвет заднего фона окна к одному из предопределенных цветов системы. Метод SetResIcons загружает соответствующие иконки из ресурсов и присоединяетих к оконному классу. Эти иконки затем появятся в верхнем левом углу основного окна и на панели задач Windows.
TopWinClass наследует от WinClass и использует этот метод. Он также подцепляет меню в вершине оконного класса.
class WinSimpleClass {
public:
WinSimpleClass(char const * name, HINSTANCE hInst) : _name (name), _hInstance (hInst) {}
WinSimpleClass (int resId, HINSTANCE hInst);
char const* GetName() const { return _name.c_str (); }
HINSTANCE GetInstance() const { return _hInstance; }
HWND GetRunningWindow();
protected:
HINSTANCE _hInstance;
std::string _name;
};
WinSimpleClass::WinSimpleClass(int resid, hinstance hinst) : _hInstance (hInst) {
ResString resStr (hInst, resId);
_name = resStr;
}
HWND WinSimpleClass::GetRunningWindow () {
HWND hwnd = ::FindWindow(getname(), 0);
if (::IsWindow(hwnd)) {
HWND hwndPopup = ::GetLastActivePopup(hwnd);
if (::IsWindow(hwndpopup)) hwnd = hwndPopup;
} else hwnd = 0;
return hwnd;
}
class WinClass: public WinSimpleClass {
public:
WinClass(char const* className, HINSTANCE hInst, WNDPROC wndProc);
WinClass(int resId, HINSTANCE hInst, WNDPROC wndProc);
void SetBgSysColor (int sysColor) {
_class.hbrBackground = reinterpret_cast<HBRUSH> (sysColor + 1);
}
void SetResIcons(int resId);
void Register();
protected:
void SetDefaults();
WNDCLASSEX _class;
};
WinClass::WinClass(char const * classname, HINSTANCE hInst, WNDPROC wndProc) : WinSimpleClass (className, hInst) {
_class.lpfnWndProc = wndProc;
SetDefaults();
}
WinClass::WinClass(int resid, hinstance hinst, wndproc wndproc) : WinSimpleClass (resId, hInst) {
_class.lpfnWndProc = wndProc;
SetDefaults();
}
void WinClass::SetDefaults () {
// Provide reasonable default values
_class.cbSize = sizeof (WNDCLASSEX);
_class.style = 0;
_class.lpszClassName = GetName();
_class.hInstance = GetInstance();
_class.hIcon = 0;
_class.hIconSm = 0;
_class.lpszMenuName = 0;
_class.cbClsExtra = 0;
_class.cbWndExtra = 0;
_class.hbrBackground = reinterpret_cast<HBRUSH>(COLOR_WINDOW + 1);
_class.hCursor = ::LoadCursor(0, IDC_ARROW);
}
void WinClass::SetResIcons (int resid) {
_class.hIcon = reinterpret_cast<HICON>(::LoadImage(_class.hInstance, MAKEINTRESOURCE(resId), IMAGE_ICON, ::GetSystemMetrics(sm_cxicon), ::GetSystemMetrics(sm_cyicon), 0));
// Small icon can be loaded from the same resource
_class.hIconSm = reinterpret_cast<HICON>(::LoadImage(_class.hInstance, MAKEINTRESOURCE(resId), IMAGE_ICON, :: GetSystemMetrics(sm_cxsmicon), ::GetSystemMetrics(sm_cysmicon), 0));
}
void WinClass::Register () {
if (::RegisterClassEx(&_class) == 0) throw WinException("Internal error: RegisterClassEx failed.");
}
class TopWinClass: public WinClass {
public:
TopWinClass(int resId, HINSTANCE hInst, WNDPROC wndProc);
};
TopWinClass::TopWinClass(int resid, HINSTANCE hInst, WNDPROC wndProc) : WinClass (resId, hInst, wndProc) {
SetResIcons(resId);
_class.lpszMenuName = MAKEINTRESOURCE(resId);
}
После того, как оконный класс зарегистрирован системой, Вы можете создать столько окон этого класса, сколько пожелаете. Они, конечно, совместно используют ту же самую оконную процедуру, которая была зарегистрирована классом. Как будет показано дальше, мы можем различать между собой разные экземпляры окна внутри этой процедуры.
WinMaker
Класс WinMaker организован аналогично WinClass. Его конструктор устанавливает значения по умолчанию, которые могут быть переустановлены вызовом специфических методов. После завершения всех установок, Вы вызываете метод Create, чтобы создать окно, и метод Show, чтобы отобразить его. Обратите внимание, что в тот момент, когда Вы вызываете Create, ваша оконная процедура вызывается с сообщением WM_CREATE.
Верхнее окно создано с использованием класса TopWinMaker, который обеспечивает соответствующий стиль и заголовок.
class WinMaker {
public:
WinMaker(WinClass& winClass);
operator HWND() { return _hwnd; }
void AddCaption(char const * caption) {
_windowName = caption;
}
void AddSysMenu() { _style |= WS_SYSMENU; }
void AddVScrollBar() { _style |= WS_VSCROLL; }
void AddHScrollBar() { _style |= WS_HSCROLL; }
void Create();
void Show(int nCmdShow = SW_SHOWNORMAL);
protected:
WinClass& _class;
HWND _hwnd;
DWORD _exStyle; // extended window style
char const* _windowName; // pointer to window name
DWORD _style; // window style
int _x; // horizontal position of window
int _y; // vertical position of window
int _width; // window width
int _height; // window height
HWND _hWndParent; // handle to parent or owner window
HMENU _hMenu; // handle to menu, or child-window id
void * _data; // pointer to window-creation data
};
WinMaker::WinMaker(WinClass& winclass) : _hwnd(0), _class(winClass), _exStyle(0), // extended window style
_windowName (0), // pointer to window name
_style(WS_OVERLAPPED), // window style
_x(CW_USEDEFAULT), // horizontal position of window
_y(0), // vertical position of window
_width(CW_USEDEFAULT), // window width
_height(0), // window height
_hWndParent(0), // handle to parent or owner window
_hMenu(0), // handle to menu, or child-window id
_data(0) // pointer to window-creation data
{ }
void WinMaker::Create() {
_hwnd = ::CreateWindowEx(_exStyle, _class.GetName(), _windowName, _style, _x, _y, _width, _height, _hWndParent, _hMenu, _class.GetInstance(), _data);
if (_hwnd == 0) throw WinException ("Internal error: Window Creation Failed.");
}
void WinMaker::Show(int nCmdShow) {
::ShowWindow(_hwnd, nCmdShow);
::UpdateWindow(_hwnd);
}
// Makes top overlapped window with caption
TopWinMaker::TopWinMaker((WinClass& winclass, char const* caption) : WinMaker(winClass) {
_style = WS_OVERLAPPEDWINDOW | WS_VISIBLE;
_windowName = caption;
}
Классы общего назначения
Прежде, чем идти дальше, рассмотрим некоторые простые классы общего назначения. WinException — нечто, что мы хотим использовать для исключений во время сбоев Windows API. Он заботится о восстановлении кода ошибки Windows. (Между прочим, имеется простой способ преобразовать код ошибки в строку функцией API FormatMessage.)
Класс ResString просто инкапсулирует строку, хранимую в строковых ресурсах вашего приложения.
// The exception class: stores the message and the error code class
WinException {
public:
WinException(char* msg) : _err(::GetLastError()), _msg(msg) {}
DWORD GetError() const { return _err; }
char const* GetMessage() const { return _msg; }
private:
DWORD _err;
char * _msg;
};
// The out-of-memory handler: throws exception
int NewHandler(size_t size) {
throw WinException( "Out of memory");
return 0;
}
class ResString {
enum { MAX_RESSTRING = 255 };
public:
ResString(HINSTANCE hInst, int resId);
operator char const*() { return _buf; }
private:
char _buf[MAX_RESSTRING + 1];
};
ResString::ResString(hinstance hinst, int resid) {
if (!::LoadString(hinst, resid, _buf, max_resstring + 1)) throw WinException ("Load String failed");
}
Controller
Контроллер — нервная система отдельного экземпляра окна. Он создается с этим окном, хранится с ним и, в заключение, разрушается вместе с ним. Вы можете помещать любую информацию о состоянии, имеющую отношение к специфическому экземпляру окна в его контроллер. Вообще же, контроллер содержит "Вид", который имеет дело с рисованием на поверхности окна, и он имеет доступ к "Модели", которая является мозгом вашего приложения (все это называется MVC, или образцом "Модель-Вид-Контроллер" ("Model-View-Controller"), изобретенным Smalltalk-программистами.
Если, как это часто бывает, ваше приложение имеет только одно окно верхнего уровня, Вы можете непосредственно включать модель в ее контроллер. Это упрощает управление ресурсами, но ценой усиления связи контроллера с моделью. В больших проектах нужно избегать таких связей. Предпочтительнее использовать внутри контроллера "интеллектуальный" указатель на модель.
Большинство методов контроллера требует дескриптора окна, с которым они взаимодействуют. Этот дескриптор передается с каждым сообщением Windows, но проще сохранить его один раз внутри контроллера и использовать всякий раз, когда он необходим. Помните — имеется взаимно однозначное соответствие между контроллерами и экземплярами окон (а следовательно, и их дескрипторами).
class Controller {
public:
Controller(HWND hwnd, CREATESTRUCT * pCreate);
~Controller();
void Size(int x, int y);
void Paint();
void Command(int cmd);
private:
HWND _hwnd;
Model _model;
View _view;
};
Оконная процедура — основной коммутационный узел Windows приложения. Вы не вызываете ее из вашей программы — ее вызывает Windows! Каждый раз когда случается что-то интересное, Windows посылает вашей программе сообщение. Это сообщение передается оконной процедуре. Вы можете обработать его, или передать оконной процедуре, заданной по умолчанию.
Оконная процедура вызывается с указанием дескриптора к окна, к которому направлено данное сообщение. Этот дескриптор однозначно идентифицирует внутреннюю структуру данных Windows, которая соответствует экземпляру окна. Это так часто случОконная процедура вызывается с указанием дескриптора к окна, к которому направлено данное сообщение. Этот дескриптор однозначно идентифицирует внутреннюю структуру данных Windows, которая соответствует экземпляру окна. Это так часто случается, что мы можем обращаться к этой структуре данных и использовать ее, чтобы сохранить некоторые специфические для экземпляра данные. Имеется типовой безопасный способ доступа к этой структуре. Между прочим, элемент GWL_USERDATA этой структуры гарантированно присутствует во всех окнах, включая окна сообщения, диалоговые окна и даже кнопки.
template <class T> inline T
WinGetLong(hwnd hwnd, int which = gwl_userdata) {
return reinterpret_cast<T>(::GetWindowLong (hwnd, which));
}
template <class T> inline void
WinSetLong(hwnd hwnd, t value, int which = gwl_userdata) {
::SetWindowLong(hwnd, which, reinterpret_cast<long>(value));
}
Каждый раз, когда Windows вызывает нашу оконную процедуру, мы хотим сначала восстановить ее контроллер. Вспомните, что может быть несколько окон, совместно использующих ту же самую оконную процедуру, и мы хотим иметь отдельный контроллер для каждого окна. Как мы узнаем, какой из контроллеров используетсять, когда произходит обратный вызов оконной процедуры? Мы можем выяснить это, рассмотрев дескриптор окна. В этом дескрипторе мы сохраняем указатель на контроллер данного окна, используя функцию Win[Set/Get]Long.
Оконная процедура сначала вызывается с сообщением WM_CREATE. В этот момент мы создаем экземпляр контроллера, нициализируем его дескриптором окна и специальной структурой данных по имени CREATESTRUCT, которая передана нам от Windows. Если же мы уже имеем контроллер, то сохраняем указатель на его в соответствующей внутренней Windows-структуре данных помеченной текущим hwnd. В следующий раз оконная процедура вызывается с сообщением, отличным от WM_CREATE, и мы просто восстанавливаем (отыскиваем) указатель на наш контроллер, используя hwnd.
Остальное просто. Оконная процедура интерпретирует параметры сообщения и вызывает соответствующие методы контроллера.
LRESULT CALLBACK WndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) {
Controller * pCtrl = WinGetLong<Controller *>(hwnd);
switch (message) {
case WM_CREATE: // Have to catch exception in case new throws!
try {
pCtrl = new Controller(hwnd, reinterpret_cast<CREATESTRUCT *>(lParam));
WinSetLong<Controller *>(hwnd, pCtrl);
} catch (WinException e) {
::MessageBox(hwnd, e.GetMessage(), "Initialization", MB_ICONEXCLAMATION | MB_OK);
return –1;
} catch (…) {
:: MessageBox(hwnd, "Unknown Error", "Initialization", MB_ICONEXCLAMATION | MB_OK);
return –1;
}
return 0;
case WM_SIZE:
pCtrl->Size(LOWORD(lParam), HIWORD(lParam));
return 0;
case WM_PAINT:
pCtrl->Paint();
return 0;
case WM_COMMAND:
pCtrl->Command(LOWORD(wParam));
return 0;
case WM_DESTROY:
WinSetLong<Controller *>(hwnd, 0);
delete pCtrl;
return 0;
}
return ::DefWindowProc(hwnd, message, wparam, lparam);
}
Ниже представлены примеры простых реализаций нескольких методов построения контроллеров. Конструктор должен помнить дескриптор окна для более позднего использования, деструктор должен посылать сообщение выхода (quit), метод Size передает его параметр Просмотру (Экрану), и т.д. Мы будем говорить о рисовании в окне немного позже. Теперь, обратите внимание, что контроллер готовит поверхность "Холста" для работы "Вида".
Controller::Controller(HWND hwnd, CREATESTRUCT* pCreate) :_hwnd (hwnd), _model ("Generic") { }
Controller::~Controller() {
:: PostQuitMessage(0);
}
void Controller::Size (int cx, int cy) {
_view.SetSize (cx, cy);
}
void Controller::Paint () {
// prepare the canvas and let View do the rest
PaintCanvas canvas(_hwnd);
_view.Paint(canvas, _model);
// Notice: The destructor of PaintCanvas called automatically!
}
Когда пользователь выбирает один из пунктов меню, оконная процедура вызывается с сообщением WM_COMMAND. Соответствующий метод контроллера посылает команду, основанную на id команды. Когда Вы создаете меню, используя редактор ресурса, Вы выбираете эти идентификаторы команд для каждого пункта меню. Они сохранены в соответствующем заголовочном файле ("resource.h" в нашем случае), который должен быть включен в исходный файл контроллера.
Наше меню содержит только три пункта с идентификаторами IDM_EXIT, IDM_HELP, и IDM_ABOUT. Диалоговое окно, которое отображается в ответ на IDM_ABOUT, также создано с использованием редактора ресурсов и имеет id IDD_ABOUT. Его процедура диалога — AboutDlgProc.
И, наконец, чтобы отобразить диалоговое окно, нам нужен дескриптор экземпляра приложения. Стандартный способ восстанавить (отыскать) его состоит в том, чтобы обратиться к внутренней структуре данных Windows, используя соответствующий hwnd.
// Menu command processing
void Controller::Command (int cmd) {
switch (cmd) {
case IDM_EXIT:
::SendMessage(_hwnd, wm_close, 0, 0l);
break;
case IDM_HELP:
::MessageBox(_hwnd, "go figure!", "Generic", MB_ICONINFORMATION | MB_OK);
break;
case IDM_ABOUT: {
// Instance handle is available through HWND
HINSTANCE hInst = WinGetLong<HINSTANCE>(_hwnd, GWL_HINSTANCE);
::DialogBox(hInst, MAKEINTRESOURCE(IDD_ABOUT), _hwnd, AboutDlgProc);
}
break;
}
}
View, Canvas
Объект "Вид" (Экранный объект) обычно хранит размеры клиентской области. Они обновляются всякий раз, когда контроллер обрабатывает сообщение WM_SIZE. Первое сообщение WM_SIZE посылается во время создания окна и до посылки WM_PAINT, поэтому мы можем безопасно принимать, его. Когда вызывается Paint, размерности клиентской области уже известны.
Графический вывод к окну осуществляется, вызывом соответствующих методов объекта Canvas. В нашем случае, мы печатаем текст, полученный из модели и рисуем вертикальную строку в десяти пикселах от левого края клиентской области.
class View {
public:
void SetSize(int cxNew, int cyNew) { _cx = cxNew; _cy = cyNew; }
void Paint(Canvas& canvas, Model& model);
protected:
int _cx; int _cy;
};
void View::Paint (Canvas& canvas, Model& model) {
canvas.Text(12, 1, model.GetText(), model.GetLen());
canvas.Line(10, 0, 10, _cy);
}
Объект "Холст" инкапсулирует то, что, на языке Windows, называется Контекстом устройства. Наш Холст очень прост, он знает только, как печатать текст и рисовать линии, но ваш Холст может иметь много больше методов, которые выполняют творческие функции. Мы больше расскажем о Холсте при описании одной из следующих обучающих программ.
class Canvas {
public:
operator HDC() { return _hdc; }
void Line(int x1, int y1, int x2, int y2) {
::MoveToEx(_hdc, x1, y1, 0);
::LineTo(_hdc, x2, y2);
}
void Text(int x, int y, char const* buf, int cBuf) {
::TextOut(_hdc, x, y, buf, cbuf);
}
void Char(int x, int y, char c) {
::TextOut(_hdc, x, y, &c, 1);
}
protected:
// Protected constructor: You can't construct
// a Canvas object, but you may be able
// to construct objects derived from it.
Canvas(HDC hdc): _hdc (hdc) {}
HDC _hdc;
};
Холсты, который Вы создаете, в ответ на сообщение WM_PAINT, имеет специальный вид. Они получают контекст устройства, вызывая BeginPaint и отдают его, вызывая EndPaint. PAINTSTRUCT содержит дополнительную информацию, о некоторой части рабочей области, которая должна быть перерисована, и т.д. Пока мы игнорируем некоторые подробности, но если вы серьезно относитесь к эффективности, Вы должны изучить это более детально.
// Concrete example of canvas.
// Create this object after WM_PAINT message
class PaintCanvas: public Canvas {
public:
// Constructor obtains the DC
PaintCanvas(HWND hwnd) : Canvas (:: BeginPaint(hwnd, &_paint)), _hwnd (hwnd) {}
// Destructor releases the DC
~PaintCanvas () {
::EndPaint(_hwnd, &_paint);
}
protected:
PAINTSTRUCT _paint;
HWND _hwnd;
};
Далее: Разве можно программировать в Windows без использования элементов управления?
(обратно)Классовая обертка для элементов управления
Элементы управления Windows
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Элементы управления могут быть добавлены к основному окну или к любому диалоговому окну вашей программы. Их лучше всего выбрать и позиционировать, используя графический редактор ресурсов. Такой редактор позволяет задавать символические имена, которые можно использовать для идентификации элементов управления.
Большинство средств управления можно инкапсулировать в объектах, которые внедрены или в соответствующий "Контроллер" (Вы можете иметь отдельные объекты Controller для каждого диалогового окна программы), или, для статических элементов управления, в "Виде".
Объекты — "Контроллеры" создаются при обработке сообщения WM_CREATE или, в случае диалоговых окон, сообщением WM_INITDIALOG. При этом выполняются конструкторы элементов управления, внедренных в эти "Контроллеры".
Базовым классом для большинства элементов управления является SimpleControl. Он получает и сохраняет дескриптор окна специфического элемента управления. Чтобы получить этот дескриптор, необходимо иметь дескриптор родительского окна и идентификатор элемента управления.
class SimpleControl {
public:
SimpleControl(HWND hwndParent, int id) : _hWnd(GetDlgItem(hwndParent, id)) {}
void SetFocus() {
::SetFocus (_hwnd);
}
HWND Hwnd() const { return _hWnd; }
protected:
HWND _hWnd;
};
Ниже представлен пример элемента управления редактированием.
class Edit: public SimpleControl {
public:
Edit(HWND hwndParent, int id) : SimpleControl (hwndParent, id) {}
void SetString(char* buf) {
SendMessage(Hwnd(), WM_SETTEXT, 0, (LPARAM)buf);
}
// code is the HIWORD (wParam)
static BOOL IsChanged (int code) {
return code == EN_CHANGE;
}
int GetLen() {
return SendMessage(Hwnd(), WM_GETTEXTLENGTH, 0, 0);
}
void GetString(char* buf, int len) {
SendMessage(Hwnd(), WM_GETTEXT, (WPARAM)len, (LPARAM)buf);
}
void Select() {
SendMessage(Hwnd(), EM_SETSEL, 0, –1);
}
};
Здесь показано, как элемент управления редактированим может использоваться:
class Controller {
public:
Controller(HWND hwnd);
…
private:
Edit _edit;
char _string[maxLen];
};
Controller::Controller(HWND hwnd) : _edit(hwnd, IDC_EDIT) {
_edit.SetFocus();
…
}
void Controller::Command(HWND hwnd, WPARAM wParam, LPARAM lParam) {
switch (LOWORD(wParam)) {
case IDC_EDIT:
if (_edit.IsChanged(HIWORD (wParam))) {
_edit.GetString(_string, maxLen);
}
break;
…
}
}
Далее: Естественно, что наиболее вероятным местом использования элемента управления является диалоговое окно.
Использование «Контроллера» в диалоге
Программа с диалогом в качестве главного окна
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Основное окно программы не должно быть универсальным окном, изменяющим свой размер. Много небольших приложений работают лучше в формате диалогового окна. Очевидное преимущество такого подхода заключается в том, что, для размещения элементов управления на поверхности диалога, можно использовать редактор ресурсов. Таким образом реализован пользовательский интерфейс (ПИ) частотного анализатора. Ниже этот полезный подход описан подробнее. Вы можете разгрузить исходный текст простого приложения, которое демонстрирует, описанные методы (любезность Laszlo Radanyi).
Прежде всего мы должны разработать диалоговое окно, используя редактор ресурсов. Мы назначаем идентификаторы всем элементам управления и непосредственно диалогу. В данном примере ресурс диалога имеет идентификатор DLG_MAIN. В процедуре WinMain мы не можем регистрировать окна любого класса, потому что Windows имеет предопределенный класс для диалоговых окон. Вместо того, чтобы создавать окно, мы вызываем функцию CreateDialog, передавая ей указатель на нашу собственную процедуру диалога (объясню позже).
Цикл сообщений данной программы является нестандартным, так как он вызывает функцию IsDialogMessage для каждого сообщения. Эта функция API не только проверяет, направлено ли данное сообщение к диалоговому окну, но и, что более важно, пересылает это сообщение процедуре диалога. Если сообщение не было адресовано диалогу, мы выполняем стандартную трансляцию и диспетчеризацию.
Для удобства, мы храним значение HINSTANCE в глобальной переменной. Этот вариант фактически является предшественником более общего объекта — Приложения. Однако, в данном случае, пример слишком тривиальный, чтобы заслуживать собственного класса.
HINSTANCE TheInstance = 0;
int WINAPI WinMain (HINSTANCE hInst, HINSTANCE hPrevInst, char* cmdParam, int cmdShow) {
TheInstance = hInst;
_set_new_handler(&NewHandler);
HWND hDialog = 0;
hDialog = CreateDialog(hinst, MAKEINTRESOURCE(DLG_MAIN), 0, DialogProc);
if (!hDialog) {
char buf[100];
wsprintf(buf, "Error x%x", GetLastError());
MessageBox(0, buf, "CreateDialog", MB_ICONEXCLAMATION | MB_OK);
return 1;
}
MSG msg;
int status;
while ((status = GetMessage(&msg, 0, 0, 0)) != 0) {
if (status == –1) return –1;
if (!IsDialogMessage(hDialog, &msg)) {
TranslateMessage(&msg);
DispatchMessage(&msg );
}
}
return msg.wParam;
}
Процедура диалога — точно такая же как и процедура Windows, за исключением того, что она возвращает TRUE, когда она обрабатывает сообщение и FALSE, когда его не обрабатывает. Нет никакой потребности вызывать процедуру, заданную по умолчанию, потому что Windows делает это за нас всякий раз, когда процедура диалога возвращает FALSE (делает за Вас это дело, так почему же не сделано точно также при использовании оконной процедуры…). Первое сообщение, которое диалог получает — WM_INITDIALOG, а последнее — WM_CLOSE. В ходе обработки этих сообщений мы создаем и уничтожаем «Контроллер» (Controller). Других случаях, отличных от этих, диалог ожидает сообщения от его элементов управления управления, передаваемого как WM_COMMAND. Одно из элементов управления, требует специальной обработки. Это (горизонтальная) линейка прокрутки (scrollbar). Она посылает сообщение WM_HSCROLL. Средства управления линейкой прокрутки (scrollbar) имеются в частотном анализаторе, и там показано, как иметь с ними дело.
BOOL CALLBACK DialogProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) {
static Controller* control = 0;
switch (message) {
case WM_INITDIALOG:
try {
control = new Controller(hwnd);
}
catch (WinException e) {
MessageBox(0, e.GetMessage(), "Exception", MB_ICONEXCLAMATION | MB_OK);
PostQuitMessage(1);
} catch (…) {
MessageBox(0, "Unknown", "Exception", MB_ICONEXCLAMATION | MB_OK);
PostQuitMessage(2);
}
return TRUE;
case WM_COMMAND:
control->Command(hwnd, LOWORD (wParam), HIWORD (wParam));
return TRUE;
case WM_HSCROLL:
control->Scroll(hwnd, LOWORD(wParam), HIWORD(wParam));
return 0;
case WM_DESTROY:
PostQuitMessage(0);
return TRUE;
case WM_CLOSE:
delete control;
DestroyWindow(hwnd);
return TRUE;
}
return FALSE;
}
Давайте, взглянем на «Контроллер». Обратите внимание, что каждый элемент управления на поверхности диалогового окна имеет соответствующий (внедренный) объект управления внутри «Контроллера». Имеются редакторы, селективные списки, радиокнопки и линейки прокрутки. Встречается специальный элемент управления «metafile», который рисует шкалу частот и два объекта отображения, соответствующие двум статическим подокнам, в которые мы рисуем графики. И, наконец, мы имеем объект Painter, который является ответственным за асинхронную перерисовку каждого из двух подокон.
class Controller {
public:
Controller(HWND hwnd);
~Controller();
void Command(HWND hwnd, int id, int code);
void Scroll(HWND hwnd, int cmd, int pos);
void Paint(HWND hwnd);
void ReInit(HWND hwnd);
void Stop(HWND hwnd);
private:
void InitScrollPositions();
void PaintScale();
BOOL _isStopped;
int _bitsPerSample;
int _samplesPerSecond;
int _fftPoints;
int _samplesPerBuf;
EditReadOnly _edit;
Combo _comboFreq;
Combo _comboPoints;
RadioButton _radio8;
RadioButton _radio16;
ScrollBarMap _scroll;
StaticEnhMetafileControl _scaleFreq;
ViewWave _viewWave;
ViewFreq _viewFreq;
Painter _display;
};
Конструктор «Контроллера» заботится об инициализации всех элементов управления, передавая им дескриптор диалогового окна и соответствующие идентификаторы. Как косметическую добавку, мы присоединяем нашу собственную иконку к диалогу. В противном случае система использовала бы стандартную иконку Windows.
Controller::Controller(HWND hwnd) :_isStopped(TRUE), _bitsPerSample(16), _samplesPerSecond(SAMPLES_SEC), _fftPoints(FFT_POINTS * 4), _samplesPerBuf(FFT_POINTS * 2), _radio8(hwnd, IDC_8_BITS), _radio16(hwnd, IDC_16_BITS), _scroll(hwnd, IDC_SCROLLBAR), _edit(hwnd, IDC_EDIT), _comboFreq(hwnd, IDC_SAMPLING), _comboPoints(hwnd, IDC_POINTS), _viewWave(hwnd, IDS_WAVE_PANE, FFT_POINTS * 8), _viewFreq(hwnd, IDS_FREQ_PANE), _scaleFreq(hwnd, IDC_FREQ_SCALE), _display(hwnd, _viewWave, _viewFreq, _samplesPerBuf, _samplesPerSecond, _fftPoints) {
// Attach icon to main dialog
HICON hIcon = LoadIcon(TheInstance, MAKEINTRESOURCE(ICO_FFT));
SendMessage(hwnd, WM_SETICON, WPARAM(ICON_SMALL), LPARAM(hIcon));
// Other initializations…
}
Использование диалогового окна в качестве главного — очень удобная и простая техника, особенно для приложений, которые используют панелеподобный интерфейс. Между прочим, приложение "Морской бой" (см. домашнюю страницу) использует тот же самый прием.
Далее: использование диалоговых окон в Windows приложениях.
(обратно)Использование фабрики классов для окон диалога
Окно диалога
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Отсюда можно загрузить программу, демонстрирующую окно диалога (zip архив 14 кб)
Диалоговое окно для Windows программы является тем же, чем является вызов функции для программы на языке C. Сначала, Windows программы передают некоторые данные диалоговому окну, чтобы инициализировать его. Затем диалоговое окно обменивается информацией с пользователем. Когда пользователь решает, что любопытство программы было удовлетворено, он (или она) нажимает кнопку OK. Вновь полученные данные возвращаются обратно программе.
Диалоговое окно обычно взаимодействует со всеми видами элементов управления (виджетами, устройствами, гизмозами — называйте их как хотите). Код диалогового окна взаимодействует с этими элементами, посылая и получая сообщения через свою «Процедуру диалога». В реализациях различных диалоговых окон имеется много общего кода. Нам хотелось бы написать и отладить этот код только один раз, а затем многократно использовать его.
Что изменяется от диалога к диалогу:
• Разновидность данных, которые передаются в диалог и возвращаются из него.
• Разновидность элементов внутри диалогового окна.
• Взаимодействие между элементами.
Эта изменчивость может быть инкапсулирована в двух специальных клиентских классах: классе списка параметров и классе контроллера диалога.
Класс списка параметров инкапсулирует внутри себя параметры. Он обеспечивает доступ для их восстановления и изменения. Определение и реализация этого класса находятся под полным контролем клиента (программиста, многократно использующего наш код).
Класс контроллера диалога содержит объекты управления для всех элементов диалога и осуществляет взаимодействия между ними. Клиент, как предполагается, получает этот класс от абстрактного класса DlgController и реализует все его чистые виртуальные методы.
Остальное — только клей. Нам необходимо параметризировать шаблон класса CtrlFactory, который используется нашей обобщенной реализацией класса ModalDialog. Фабрика контроллера создает соответствующий, определенный клиентом, контроллер и возвращает полиморфный указатель на него. Рис. 1 показывает связи между различными классами, включаемыми в реализацию диалогового окна.
Рис. 1. Классы, включаемые в образец проектирования "Диалоговое окно".
Давайте, начнем с клиентского кода. В нашей обобщенной программе мы нуждаемся в диалоговом окне, которое позволяет пользователю редактировать строку. Используя редактор ресурса, мы создаем шаблон диалога, который содержит средства редактирования и две кнопки, OK и CANCEL. Идентификатор ресурса (id) этого диалога – IDD_EDITDIALOG. Затем мы определяем наш собственный класс списка параметров по имени EditorData и специальный класс контроллера по имени EditorCtrl. Когда пользователь выбирает пункт меню Edit, будет выполняться следующий код:
void Controller::Edit(HWND hwnd) {
EditorData data(_model.GetText ());
ControllerFactory<EditorCtrl, EditorData> factory(&data);
ModalDialog dialog(_hInst, hwnd, IDD_EDITDIALOG, &factory);
if (dialog.IsOk()) {
_model.SetText(data.GetName());
// Force repaint
InvalidateRect(hwnd, 0, TRUE);
}
}
Сначала создается и инициализируется строкой объект EditorData. Затем, формируется шаблон ControllerFactory. Мы параметризуем его двумя клиентскими классами EditorCtrl и EditorData. Объект фабрики инициализирован указателем на наши данные. Затем создается объект ModalDialog. Он получет указатель на нашу фабрику в качестве параметра. Это используется для того, чтобы создать объект контроллера и восстанавливать данные из списка параметров. После того, как проведено взаимодействие с пользователем, мы проверяем, подтверждал ли пользователь результаты, нажимая кнопку OK, и если так, то мы фиксируем результаты редактирования и используем их в нашей программе. Этот способ создания диалогового окна является наиболее типичным.
Класс EditorData в нашем примере предельно прост.
class EditorData {
public:
enum { maxLen = 128 };
EditorData(char const* name) {
SetName(name);
}
BOOL IsNameOK() { return (_name[0] != '\0'); }
void SetName(char const *name) {
strcpy(_name, name);
}
char const* GetName() { return _name; }
private:
char _name[maxLen];
};
Класс контроллера, EditorCtrl, содержит все операции. Прежде всего он встраивает в себя элемент редактирования. Этот объект ответствен за взаимодействие с элементом редактирования, внедренным в диалоговое окно. Элемент имеет идентификатор IDC_NAME_EDIT, заданныйс помощью редактора ресурсов. Во-вторых, контроллер хранит указатель на EditorData. Этот указатель взят из базового класса DlgController. Три виртуальных метода DlgController должны быть переписаны в нашем EditorControl. Это OnInitDialog, который вызывается немедленно после того, как диалог был инициализирован, OnCommand, который вызывается всякий раз, когда любой элемент диалогового окна посылает нам команду и, в заключение, OnNotify, который используется новыми элементами управления Windows95.
class EditorCtrl : public DlgController {
public:
EditorCtrl(HWND hwndDlg, void *argList) : DlgController(argList), _nameEdit(hwndDlg, IDC_NAME_EDIT) {
_dlgData = (EditorData*)GetArgList();
}
void OnInitDialog(HWND hwnd);
bool OnCommand(HWND hwnd, int ctrlID, int notifyCode);
bool OnNotify(HWND hwnd, int idCtrl, NMHDR *hdr);
private:
Edit _nameEdit;
EditorData *_dlgData;
};
В методе OnInitDialog мы обрабатываем строку, которая была передана в EditorData и используем ее, чтобы инициализировать элемент редактирования.
void EditorCtrl::OnInitDialog(HWND hwnd) {
char const* name = _dlgData->GetName();
_nameEdit.SetString(name);
}
OnCommand получает команды от различных элементов. Элементы идентифицированы их идентификаторами. Например, если идентификатор — IDC_NAME_EDIT, это означает что что-то произошло с элементом редактирования. В нашей реализации мало функциональности, и мы реагируем на каждое изменение, копируя целую строку в объект EditorData. Хотя встречаются случаи, когда Вы должны проверять правильность строки или отображать ее в некотором другом элементе управления, а также Вы должны реагировать на каждое сообщение об изменении.
Когда пользователь нажимает кнопку OK, мы получаем команду с идентификатором IDOK. Мы проверяем строку и, если она правильная, то заканчиваем диалог, передающий TRUE как код возврата. Когда идентификатор — IDCANCEL (от кнопки Cancel) мы заканчиваем диалог с кодом возврата FALSE.
Метод OnNotify ничего не делает при использовании элементов управления, использовавшихся до Widnows95, таких как элементы редактирования и кнопки.
bool EditorCtrl::OnCommand(HWND hwnd, int ctrlID, int notifyCode) {
switch (ctrlID) {
case IDC_NAME_EDIT:
if (_nameEdit.IsChanged(notifyCode)) {
char nameBuf [EditorData::maxLen];
int len = _nameEdit.GetLen();
if (len < EditorData::maxLen) {
_nameEdit.GetString(nameBuf, sizeof(nameBuf));
_dlgData->SetName(nameBuf);
}
return true;
}
break;
case IDOK:
if (_dlgData->IsNameOK()) {
EndDialog(hwnd, TRUE);
} else {
MessageBox(hwnd, "Please, enter valid name", "Name Editor", MB_ICONINFORMATION | MB_OK);
}
return true;
case IDCANCEL:
EndDialog(hwnd, FALSE);
return true;
}
return false;
}
bool EditorCtrl::OnNotify(HWND hwnd, int idCtrl, NMHDR *hdr) {
return false;
}
Теперь, когда Вы знаете клиентский код, давайте рассмотрим полную реализацию образца "Диалоговое окно". Фабрика контроллера — очень простой шаблон класса. Все, что она делает, это прием списка обобщенных параметров и сохранение его через void-указатели. Только определенный клиентом контроллер знает, чем фактически является класс, размещенный в списке параметров, и только он выполняет приведение (см. конструктор EditorCtrl).
Код, общий для всех фабрик контроллеров изолирован в классе CtrlFactory от которого наследует фактический шаблон. Шаблон переопределяет метод MakeController, чтобы создать новый контроллер для класса ActualCtrl, определенного клиентом. Обратите внимание, что метод возвращает ActualCtrl как указатель на его базовый класс DlgController, и это — все то, что видит остальная часть реализации.
class CtrlFactory {
public:
CtrlFactory(void *argList) : _argList(argList) {}
void *GetArgList() { return _argList; }
virtual DlgController* MakeController(HWND hwndDlg) = 0;
private: void *_argList;
};
template <class ActualCtrl, class ActualArgList>
class ControllerFactory : public CtrlFactory {
public:
ControllerFactory(void *argList) : CtrlFactory(argList) {}
DlgController * MakeController(HWND hwndDlg) {
return new ActualCtrl(hwndDlg, (ActualArgList*)GetArgList());
}
};
Ниже приводится определение абстрактного класса DlgController, который используется как основа для всех классов контроллеров, определенных клиентом. Мы уже видели, как работает эти наследования на примере клиентского класса EditorCtrl.
class DlgController {
public:
virtual ~DlgController() {} // In case derived class overrides
virtual void OnInitDialog(HWND hwnd) = 0;
virtual bool OnCommand(HWND hwnd, int ctrlID, int notifyCode) = 0;
virtual bool OnNotify(HWND hwnd, int idCtrl, NMHDR *hdr) = 0;
void *GetArgList() { return _argList; }
protected:
DlgController(void *argList) : _argList (argList) {}
private:
void *_argList;
};
Центральным фрагментом для многократного использования программного обеспечения является класс ModalDialog. Он делает всю работу в своем конструкторе, вызывая функцию API DialogBoxParam. Параметр, который мы передаем диалоговому окну (фактически, его процедуре диалога) — указатель на фабрику контроллера. Процедура диалога определена как статический метод (не нужен указатель: процедура диалога вызывается из Windows, поэтому отсутствует доступ по указателю).
class ModalDialog {
public:
ModalDialog(HINSTANCE hInst, HWND hwnd, int dlgResource, CtrlFactory *ctrlFactory) {
_result = DialogBoxParam(hInst, MAKEINTRESOURCE(dlgResource), hwnd, (DLGPROC)ModalDialogProc, (LPARAM)ctrlFactory);
}
static BOOL CALLBACK ModalDialogProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam);
bool IsOk() const { return (_result == –1) ? false : _result != 0; }
private:
int _result;
};
В заключение отметим, что процедура диалога, общая для всех типов диалогов, реализована так, чтобы ответить на три вида сообщений: WM_INITDIALOG, WM_COMMAND и WM_NOTIFY. Фактически, все они направляют эти сообщения к объекту — контроллеру. Он получает указатель на полиморфный объект контроллера вызывая в начале метод фабрики MakeController.
Обратите внимание, что, из этой точки мы позволяем Windows, отследить указатель на контроллер. Мы сохраняем его как GWL_USERDATA — специальный длинный, который ассоциируется с каждым окном, в особенности с нашим диалогом, и доступен через его дескриптор окна.
template <class T> inline T
GetWinLong(HWND hwnd, int which = GWL_USERDATA) {
return reinterpret_cast<T>(::GetWindowLong(hwnd, which));
}
template <class T> inline void
SetWinLong(HWND hwnd, T value, int which = GWL_USERDATA) {
::SetWindowLong(hwnd, which, reinterpret_cast<long>(value));
}
Мы должны быть, хотя бы внимательными. Прежде всего мы должны освободить контроллер после того, как использовали его. Мы делаем это при обработке WM_DESTROY.
Во-вторых, Windows имеет неудачную идею (привычку) посылать сообщения WM_COMMAND и WM_NOTIFY перед WM_INITDIALOG и после WM_DESTROY. Что можно здесь сказать? Я бы побил менеджера, который ответствен за эти дела. Но раз это есть, мы должны защитить себя, проверяя, является ли ctrl ненулевым перед вызовом OnCommand и OnNotify.
BOOL CALLBACK ModalDialog::ModalDialogProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) {
DlgController* ctrl = GetWinLong<DlgController *>(hwnd);
switch (message) {
case WM_INITDIALOG:
{
CtrlFactory *ctrlFactory = reinterpret_cast<CtrlFactory *>(lParam);
ctrl = ctrlFactory->MakeController(hwnd);
SetWinLong<DlgController *>(hwnd, ctrl);
ctrl->OnInitDialog (hwnd);
}
return TRUE;
case WM_COMMAND:
if (ctrl && ctrl->OnCommand(hwnd, LOWORD(wParam), HIWORD (wParam))) return TRUE;
break;
case WM_NOTIFY:
if (ctrl && ctrl->OnNotify(hwnd, wParam, (NMHDR *)lParam))
return TRUE;
break;
case WM_DESTROY:
delete ctrl;
SetWinLong<DlgController *>(hwnd, 0);
break;
}
return FALSE;
}
Здесь представлена красота полиморфизма в действии. Объект фабрики создан клиентом, использующим шаблонный класс. Этот объект передается конструктору ModalDialog. ModalDialog передает его процедуре диалога как пустой указатель (дело в том, что он должен пройти через Windows). Процедура Диалога получает его внутри сообщения WM_INITDIALOG как LPARAM. После прохождения пищеварительного тракта Windows он должен быть восстановлен к своей первоначальной форме, переводом его обратно к указателю на CtrlFactory — в базовый класс всех фабрик контроллера.
Когда мы вызываем его виртуальный метод MakeController, мы вызываем метод, переопределенный в шаблонном классе ControllerFactory. Он создает новый объект для класса ActualCtrl, определенного клиентом. Но снова, он возвращает этот объект к нам замаскированный как обобщенный указатель на DlgController. Так всякий раз, когда мы вызываем любой из виртуальных методов ctrl, мы выполняем клиентские переопределения, определенные в классе ActualCtrl. Это лучшее проявление полиморфизма: Вы записываете код, используя обобщенные указатели, но когда код выполнен, он вызывается с очень специфическими указателями. Когда Вы вызываете методы через эти указатели, Вы выполняете специфические методы, обеспеченные клиентом вашего кода.
Вот, что случается с фабрикой объектов, чей фактический класс ControllerFactory <EditorCtrl, EditorData>
Передается конструктору ModalDialog как void* Передаётся от Windows к ModalDialogProcedure как LPARAM Приведение в ModalDialogProcedure к CtrlFactory*А вот, что случается с объектными данными, чьим фактическим классом является EditorData.
Передается конструктору фабрики как void* Приведение в методе AcquireController класса ControllerFactory<EditorCtrl, EditorData> к EditorData* Переданный конструктору EditCtrl как EditotData*Объект класса EditCtrl, созданный в методе MakeController класса ControllerFactory<EditorCtrl, EditorData> возвращается из него как DlgController* и сохраняется в этой форме как статический член данных ModalDialog.
Если Вы имеете проблемы после моего объяснения, не отчаивайтесь. Объектно ориентированные методы, которые я только описал, трудны, но необходимы. Они названы образцами проектирования. Я настоятельно рекомендую читать книгу: Gamma, Helm, Johnson and Vlissides — Design Patterns, Elements of Reusable Object-Oriented Software или посмотреть Patterns Home Page (домашнюю страницу образцов). Там описано много творческих способов использования полиморфизма, наследования и шаблонизации, чтобы делать программное обеспечение более пригодным для многократного использования.
Далее: Более подробный разговор о холсте.
(обратно)Обертка для контекста устройств
Холст или контекст устройств Windows
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Чтобы раукрашивать, рисовать или печатать в окне, Вам необходим контекст устройств (device context или, кратко, DC). DC — это ресурс, который заимствуется у Windows и, как предполагается, возвращается сразу же после того, как вы сделаете свою работу. Отсюда и берет корни объект Canvas (Холст). Конструктор Холста получает DC, а деструктор освобождает его. Важно то, что Вы создаете объекты Canvas как автоматические (стековые) переменные. Это гарантирует, что, когда программа выйдет из локальной области (контекста), всегда вызовется их деструктор, в которой определены ресурсы (предлагаемый класс является примером более общей методологии Управления ресурсами). Типичное использование объекта Canvas демонстрируется следующем кодом (вы его уже видели в программе Generic):
void Controller::Paint() {
// prepare the canvas and let View do the rest
PaintCanvas canvas(_hwnd);
_view.Paint(canvas, _model);
// Notice: The destructor of PaintCanvas called automatically!
}
Различные типы Холста совместно используют общего предка — класс Canvas. Обратите внимание, что конструктор Холста защищен. Фактически, Вы не можете сформировать объект этого класса. Однако, наследующие классы открыты, чтобы обеспечить доступ к их собственным конструкторам. Между прочим, Вы можете осуществлять добавление новых методов к Холсту, по мере возникновения такой потребности.
class Canvas {
public:
// operator cast to HDC
// (used when passing Canvas to Windows API)
operator HDC() { return _hdc; }
void Point(int x, int y, COLORREF color) {
::SetPixel(_hdc, x, y, color);
}
void MoveTo(int x, int y) {
::MoveToEx(_hdc, x, y, 0);
}
void Line(int x1, int y1, int x2, int y2 ) {
MoveToEx(_hdc, x1, y1, 0);
LineTo(_hdc, x2, y2);
}
void Rectangle(int left, int top, int right, int bottom) {
// draw rectangle using current pen
// and fill it using current brush
::Rectangle(_hdc, left, top, right, bottom);
}
void GetTextSize(int& cxChar, int& cyChar) {
TEXTMETRIC tm;
GetTextMetrics(_hdc, &tm);
cxChar = tm.tmAveCharWidth;
cyChar = tm.tmHeight + tm.tmExternalLeading;
}
void Text(int x, int y, char const * buf, int cBuf) {
::TextOut(_hdc, x, y, buf, cbuf);
}
void Char(int x, int y, char c) {
TextOut(_hdc, x, y, &c, 1);
}
void SelectObject(void* pObj) {
::SelectObject(_hdc, pobj);
}
protected:
Canvas(HDC hdc): _hdc(hdc) {}
HDC _hdc;
};
В ответ на сообщение WM_PAINT нужно создать объект PaintCanvas. Обратите внимание на способ получения и освобождения DC объектом PaintCanvas.
class PaintCanvas: public Canvas {
public:
// Constructor obtains the DC
PaintCanvas(HWND hwnd) : Canvas(BeginPaint(hwnd, &_paint)), _hwnd(hwnd) {}
// Destructor releases the DC
~PaintCanvas() {
EndPaint(_hwnd, &_paint);
}
protected:
PAINTSTRUCT _paint;
HWND _hwnd;
};
Другой важный пример — класс UpdateCanvas, который используется для графических операций вне контекста обработки сообщения WM_PAINT. Конечно, ваша программа может всегда инициировать перерисовку, вызывая InvalidateRect, но во многих случаях это было бы массовым убийством. Если ваша программа осуществляет перерисовку новых объектов, когда они обрабатываются или в ответ на действия пользователя, Вы можете модифицировать окно, используя UpdateCanvas.
class UpdateCanvas: public Canvas {
public:
UpdateCanvas(HWND hwnd) : Canvas(GetDC(hwnd)), _hwnd(hwnd) {}
~UpdateCanvas() {
ReleaseDC(_hwnd, _hdc);
}
protected:
HWND _hwnd;
};
Можно создать и другие типы Холста: DrawItemCanvas используется для рисования элементов управления их владельцем, MemCanvas — для рисования во фрагментах памяти, и т.д.
Далее: Использование перьев и кистей для рисования на холсте.
(обратно)Перья и кисти внутри классов
Рисование перьями и раскрашивание кистями
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Подобно живописцу, Вы нуждаетесь в перьях и кистях, чтобы создать шедевр на вашем холсте. Когда Вы вызываете метод Canvas::Line или Canvas::Rectangle, Windows использует текущие установки пера, чтобы рисовать линии, и текущие установки кисти, чтобы заполнять охватываемые контуры.
Когда объект сопоставляется с Холстом, нельзя забывать освободить его после окончания работы. Это надо делать до тех пор, пока вы не обеспечите такой возможностью вашу программу на языке C++. Используйте только локальные объекты, чьи конструкторы присоединяют, а деструкторы (вызываемые автоматически, при выходе области действия) освобождают объекты (см. страницу «Управление ресурсами» для более детального знакомства с этой методологией). Обратите внимание, что ниже следующие объекты используют HDC (дескрипторы контекстов устройств) в качестве параметры в их конструкторах. Однако, взамен этого, Вы должны просто передать им объект Canvas. Помните, что «Холст» может автоматически приводиться к HDC.
class StockObject {
public:
StockObject(HDC hdc, int type) : _hdc(hdc) {
_hObjOld = SelectObject(_hdc, GetStockObject(type));
}
~StockObject () {
SelectObject(_hdc, _hObjOld);
}
private:
HGDIOBJ _hObjOld;
HDC _hdc;
};
Windows имеет набор предопределенных перьев и кистей. Если Вы хотите использовать их, то достаточно присоединить выбранные перья и кисти к вашему холсту не некоторое время.
class WhitePen : public StockObject {
public:
WhitePen(HDC hdc): StockObject(hdc, WHITE_PEN) {}
};
// example
void Controller::Paint(HWND hwnd) {
PaintCanvas canvas(hwnd);
WhitePen pen(canvas);
canvas.Line(0, 10, 100, 10);
// destructor of WhitePen
// destructor of PaintCanvas
}
Если ваша программа поддерживает использование несколько перьев, отсутствующих в Windows, Вы можете предварительно создать их (например, внедрив их в объект View) и использовать объект PenHolder, для временного присоединения к Холсту.
class Pen {
public:
Pen(COLORREF color) {
_hPen = CreatePen(PS_SOLID, 0, color);
}
~Pen() {
DeleteObject(_hpen);
}
operator HPEN() {
return _hPen;
}
private:
HPEN _hPen;
};
class PenHolder {
public:
PenHolder(HDC hdc, HPEN hPen) : _hdc (hdc) {
_hPenOld = (HPEN)SelectObject (_hdc, hPen);
}
~PenHolder() {
SelectObject(_hdc, _hPenOld);
}
private:
HDC _hdc;
HPEN _hPenOld;
};
class View {
public:
View() : _penGreen (RGB (0, 255, 128)) {}
void Paint(Canvas& canvas) {
PenHolder holder(canvas, _penGreen);
canvas.Line(0, 10, 100, 10);
// destructor of PenHolder
}
private:
Pen _penGreen;
};
И, наконец, если ваша программа нуждается в произвольных цветных перьях, то есть, невозможно предварительно определить всех цветов, в которых вы будете нуждаться, Вы должны использовать цветные перья. Когда Вы определяете автоматический объект ColorPen, его конструктор создает и присоединяет перо. Когда, в конце области действия, вызывается деструктор, он отсоединяет перо и удаляет его.
class ColorPen {
public:
ColorPen(HDC hdc, COLORREF color) : _hdc (hdc) {
_hPen = CreatePen(PS_SOLID, 0, color);
_hPenOld = (HPEN)SelectObject(_hdc, _hPen);
}
~ColorPen() {
SelectObject(_hdc, _hPenOld);
DeleteObject(_hPen);
}
private:
HDC _hdc;
HPEN _hPen;
HPEN _hPenOld;
};
Точно таким же способом Вы можете работать с кистями (кистей, поддерживаемых Windows, гораздо больше, чем перьев). В качестве примера, ниже дается определение ColorBrush.
class ColorBrush {
public:
ColorBrush(HDC hdc, COLORREF color) : _hdc (hdc) {
_hBrush = CreateSolidBrush(color);
_hBrushOld = (HBRUSH)SelectObject(_hdc, _hBrush);
}
~ColorBrush() {
SelectObject(_hdc, _hBrushOld);
DeleteObject(_hBrush);
}
private:
HDC _hdc;
HBRUSH _hBrush;
HBRUSH _hBrushOld;
};
Как всегда, мы пощряем Ваши собственные эксперименты.
Далее: совершенно иная тема — «Потоки».
(обратно)Классовая оболочка для потоков
Использование потоков
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Многозадачность — один из наиболее трудных аспектов программирования. Поэтому, для нее тем более важно обеспечить простой набор абстракций и инкапсулировать их в хорошей объектно-ориентированной оболочке. В ОО мире, естественным аналогом потока, являющегося, чисто процедурной абстракцией, служит «Активный объект». Активный объект обладает удерживаемым потоком, который асинхронно выполняет некоторые задачи. Этот поток имеет доступ к всем внутренним (закрытым) данным и методам объекта. Открытый интерфейс Активного объекта доступен внешним агентам (таким как основному потоку, или потоку, несущему сообщения Windows). Поэтому, они могут манипулировать состоянием объекта также, как эта манипуляция осуществляется из удерживаемого потока. Хотя, режим управления при этом сильно ограничен.
Активный Объект сформирован как каркас по имени ActiveObject. Построение производного класса, как предполагается, обеспечивает реализацию для чистых виртуальных методов InitThread, Run и Flush (также как и написание деструктора).
class ActiveObject {
public:
ActiveObject();
virtual ~ActiveObject() {}
void Kill();
protected:
virtual void InitThread() = 0;
virtual void Run() = 0; virtual void FlushThread() = 0;
static DWORD WINAPI ThreadEntry(void *pArg);
int _isDying;
Thread _thread;
};
Конструктор класса ActiveObject инициализирует удерживаемый поток, передавая ему указатель функции, которую предполагается выполнить и указатель "this" на себя. Мы должны отключить предупреждение, сигнализирующее об использовании "this" до полного создания объекта. Мы знаем, что этот объект не будет использоваться раньше положенного, потому что поток создается в неактивном состоянии. Предполагается, сто конструктор производного класса вызывает _thread.Resume() чтобы активизировать поток.
// The constructor of the derived class
// should call
// _thread.Resume ();
// at the end of construction
ActiveObject::ActiveObject() : _isDying (0),
#pragma warning(disable: 4355) // 'this' used before initialized
_thread(ThreadEntry, this)
#pragma warning(default: 4355)
{ }
Метод Kill вызывает виртуальный метод FlushThread — это необходимо для завершения потока из любого состояния ожидания и дает ему возможность запустить _isDying для проверки флажка.
void ActiveObject::Kill() {
_isDying++;
FlushThread();
// Let's make sure it's gone
_thread.WaitForDeath();
}
Мы также имеем каркас для функции ThreadEntry (это — статический метод класса ActiveObject, поэтому мы можем определять соглашение о вызовах, требуемое API). Эта функция выполняется удерживаемым потоком. Параметр, получаемый потоком от системы является тем, который мы передали конструктору объекта потока — это указатель "this" Активного Объекта. API ожидает void-указатель, поэтому мы должны делать явное приведение указателя на ActiveObject. Как только мы овладеваем Активным Объектом, мы вызываем его чистый виртуальный метод InitThread, делать все специфические для реализации приготовления, а затем вызываем основной рабочий метод Run. Реализация метода Run оставлена клиенту каркаса.
DWORD WINAPI ActiveObject::ThreadEntry(void* pArg) {
ActiveObject* pActive = (ActiveObject*)pArg;
pActive->InitThread();
pActive->Run();
return 0;
}
Объект Thread — это тонкая инкапсуляция API. Обратите внимание на флажок CREATE_SUSPENDED, который гарантирует, что нить не начнет выполняться прежде, чем мы не закончим конструирование объекта ActiveObject.
class Thread {
public:
Thread(DWORD(WINAPI* pFun)(void* arg), void* pArg) {
_handle = CreateThread(
0, // Security attributes
0, // Stack size
pFun, pArg, CREATE_SUSPENDED, &_tid);
}
~Thread() {
CloseHandle(_handle);
}
void Resume() {
ResumeThread(_handle);
}
void WaitForDeath() {
WaitForSingleObject(_handle, 2000);
}
private:
HANDLE _handle;
DWORD _tid; // thread id
};
Синхронизация — это то, что действительно делает многозадачный режим столь интенсивно используемым. Давайте, начнем со взаимных исключений. Класс Mutex — тонкая инкапсуляция API. Вы внедряете Mutexes (мутации) в ваш Активный Объект, а затем используете их через Блокировки. Блокировка (Lock) — умный объект, который создается на стеке. В результате чего, во время обслуживания, ваш объект защищен от любых других потоков. Класс Lock — одно из приложений методологии Управления ресурсами. Вы должны поместить Lock внутри всех методов вашего Активного Объекта, которые разделяют доступ к данным с другими потоками.
class Mutex {
friend class Lock;
public:
Mutex() {
InitializeCriticalSection(&_critSection);
}
~Mutex() {
DeleteCriticalSection(&_critSection);
}
private:
void Acquire() {
EnterCriticalSection(&_critSection);
}
void Release() {
LeaveCriticalSection(&_critSection);
}
CRITICAL_SECTION _critSection;
};
class Lock {
public:
// Acquire the state of the semaphore
Lock(Mutex& mutex) : _mutex(mutex) {
_mutex.Acquire();
}
// Release the state of the semaphore
~Lock() {
_mutex.Release();
}
private:
Mutex& _mutex;
};
Событие — это сигнальное устройство, которое потоки используют, чтобы связаться друг с другом. Вы внедряете Событие (Event) в ваш активный объект. Затем Вы переводите удерживаемый поток в состояние ожидания, пока некоторый другой поток не освободит его. Не забудьте однако, что, если ваш удерживаемй поток ожидает события, он не может быть завершен. Именно поэтому Вы должны вызывать Release из метода Flush.
class Event {
public:
Event() {
// start in non-signaled state (red light)
// auto reset after every Wait
_handle = CreateEvent(0, FALSE, FALSE, 0);
}
~Event() {
CloseHandle(_handle);
}
// put into signaled state
void Release() {
SetEvent(_handle);
}
void Wait() {
// Wait until event is in signaled (green) state
WaitForSingleObject(_handle, INFINITE);
}
operator HANDLE() { return _handle; }
private:
HANDLE _handle;
};
Чтобы увидеть, как эти классы могут быть использованы, я предлагаю небольшую подсказку. Вы можете перейти к странице, которая объясняет, как класс ActiveObject используется в Частотном анализаторе для асинхронной модификации дисплеев. Или, Вы можете изучить более простой пример Наблюдателя Папки, который спокойно ждет, отображая папки, и пробуждается только, когда присходит изменение ее содержимого.
Жаль, что я не могу сказать, что программирование потоков является простым. Однако, оно будет проще, если Вы станете использовать правильные примитивы. Это примитивы, которые я рекламировал: ActiveObject, Thread, Mutex, Lock и Event. Некоторые из них фактически доступны в MFC. К примеру, там есть блокирующий объект CLock (а может быть — это ЧАСЫ [CLock — игра слов]?) деструктор которого управляет, критической секцией (он немного менее удобен из-за «двухшаговой» конструкции: Вы должны создать его, а затем выбирать его в два отдельных шага — как будто бы вы захотели создать его, а затем передумать). Другое отличие: MFC предлагает только некоторую тонкую фанеру над API и ничего нового.
Вы можете также распознать в некоторых из механизмов, которые я представил здесь, аналоги из языка программирования Java. Конечно, когда Вы имеете свободу проектирования многозадачного режима в языке, Вы можете позволять себе быть изящными. Их версия ActiveObject называется Runnable, и она имеет метод run. Каждый объект Java потенциально имеет встроенный mutex и все, что Вам надо сделать, чтобы осуществить блокировку, — это объявить метод (или область) засинхронизированным. Точно так же события реализованные с ожиданиями подтверждениями вызываются внутри любого синхронизированного метода. Поэтому, если Вы знаете, как программировать на Java, Вы знаете, как программировать на C++ (как будто есть знатоки Java, не осведомленные о C++).
Далее: использование потоков на примере Наблюдателя за папками.
(обратно)Практическое использование потоков
Когда измененяются папки
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Вы когда-либо задались вопросом: каким оразом Проводник (Explorer) узнает о том, что некоторое действие должно модифицировать его окно, потому что был добавлен или удален файл в текущей папке некоторым внешним приложением? Больше этому можно не удивляться, потому что использование нашего Активного Объекта позволяет делать то же самое и даже больше. Есть несколько простых вызовов API, с помощью которых Вы можете запросить у файловой системы, чтобы она избирательно сообщила Вам относительно изменений для файлов и папок. Как только Вы устанавливаете такую вахту, ваш поток может отправляться спать, ожидая прихода событий. Файловая система отреагирует на событие, как только она обнаружит вид изменения, за которым вы наблюдаете.
Загрузка исходных текстов приложения FolderWatcher (zip архив 11K).
Без дальнейшей суеты унаследуем FolderWatcher из ActiveObject. Зададим в качестве источника уведомления — событие, а в качестве приемника уведомления — дескриптор к окна, отвечающего на уведомление. Исходное событие установлено в конструкторе FolderWatcher. Важно также запустить удерживаемый поток в конце конструктора.
class FolderWatcher : public ActiveObject {
public: FolderWatcher(char const* folder, HWND hwnd) : _notifySource (folder), _hwndNotifySink (hwnd) {
strcpy(_folder, folder);
_thread.Resume();
}
~FolderWatcher() {
Kill();
}
private:
void InitThread() {}
void Loop();
void FlushThread() {}
FolderChangeEvent _notifySource;
HWND _hwndNotifySink;
char _folder[MAX_PATH];
};
Все действия в ActiveObject происходят внутри метода Loop. Здесь мы устанавливаем "бесконечный" цикл, в котором поток должен ожидать событие. Когда событие происходит, мы проверяем флажок _isDying (как обычно) и посылаем специальное сообщение WM_FOLDER_CHANGE окну, которое имеет дело с уведомлениями. Это — не предопределенное сообщение Windows. Оно специально определено нами для передачи уведомления о папке от одного потока другому.
Происходит следующее: удерживаемый поток делает другой вызов API, чтобы позволить файловой системе, узнать, что она нуждается в большем количестве уведомлений. Затем управление возвращается к ожидающему потоку, находящемуся в состоянии сна. Одновременно Windows получает наше сообщение WM_FOLDER_CHANGE из очереди сообщений и посылает его оконной процедуре принимающего окна. Подробности чуть позже.
UINT const WM_FOLDER_CHANGE = WM_USER;
void FolderWatcher::Loop() {
for (;;) {
// Wait for change notification
DWORD waitStatus = WaitForSingleObject(_notifySource, INFINITE);
if (WAIT_OBJECT_0 == waitStatus) {
// If folder changed
if (_isDying) return;
PostMessage(_hwndNotifySink, WM_FOLDER_CHANGE, 0, (LPARAM)_folder);
// Continue change notification
if (!_notifySource.ContinueNotification()) {
// Error: Continuation failed
return;
}
} else {
// Error: Wait failed
return;
}
}
}
Рассмотрим, что происходит в оконной процедуре в ответ на наше специальное сообщение. Мы вызываем метод Контроллера OnFolderChange. Этот метод может делать все, что мы захотим. В Проводнике (Explorer) он регенерирует отображение содержимого папки, которую мы наблюдаем. В нашем примере он только вызывает простое окно сообщения. Обратите внимание, что мы передаем имя измененной папки как LPARAM. Совершенно неважно, как определить WPARAM и LPARAM, в сообщении, определяемом пользователем.
Между прочим, Наблюдатель Папки — только часть Контроллера.
case WM_FOLDER_CHANGE:
pCtrl->OnFolderChange(hwnd, (char const *)lParam);
return 0;
void Controller::OnFolderChange(HWND hwnd, char const * folder) {
MessageBox(hwnd, "Change Detected, "Folder Watcher", MB_SETFOREGROUND | MB_ICONEXCLAMATION | MB_OK);
}
class Controller {
public:
Controller(HWND hwnd, CREATESTRUCT * pCreate);
~Controller();
void OnFolderChange(HWND hwnd, char const *folder);
private:
FolderWatcher _folderWatcher;
};
Теперь, когда мы знаем, как иметь дело с уведомлением, давайте взглянем на их источники, События изменяющие файлы. Объект события создан файловой системой в ответ на FindFirstChangeNotification. Дескриптор этого события возвращен из вызова. Мы запоминаем этот дескриптор и используем его позже, чтобы или осуществить восстанавление или отказаться от нашего интереса к дальнейшим уведомлениям. Обратите внимание, что мы можем устанавливать наблююдение рекурсивно, то есть, наблюдать данную папку и все ее подпапки и подподпапки. Мы можем также выражать интерес к специфическим изменениям, передавая поразрядное ИЛИ для любой комбинации следующих флажков:
• FILE_NOTIFY_CHANGE_FILE_NAME (переименование, создание или удаление файла)
• FILE_NOTIFY_CHANGE_DIR_NAME (создание или удаление каталога (папки))
• FILE_NOTIFY_CHANGE_ATTRIBUTES
• FILE_NOTIFY_CHANGE_SIZE
• FILE_NOTIFY_CHANGE_LAST_WRITE (сохранение файла)
• FILE_NOTIFY_CHANGE_SECURITY
Для удобства мы определили несколько подклассов от FileChangeEvent, которые соответствуют к некоторым полезным комбинациям этих флажков. Один из них — FolderChangeEvent, который мы использовали в нашем FolderWatcher.
class FileChangeEvent {
public:
FileChangeEvent(char const *folder, BOOL recursive, DWORD notifyFlags) {
_handle = FindFirstChangeNotification(folder, recursive, notifyFlags);
if (INVALID_HANDLE_VALUE == _handle) throw WinException("Cannot create change notification handle");
}
~FileChangeEvent() {
if (INVALID_HANDLE_VALUE != _handle) FindCloseChangeNotification(_handle);
}
operator HANDLE() const { return _handle; }
BOOL ContinueNotification() {
return FindNextChangeNotification(_handle);
}
private:
HANDLE _handle;
};
class FolderChangeEvent : public FileChangeEvent {
public:
FolderChangeEvent(char const* folder) : FileChangeEvent(folder, FALSE, FILE_NOTIFY_CHANGE_FILE_NAME) {}
};
class TreeChangeEvent : public FileChangeEvent {
public:
TreeChangeEvent(char const * root) : FileChangeEvent (root, TRUE, FILE_NOTIFY_CHANGE_FILE_NAME | FILE_NOTIFY_CHANGE_DIR_NAME) {}
};
Должно быть теперь просто обобщить этот пример, чтобы сделать некоторую действительно полезную работу в ваших программах. Не забудьте посмотреть API, который мы используем в этих обучающих программах, в интерактивной справке, которая идет с вашим компилятором.
Далее: Программирование OLE и использование COM без MFC.
(обратно)Оболочка из классов для COM
Использование оболочки Windows совместно с COM
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Программировать с использованием COM настолько трудно, что Вы не должны даже пробовать это без MFC. Правильно или неправильно? Абсолютная чушь! Рекламируемые OLE и его преемник COM имеют элегантность гиппопотама, занимающегося фигурным катанием. Но размещение MFC на вершине COM подобно одеванию гиппопотама в клоунский костюм еще больших размеров.
Загрузите исходник примера, TreeSizer (zip архив 12 кб, любезность Laszlo Radanyi), в котором вычисляется суммарный размер всех файлов в некотором каталоге и всех его подкаталогах. Он, для просмотра каталогов, использует окно просмотра оболочки Windows.
Итак, что делать программисту, когда он столкнется с потребностью использовать возможности оболочки Windows, которые являются доступными только через интерфейсы COM? Читайте …
Для начала, всякий раз, когда Вы планируете использовать COM, Вы должны сообщить системе, чтобы она инициализировала COM подсистему. Точно так же всякий раз, когда вы заканчиваете работу, Вы должны сообщить системе, чтобы она выгрузила COM. Самая простой способ это сделать заключается в определении объекта, конструктор которого инициализирует COM, а деструктор выгрожает ее. Самое лучшее место для внедрения данного механизма — это объект Controller (см. Windows программу Generic), подобный этому.
class Controller {
public:
Controller(HWND hwnd, CREATESTRUCT * pCreate);
~Controller();
// … private:
UseCom _comUser; // i'm a com user
Model _model;
View _view;
HINSTANCE _hInst;
};
Этот способ гарантируют, что COM подсистема будет проинициализирована прежде, чем к ней будут сделаны любые обращения и что она будет освобождена после того, как программа осуществит свои разрушения (то есть, после того, как "Вид" и "Модель" будут разрушены).
Класс UseCom очень прост.
class UseCom {
public:
UseCom() {
HRESULT err = CoInitialize(0);
if (err != S_OK) throw "Couldn't initialize COM";
}
~UseCom() {
CoUninitialize();
}
};
Пока не было слишком трудно, не так ли? Дело в том, что мы не коснулись главной мерзости COM программирования — подсчета ссылок. Вам должно быть известно, что каждый раз, когда что Вы получаете интерфейс, его счетчик ссылок увеличивается. И Вам необходимо явно уменьшать его. И это становится более чем ужастным тогда, когда Вы начинаете запрашивать интерфейсы, копировать их, передавать другим и т.д. Но ловите момент: мы знаем, как управляться с такими проблемами! Это называется управлением ресурсами. Мы никогда не должны касаться интерфейсов COM без инкапсуляции их в интеллектуальных указателях на интерфейсы. Ниже показано, как это работает.
Примечание. В настоящий момент данная тема достаточно широко рассмотрена в литературе, переведенной на русский язык. В частности, можно отметить книги:
Джефф Элджер. "C++: библиотека программиста";
Скотт Мейерс. "Эффективное программирование на С++".
А.Л.template <class T>
class SIfacePtr {
public:
~SIfacePtr() {
Free ();
}
T * operator->() { return _p; }
T const* operator->() const { return _p; }
operator T const * () const { return _p; }
T const& GetAccess () const { return *_p; }
protected: SIfacePtr () : _p (0) {}
void Free () {
if (_p != 0) _p->Release();
_p = 0;
}
T * _p;
private:
SIfacePtr(SIfacePtr const& p) {}
void operator=(SIfacePtr const& p) {}
};
Не волнуйте, что этот класс выглядит непригодным (потому что имеет защищенный конструктор). Мы никогда не будем использовать его непосредственно. Мы наследуем от него. Между прочим, это удобный прием: создайте класс с защищенным пустым конструктором, и осуществите наследование от него. Все наследующие классы должны обеспечивать их внутреннюю реализацию своими открытыми конструкторами. Поскольку Вы можете иметь различные классы, наследующие от SIfacePtr, они будут отличаться по способу получения, по их конструкторам, рассматриваемым интерфейсам.
Закрытые фиктивный копирующий конструктор и оператор "=" не всегда необходимы, но они сохранят Вам время, потраченное на отладку, если по ошибке вы передадите интеллектуальный интерфейс по значению вместо передачи по ссылке. Это больше невозможно. Вы можете освободить один и тот же интерфейс, дважды и это будет круто отражаться на подсчете ссылок COM. Верьте мне, у меня это случалось. Как это часто бывает, компилятор откажется передавать по значению объект, который имеет закрытую копию конструктора. Он также выдаст ошибку, когда Вы пробуете присвоить объект, который имеет закрытый оператор присваивания.
Для завершения этого короткого введения, позвольте мне представить еще одну вариацию на тему интеллектуальных указателей. Оболочки API часто распределяет память, используя свои собственные специальные программы распределения. Это не было бы настолько плохо, если бы не предположение, что они ожидают от вас освобождения памяти с использованием той же самой программы распределения. Так, всякий раз, когда оболочка вручает нам такой сомнительный пакет, мы обворачиваем его в специальный интеллектуальный указатель.
template <class T> class
SShellPtr {
public:
~SShellPtr() {
Free();
_malloc->Release();
}
T* weak operator->() { return _p; }
T const* operator->() const { return _p; }
operator T const* () const { return _p; }
T const& GetAccess () const { return *_p; }
protected:
SShellPtr() : _p(0) {
// Obtain malloc here, rather than
// in the destructor.
// Destructor must be fail-proof.
// Revisit: Would static IMalloc * _shellMalloc work?
if (SHGetMalloc(&_malloc) == E_FAIL) throw Exception "Couldn't obtain Shell Malloc";
}
void Free() {
if (_p != 0) _malloc->Free(_p);
_p = 0;
}
T * _p;
IMalloc* _malloc;
private:
SShellPtr(SShellPtr const& p) {}
void operator=(SShellPtr const & p) {}
};
Обратите внимание на использование ранее показанного приема: класс SShellPtr непосредственно не пригоден для использования. Вы должны наследовать от него подкласс и реализовать в нем соответствующий конструктор.
Обратите также внимание, что я не уверен, может ли _shellMalloc быть статическим элементом SShellPtr. Проблема состоит в том, что статические элементы инициализируются перед WinMain. Из-за этого вся COM система может оказаться неустойчивой. С другой стороны, документация говорит, что Вы можете безопасно вызывать из другой API функции CoGetMalloc перед обращением к CoInitialize. Это не говорит о том, может ли SHGetMalloc, который делает почти то же самое, также вызываться в любое время в вашей программе. Подобно многим других случаям, когда система ужасно разработана или задокументирована, только эксперимент может ответить на такие вопросы. Добро пожаловать к нам с такими ответами.
Между прочим, если Вы нуждаетесь в интеллектуальном указателе, который использует специфическое распределение памяти для COM, то получите его, вызывая CoGetMalloc. Вы можете без опаски сделать этот _malloc статическим элементом и инициализировать его только один раз в вашей программе (ниже SComMalloc::GetMalloc тоже статический):
IMalloc* SComMalloc::_malloc = SComMalloc::GetMalloc();
IMalloc* SComMalloc::GetMalloc() {
IMalloc* malloc = 0;
if (CoGetMalloc(1, &malloc) == S_OK) return malloc;
else return 0;
}
Это – все, что надо знать, чтобы начать использовать оболочку Windows и ее COM интерфейсы. Ниже приводится пример. Оболочка Windows имеет понятие Рабочего стола, являющегося корнем «файловой» системы. Вы обращали внимание, как Windows приложения допускают пользователя, просматривают файловую систему, начинающуюся на рабочем столе? Этим способом Вы можете, например, создавать файлы непосредственно на вашем рабочем столе, двигаться между дисководами, просматривать сетевой дисковод, и т.д. Это, в действительности, Распределенная Файловая система (PMDFS — poor man's Distributed File System) ограниченного человека (?). Как ваше приложение может получить доступ к PMDFS? Просто. В качестве примера напишем код, который позволит пользователю, выбирать папку, просматривая PMDFS. Все, что мы должны сделать — это овладеть рабочим столом, позиционироваться относительно его, запустить встроенное окно просмотра и сформировать путь, который выбрал пользователь.
char path [MAX_PATH];
path [0] = '\0';
Desktop desktop;
ShPath browseRoot(desktop, unicodePath);
if (browseRoot.IsOK()) {
FolderBrowser browser(hwnd, browseRoot, BIF_RETURNONLYFSDIRS, "Select folder of your choice");
if (folder.IsOK()) {
strcpy (path, browser.GetPath());
}
}
Давайте, запустим объект desktop. Он использует интерфейс по имени IShellFolder. Обратите внимание, как мы приходим к Первому Правилу Захвата. Мы распределяем ресурсы в конструкторе, вызывая функцию API SHGetDesktopFolder. Интеллектуальный указатель интерфейса будет заботиться об управлении ресурсами (подсчет ссылок).
class Desktop: public SIfacePtr<IShellFolder> {
public:
Desktop() {
if (SHGetDesktopFolder(&_p) != NOERROR) throw "SHGetDesktopFolder failed";
}
};
Как только мы получили рабочий стол, мы должны создать специальный вид пути, который используется PMDFS. Класс ShPath инкапсулирует этот «путь». Он создан из правильного Unicode пути (используйте mbstowcs, чтобы преобразовать путь ASCII в Unicode: int mbstowcs(wchar_t *wchar, const char *mbchar, size_t count)). Результат преобразования — обобщенный путь относительно рабочего стола. Обратите внимание, что память для нового пути распределена оболочкой – мы инкапсулируем это в SShellPtr, чтобы быть уверенными в правильном освобождении.
class ShPath: public SShellPtr<ITEMIDLIST> {
public:
ShPath (SIfacePtr<IShellFolder>& folder, wchar_t* path) {
ULONG lenParsed = 0;
_hresult = folder->ParseDisplayName(0, 0, path, &lenParsed, &_p, 0);
}
bool IsOK() const {
return SUCCEEDED(_hresult);
}
private:
HRESULT _hresult;
};
Этот путь оболочки станет корнем, из которого окно просмотра начнет его взаимодействие с пользователем.
С точки зрения клиентского кода, окно просмотра — путь, выбранный пользователем. Именно поэтому он наследуется от SShellPtr<ITEMIDLIST>.
Между прочим, ITEMIDLIST — официальное имя для этого обобщенного пути. Это — список, и я не назвал его SHITEMID'ом. Впредь я буду воздерживаться от любых дальнейших комментариев или шуток относительно соглашений, связанных с именами, используемыми в оболочке.
class FolderBrowser: public SShellPtr<ITEMIDLIST> {
public:
FolderBrowser(HWND hwndOwner, SShellPtr<ITEMIDLIST>& root, UINT browseForWhat, char const *title);
char const* GetDisplayName() { return _displayName; }
char const* GetPath() { return _fullPath; }
bool IsOK()const { return _p != 0; };
private:
char _displayName[MAX_PATH];
char _fullPath[MAX_PATH];
BROWSEINFO _browseInfo;
};
FolderBrowser::FolderBrowser(HWND hwndOwner, SShellPtr<ITEMIDLIST>& root, UINT browseForWhat, char const *title) {
_displayName [0] = '\0';
_fullPath [0] = '\0';
_browseInfo.hwndOwner = hwndOwner;
_browseInfo.pidlRoot = root;
_browseInfo.pszDisplayName = _displayName;
_browseInfo.lpszTitle = title;
_browseInfo.ulFlags = browseForWhat;
_browseInfo.lpfn = 0;
_browseInfo.lParam = 0;
_browseInfo.iImage = 0;
// Let the user do the browsing
_p = SHBrowseForFolder(&_browseInfo);
if (_p != 0) SHGetPathFromIDList(_p, _fullPath);
}
Вот так! Разве это не просто?
Далее: Вам, наверное, будет приятно услышать то, что я думаю об OLE?
(обратно)Дефекты OLE
Что является неправильным в OLE
Рассказ посвященного лица
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Вы могли слышать или читать критические мнения относительно OLE. Программисты обычно жалуются на сложность системы подсчета ссылок и недостатосную поддержку наследования. Microsoft обожествляет этот счетчик, говоря, что нет никакого другого способа, и что этот способ является для вас наилучшим[2]. Интерфейсы, как сказано, должно быть ссылочно подсчитаны (refcounted), и имеется мудрый, рубильник обеспечивающий соединение (агрегацию) частей (нежно называемый ухудшением (aggravation) OLE программистами), который обеспечивает те же самые функциональные возможности, что и наследование. Может быть они правы, и проблема взаимодействия с объектами, загружаемыми во время выполнения настолько сложна, что просто не имеется более лучшего способа? С другой стороны, возможно, что OLE имеет фатальный дефект, который только обостряется во всех других местах.
Фатальный дефект проекта OLE — требование того, чтобы была возможность добраться от любого интерфейса до любого другого интерфейса.
Технически это интерфейсное прыгание сделано за счет того, что каждый интерфейс наследует от матери всех интерфейсов IUnknown. IUnknown имеет фатальный метод QueryInterface, который, как предполагается, возвращает любой интерфейс, обеспечиваемый текущим объектом. Это единственное предположение препятствует наличию любой возможности простой реализации наследования. Позвольте мне объясняют почему.
Предположим, что Вы имеете объект FooObj с интерфейсом IFoo. Эта ситуация легко моделируется в C++ при наличии абстрактного класса (все методы — чистые виртуальные) IFoo и конкретного класс FooObj, который наследуется из IFoo и реализует все его методы.
Теперь Вам вдруг захотелось расширить этот объект, добавляя поддержку для другого интерфейса IBar. В C++ это тривиально, Вы только определяете класс FooBarObj, который наследует от FooObj и IBar. Этот новый класс поддерживает интерфейс IFoo вместе с его реализацией через наследование из FooObj. Он также поддерживает интерфейс IBar и обеспечивает реализацию методов IBar.
Любой, кто знает C++, может сделать это с закрытыми глазами. Так, почему же Вы не можете сделать то же самое в OLE? Здесь проявляется Изъян. Вы должны быть способны получить интерфейс IBar из интерфейса IFoo, используя его QueryInterface. Но, подождите минуту, объект FooObj, который обеспечивает реализацию всех методов IFoo, включая QueryInterface, не имеет никаких сведений относительно IBar! Невозможно было даже представить наличие IBar. Так, как же в этой ситуации обеспечить доступ к IBar?
Хороший вопрос. Я не собираюсь входить в кровавые подробности агрегационной рубки, которая, как предполагается, решает эту проблему. Накладываемые ограничения и пороки начального проекта, действительно, изобретательно, рубят. Так имеется ли лучший проект? Читайте дальше…
Можете ли Вы отметить случай, когда были вынуждены проводить различия между объектом, который реализует интерфейсы и интерфейсами непосредственно? Это два полностью различных понятия. Вы не можете объяснить что-нибудь в OLE без того, чтобы не говорить об объектах, иногда называемых компонентами. Интерфейсы важны, но объекты еще более важны. Когда Вы можете получить один интерфейс от другого? Когда они совместно используют один и тот же основной объект. Вы можете изменять состояние объекта, используя один интерфейс и затем исследовать это состояние через другой интерфейс. Очевидно, что это тот же самый объект! В моем примере я описал два интерфейса, IFoo и IBar, и два объекта (или класса объектов), FooObject и FooBarObject.
Фактически, любой, кто реализует интерфейсы (используя C++, C, или Basic) имеет дело с объектами. Однако, эта очень важная абстракция полностью отсутствует с точки зрения клиента OLE. Все, что клиент видит – это интерфейсы. Основной объект подобен призраку.
Но это не призрак. Он физически представлен в адресном пространстве вашей программы, или непосредственно, или как заглушка пересылки. Так, почему скрывают это? Действительно, разве OLE не было бы более простым с явным понятием объекта? Давайте посмотрим, как это работало бы.
Клиент этого «интеллектуального OLE» вызвал бы CoCreateInstance или ClassFactory::CreateInstance, чтобы получить указатель на объект (а не на интерфейс!). Используя этот указатель, клиент вызвал бы QueryInterface, чтобы получить интерфейс. Если бы клиент хотел получить другой интерфейс, он или она сделали бы другое обращение QueryInterface через объект, а не через интерфейс. Вы не могли бы получать интерфейс из другого интерфейса. Только объект обладал бы способностью распределять интерфейсы. Bye, bye IUnknown!
Позвольте мне показать Вам некоторый гипотетический код в этом новом «интеллектуальное OLE».
CoObject* obj CoCreateInstance(CLSID_FooBarObject);
IFoo* foo = obj->QueryInterface(IID_FOO);
foo->FooMethod();
IBar* bar = obj->QueryInterface(IID_BAR);
bar->BarMethod();
delete obj;
Я преднамеренно опустил всю проверку ошибок и подсчет ссылок. Фактически, я не написал бы код, подобный этому, в серьезном приложении, я использовал бы интеллектуальные указатели и исключения. Но обратете внимание на одну вещь, в «интеллектуальном OLE» наследование столь же просто как и в C++. Здесь не имеется никакого способа перейти от интерфейса к интерфейсу и нет никакого IUnknown. Расширение FooObject, добавлением IBar требует не больше работы чем создание FooBarObject, наследующего от FooObject и IBar, реализующего методы IBar и переписывание метода QueryInterface CoObject. Я полагаю, что все «интеллектуальное OLE» объекты наследуют от абстрактного класса CoObject и переопределяют его метод QueryInterface (это очень отличается от наличия всех интерфейсов, наследующих от IUnknown!).
Что сказать о подсчете ссылок? Вполне очевидно, что имеются очень немного потребностей в подсчете ссылок (refcounting), пока Вы соглашаетесь не уничтожать объект, в то время пока Вы используете его интерфейсы. Это не такое большое дело. Мы делаем это все время, когда используем методы в C++. Мы не думаем о том, что это особенно жесткое требование: не уничтожить объект, в то время как мы используем его методы. Если мы должны следовать за текущей моделью OLE везде, мы должны требовать, чтобы клиент получал счетчик ссылок любого метода, который он, или она планируют использовать, а затем освобождать его после вызова? Это было бы абсурдно, не так ли?
Так, почему же OLE так придирчиво считает ссылки? Простое объяснение: потому что это скрывает объект от клиента. OLE-объект создается неявно, когда Вы получаете его первый интерфейс, и разрушается неявно, когда Вы освобождаете его последний интерфейс. Вы видите, что OLE делает для Вас большую пользу, скрывая эту бухалтерию от Вас. Так ли это? Забавный вопрос.
Давным давно, когда машинные языки были все еще в их младенчестве, мастера C, пробовали реализовать стек. Они сделали открытие, что всем клиентам нуждающимся в стеке нужны были две функции, втолкнуть (push) и вытолкнуть (pop). Они также поняли (реализовали), что они должны будут выделить некоторую память, чтобы хранить данные стека и, так как они были опрятные программисты, они будут должны были освободить их, когда клиент был обслужен. Но как они узнали бы, когда клиент был обслужен? Совершенно очевидно, что клиент был обслужен, когда он или она не должны были бы большк выполнять вызовы push или pop. Как только мастера C поняли это, остаток был прост. Стек был создан и память распределялась, когда клиент впервые запрашивал push. Он мог затем вызывать push со специальным параметром, чтобы получить соответствующее pop. Фактически, используя эту схему, он мог создавать столько push и pop, сколько он желал. Затем, когда он был обслужен с заданными push или pop, он просто освобождал бы их. Однократное освобождение всех вталкиваний и выталкиваний привело бы к освобождению стека. Эта гениальная схема чрезвычайно упрощала программирование, потому что клиенты не должны были иметь дело со стеком непосредственно. Система вела всю бухгалтерию. Программисты были в экстазе, и они отдали все их деньги мастерам C. Между прочим, новые функции назывались i_push и i_pop.
Здесь самая лучшая часть истории. Вы могли бы подумать: «О, право, большое дело! Легко придумать эти идеи теперь, после того, как OLE находится на рынке для почти десятилетие». Сообщаю, что искренне Ваш был тем, кто работал когда-то в Microsoft. Вскоре, после выпуска OLE 1.0, я записал эти идеи и послал ответственным людям. Короче говоря, идеи были приняты как допустимые, но отклонены, потому что уже имелось слишком много кода, записанного в спецификациях OLE (обычное дело в Microsoft). Никто из менеджеров не пожелал рисковать, перепроектируя OLE.
Итак, теперь мы имеем подсчет ссылок, агрегацию и все прочее. Мораль истории:
Нет ничего святого, что касается OLE. Это может быть сделано лучше!
Но мы все же можем иметь пирог и есть его? Другими словами, можно формировать «интеллектуальное OLE» на вершине «другого OLE»? Ваша ставка! Идите прямо к следующей обучающей программе.
(обратно)Оболочка из классов для OLE
Рационализация OLE
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Построив интеллектуальное OLE на вершине старого, Вы узнаете другое OLE
Прежде всего Вы должны сообщить миру, что собираетесь использовать OLE. Имеется небольшой класс, который будет делать это за Вас. Только внедрите объект этого класса в некоторый высокоуровневый сконструированный объект прежде, чем Вы что-либо сделаете с OLE и удалите его после того, как отработаете с OLE. В Windows программе первоосновой для UseOle является «Контроллер».
class UseOle {
public:
UseOle() { OleInitialize (0); }
~UseOle() { OleUninitialize (); }
};
class Controller {
public:
Controller(HWND hwnd, CREATESTRUCT* pCreate);
~Controller() { PostQuitMessage(0); }
void Paint(HWND hwnd);
private:
UseOle useOle;
};
Затем Вы должны создать OLE объект, который является поставщиком интерфейсов. Абстрактный класс CoObject объявляет метод AcquireInterface. Фактический класс SObject (интеллектуальный объект) обеспечивает одну специфическую реализацию CoObject, которая использует, внутри себя, позорящий OLE IUnknown.
class CoObject {
public:
virtual void* AcquireInterface (IID const& iid) = 0;
};
class SObject: public CoObject {
public:
SObject(CLSID const& classId, bool running = false);
~SObject() {
if (_iUnk) _iUnk-> Release ();
}
void* AcquireInterface(IID const& iid);
private:
IUnknown * _iUnk;
};
Давайте взглянем на реализации конструктора и метода AcquireInterface.
Конструктор получает объект, вызывая функцию API GetActiveObject и/или CoCreateInstance. Различие между ними в том, что GetActiveObject пытается овладеть уже выполняющимся объектом, в то время как CoCreateInstance пробует то же самое, но, если это терпит неудачу, то запускает любой exe-шник, необходимый для выполнения этого объекта. Некоторые объекты фактически определяют предпочтение: они хотят, чтобы новый сервер был заново запущен каждый раз, когда вызывается CoCreateInstance. GetActiveObject позволяет Вам обойти это.
Обратите внимание, что это — только один пример того, как Вы получаете доступ к OLE объектам. Вы можете захотеть поиграть с некоторыми из параметров. Например, я передаю CLSCTX_SERVER как параметр в CoCreateInstance. Это даст мне уверенность, что объект будет жить в отдельном от клиента процессе. Во многих случаях вам лучше иметь объект как сервер в процессе на основе DLL, которая загружается в адресное пространство клиента. Для больших подробностей ищите описание CoCreateInstance в вашей справке.
SObject::SObject(CLSID cons & classId, bool running) :_iUnk (0) {
HRESULT hr = S_OK;
if (running) {
::GetActiveObject(classid, 0, &_iunk);
}
if (_iUnk == 0) {
hr = ::CoCreateInstance(classId, 0, CLSCTX_SERVER, IID_IUnknown, (void**)&_iUnk);
}
if (FAILED(hr)) throw HEx(hr, "Couldn't create instance");
}
Через мгновение я объясню странный тип исключения HEx.
В нашей реализации AcquireInterface просто вызывает метод QueryInterface из IUnknown (или, как я говорю, неудачный QueryInterface из неудачного IUnknown).
void* SObject::AcquireInterface(IID const& iid) {
void * p = 0;
HRESULT hr = _iUnk->QueryInterface(iid, &p);
if (FAILED(hr)) {
if (hr == E_NOINTERFACE) throw "No such interface";
else throw HEx(hr, "Couldn't acquire interface");
}
return p;
}
Метод AcquireInterface — один из этих исключительных, Получающих методов Управления ресурсами, которые освобождают ресурсы. Мы не вызываем его иначе, как внутри конструктора интеллектуального указателя интерфейса. (Между прочим, параметр шаблона — это IID указатель, потому что компилятор не будет принимать ссылки как параметры шаблона. Я не уверен почему.)
Итак, имеется шаблон для интеллектуального указателя интерфейса.
template<class I, IID const * iid>
class SFace {
public:
~SFace() {
if (_i) _i-> Release();
}
I* operator->() { return _i; }
protected:
SFace() : _i(0) {}
SFace(void * i) {
_i = static_cast<I*>(i);
}
protected:
I * _i;
};
Как видите, этот специфический шаблон не может порождать экземпляры. Дело в том, что все его конструкторы защищены. Но не волнуйтесь, мы создадим другие классы, которые обеспечим их собственными специализированными конструкторами.
Вот один из них, который использует наш CoObject (или любой другой объект, полученный от него) как источник интерфейса.
template<class I, IID const * iid>
class SObjFace: public SFace<I, iid> {
public:
SObjFace(CoObject& obj) : SFace<I, iid>(obj.AcquireInterface(*iid)) {}
};
В заключение позвольте мне представить класс HEx (HRESULT Exception). Это — класс исключения, который является способным к отображению значимых сообщений об ошибках. Для достижения моих ограниченных целей, я просто отображаю сообщения непосредственно на холсте основного экрана. Не бойтесь реализовать ваш собственный метод с использованием окна сообщений или еще чего-нибудь.
class HEx {
public:
HEx(HRESULT hr, char const * str = 0) : _hr (hr), _str (str) {}
void Display(int x, int y, Canvas& canvas) {
if (_str != 0) {
canvas.Text (x, y, _str);
y += 20;
}
if (FAILED (_hr)) {
char * msg;
::FormatMessage(FORMAT_MESSAGE_ALLOCATE_BUFFER | FORMAT_MESSAGE_FROM_SYSTEM, 0, _hr, MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), reinterpret_cast<char*>(&msg), 0, 0);
canvas.Text(x, y, msg);
::LocalFree(msg);
}
}
private:
HRESULT _hr;
char const * _str;
};
Далее: Будет представлен типичный код. Я только должен объяснить, что такое Автоматизация.
Обертка для автоматизации
Автоматизация
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Мне бы хотелось получить море информации из запущенной копии Microsoft Developers Studio. Это должно быть простой задачей, т.к. DevStudio, подобно многим другим приложениям MS, предоставляет его интерфейсы через OLE Автоматизацию. Не столь просто! Как Вы увидите, Microsoft решил, что клиенты интерфейсов автоматизации VC ++ будет или использовать Visual Basic, или внутренних умных мастеров DevStudio. Я, с другой стороны, люблю программировать на C++ (Вам не кажется, что Microsoft Visual C++ должен быть переименован в Microsoft Visual MFC Wizard? Это принизило C++ до роли языка сценариев для MFC.)
В любом случае, когда я выяснил, как надо делать, остальное оказалось не быть слишком трудным. Вы только должны выяснить, где вся необходимая информация сохраняется в реестре. В частности IID всех интерфейсов. Совет: используйте OLE-COM Object Viewer, который поставляется с VC ++, чтобы просмотреть библиотеки типов. Было бы вообще великолепно, если бы Microsoft предоставлял исходные файлы или obj файлы с определениями идентификаторов интерфейсов. В существующей же ситуации я должен копировать их из Object Viewer'а и вставлять их в нужное место. Ниже приводится пример.
static const IID IID_IApplication = {
0xEC1D73A1, 0x8CC4, 0x11CF, { 0x9B, 0xE9, 0x00, 0xA0, 0xC9, 0x0A, 0x63, 0x2C }
};
Итак, как получить управление выполняющейся копией DevStudio? В начале вы должны создать OLE объект. Для этого необходим идентификатор класса этого объекта. Вы можете получить идентификатор класса от системы (эта информация хранится в реестре), если знаете программный идентификатор. Программный идентификатор, устроен так чтобы читаться человеком. Конечно, каждый человек знает, что Developer Studio идет под именем "MSDEV.APPLICATION". Это так просто.
Имея идентификатор класса, мы можем создать наш SObject. Мы передаем значение параметра запуска как true, потому что хотим соединиться с выполняющейся копией MSDEV.APPLICATION, если это возможно. Получение интерфейса из SObject столь же просто как создание экземпляра шаблона SObjFace с соответствующими параметрами. Итак, нашей отправной точкой будет, интерфейс к приложению.
CLSID idMsDev;
HRESULT hr = ::CLSIDFromProgID(L"MSDEV.APPLICATION", &idMsDev);
if (FAILED (hr)) throw HEx(hr, "Couldn't convert prog id to class id");
SObject obj(idMsDev, true);
SObjFace<IApplication, &IID_IApplication> app(obj);
Обратите внимание, что строка, которую Вы передаете к CLSIDFromProgID, должна использовать кодировку Unicode. Помещение L перед строковым литералом обеспечивает это.
Я надеюсь, что Вы можете оценить простоту этого кода. Он почти столь же прост, как и его VB эквивалент.
Dim app as Application
Set app = GetObject(, "MSDEV.APPLICATION")
if (app = NULL)
Set app = CreateObject("MSDEV.APPLICATION")
Теперь давайте что-нибудь сделаем с этим интерфейсом. Так случилось, что IApplication имеет член Visible, который Вы можете установить или получить. Когда Вы устанавливаете Visible в истину, окно приложения становится видимым. Ниже приводится синтаксис для «установки» члена. Обратите внимание, что в OLE Вы должны использовать обозначения с именами VARIANT_BOOL и VARIANT_TRUE вместо bool и true. Это делается ради совместимости с Basic (что делает Билла счастливым).
VARIANT_BOOL b = VARIANT_TRUE;
app->put_Visible(b);
Как я узнал, что IApplication имеет член Visible? Хороший вопрос! Имеется подкаталог objmodel в VC ++, в каталоге include, где Вы можете отыскать такие файлы как Appauto.h, которые содержат строки, подобные одной из показанных ниже. Вы можете проводить выборочное изучение, чтобы интерпретировать эти файлы. Их критика связана с (глупым!) требованием, чтобы они включались как в C, так и в C++ код. А Microsoft не захотела поддерживать два набора заголовочных файлов, поэтому здесь мы поступаем так.
STDMETHOD(get_Visible)(THIS_ VARIANT_BOOL FAR* Visible) PURE;
STDMETHOD(put_Visible)(THIS_ VARIANT_BOOL Visible) PURE;
Так, что же мы делаем дальше, когда приложение в наших руках? Как насчет выяснения того, какой документ является в настоящее время активным? Используя интерфейс IApplication в качестве источника, мы можем создавать другой OLE объект, который представит активный документ. Этот специфический OLE объект, SActiveDocument, может использоваться как источник нескольких интерфейсов, одним из которых является IGenericDocument. Мы захватываем этот интерфейс стандартным способом — создавая объект с помощью шаблона SObjFace. SActiveDocument, подобно всем нашим объектам OLE/COM, наследует от CoObject, исходные интерфейсы.
IGenericDocument имеет член FullName, который может быть получен, вызовом метода get_FullName. К сожалению, совместимость с Basic снова наносит удар: результат передается в форме BSTR, или Basic строки. Я создал два вспомогательных класса BString и CString, чтобы заботиться о этой сверхъестественности. В частности BString удостоверяется, что строка освобождена, используя при этом функцию API SysFreeString.
SActiveDocument docObj(app);
if (docObj) {
SObjFace<IGenericDocument, &IID_IGenericDocument> doc(docObj);
BString bPath;
doc->get_FullName(bPath.GetPointer());
CString path(bPath);
canvas.Text(20, y, "Active Document:");
canvas.Text (200, y, path);
}
Это типичная ситуация для OLE Автоматизации. Используя интерфейсный метод одного приложения (app в данном случае) Вы овладеваете другим объектом (docObj) и его собственными интерфейсами. Для каждого такого метода, возвращающего объект, мы создадим новый класс интеллектуальных указателей, которые отличаются только возможностями их конструкторов. Например, имеется класс SActiveDocument.
class SActiveDocument: public DispObject {
public:
SActiveDocument(SObjFace<IApplication, &IID_IApplicationication> &app) {
HRESULT hr = app->get_ActiveDocument(&_idisp);
if (FAILED (hr)) throw HEx(hr, "get_ActiveDocument failed");
}
};
Обратите внимание, что базовый класс SActiveDocument — не SObject. Это новый класс DispObject. Он почти подобен SObject с одним лишь различием внутри: вместо использования указателя на IUnknown, он использует указатель на IDispatch. Это имеет значение? Реально — нет, я мог бы использовать SObject и все, работало бы также. За исключением того, что IDISPATCH может использоваться для большего чем запрос только других интерфейсов. Он может использоваться для динамической диспетчеризации вызовов. Так как наша программа написана на C++, и она знает все предоставленные интерфейсы, мы в действительности можем не использовать динамическую диспетчеризацию. Но имеются ситуации, в которых Вы должны дать пользователю возможность решить в реальном времени: какой объект загрузить и какой метод вызвать. Интерпретаторы и языки сценариев позволяют делать это. В частности, Visual Basic, являющийся инструментом для написания сценариев имеет такие функциональные возможности.
Ниже представлена скелетная реализация DispObject, которая демонстрирует эту возможность. Она также объясняет, почему мы говорили о таких «членах», как Visible или FullName при обсуждении интерфейсов. В VB они фактически появляются как элементы данных, или как реквизиты, объектов. Здесь, я реализовал диспетчерский метод GetProperty, который используется, чтобы загрузить значение любого свойства, по его DISPID. И Вы можете получать DISPID любого свойства или метода, если Вы знаете его имя. Метод GetDispId будет делать это для Вас. Подобным способом, Вы можете реализовать и PutProperty, а также Invoke, который может использоваться, чтобы вызвать любой метод по его DISPID. Я оставляю это как упражнение для читателя.
class DispObject: public CoObject {
public:
DispObject(CLSID const& classId) : _iDisp(0) {
HRESULT hr = ::CoCreateInstance(classId, 0, CLSCTX_ALL, IID_IDispatch, (void**)&_iDisp);
if (FAILED(hr)) {
if (hr == E_NOINTERFACE) throw "No IDispatch interface";
else throw HEx(hr, "Couldn't create DispObject");
}
}
~DispObject() {
if (_iDisp) _iDisp->Release();
}
operator bool() const { return _iDisp != 0; }
bool operator!() const { return _iDisp == 0; }
DISPID GetDispId(WCHAR* funName) {
DISPID dispid;
HRESULT hr = _iDisp->GetIDsOfNames(IID_NULL, &funName, 1, GetUserDefaultLCID(), &dispid);
return dispid;
}
void GetProperty(DISPID propId, VARIANT& result) {
// In parameters
DISPPARAMS args = { 0, 0, 0, 0 };
EXCEPINFO except;
UINT argErr;
HRESULT hr = _iDisp->Invoke(propId, IID_NULL, GetUserDefaultLCID(), DISPATCH_PROPERTYGET, &args, &result, &except, &argErr);
if (FAILED (hr)) throw HEx(hr, "Couldn't get property");
}
void* AcquireInterface(IID const & iid) {
void* p = 0;
HRESULT hr = _iDisp->QueryInterface(iid, &p);
if (FAILED(hr)) {
if (hr == E_NOINTERFACE) throw "No such interface";
else throw HEx(hr, "Couldn't query interface");
}
return p;
}
protected:
DispObject(IDispatch * iDisp) : _iDisp(iDisp) {}
DispObject() : _iDisp(0) {}
protected:
IDispatch* _iDisp;
};
Ниже приводится небольшая иллюстрация динамической диспетчеризации. Конечно, тот же самый результат мог быть получен непосредственно, если вызвать метод get_Name интерфейса IGenericDocument. Мы рассмотрим этот непосредственный метод, использующий таблицу виртуальных фунций через мгновение, чтобы получить полный путь документа.
// Use docObj as a dispatch interface
DISPID pid = docObj.GetDispId(L"Name");
VARIANT varResult;
::VariantInit(&varResult);
docObj.GetProperty(pid, varResult);
BString bName(varResult);
CString cName(bName);
canvas.Text(20, y, "Name:");
canvas.Text(200, y, cName);
Это показывает, как Вы получаете путь, используя таблицу виртуальных функций (vtable).
SObjFace<IGenericDocument, &IID_IGenericDocument> doc(docObj);
BString bPath;
doc->get_FullName(bPath.GetPointer());
Теперь у Вас не должно быть каких-либо проблем при понимании кода, который определяет номер строки, на которой пользователь позиционировал курсор.
BString bType;
doc->get_Type(bType.GetPointer());
if (type.IsEqual("Text")) {
SObjFace<ITextDocument, &IID_ITextDocument> text (docObj);
SSelection selObj(text);
SObjFace<ITextSelection, &IID_ITextSelection> sel(selObj);
long line;
sel->get_CurrentLine(&line);
canvas.Text(20, y, "CurrentLine:");
char buf[10];
wsprintf(buf, "%ld", line);
canvas.Text(200, y, buf);
}
SSelection — это DispObject, который может быть получен, вызовом метода get_Selection интерфейса текстового документа.
class SSelection: public DispObject {
public:
SSelection(SObjFace<ITextDocument, &IID_ITextDocument>& doc) {
HRESULT hr = doc->get_Selection(& _iDisp);
if (FAILED(hr)) throw HEx(hr, "get_Selection failed");
}
};
У Вас могут быть небольшие трудности, если это — ваш первый контакт с OLE (преуменьшение!). Поэтому, ниже подводятся некоторые итоги, которые суммируют различные действия, позволяющие упростить задачу Автоматизации. Обратите внимание, что это — клиентская сторона уравнения. Если Вы хотите, чтобы ваше приложение было сервером Автоматизации, то ожидайте некоторых усложнений. Хорошо то, что имеется большое количество литературы по этим вопросам.
Итак здесь изложено то, что Вы должны сделать.
• Исследование
○ Проведите поиск в вашем реестре (используя RegEdt32 или OLE/COM object viewer) чтобы найти ProgID приложения, которым Вы хотите овладеть. HKEY_CLASSES_ROOT — отправная точка. Вы увидите там такие ключи как Word.Application, Excel.Application и многие другие.
○ Отыщите библиотеки типов, используя OLE/COM object viewer. Они предоставят идентификаторы классов и идентификаторы интерфейсов, которые Вы должны скопировать и вставить в ваш код.
○ Найдите заголовочные файлы для этих интерфейсов.
• В вашей программе: Преобразуйте ProgID в ClassID.
• Чтобы соединяться с выполняющимся приложением или активизировать новый экземпляр, создайте SObject, используя ClassID.
• Получите интерфейс IApplication из объекта (используйте шаблон IObjFace).
○ Используйте этот интерфейс, чтобы получить доступ к другим объектам внутри приложения. Для каждого такого объекта:
○ Объявите класс, наследующий от DispObject.
○ В его конструкторе используйте соответствующий get_* метод, чтобы получить доступ к внутреннему объекту.
○ Создайте объект этого класса, передавая его интерфейс родительскому объекту.
○ Получите соответствующий интерфейс из этого объекта используя шаблон IObjFace.
○ Вызовите соответствующие методы этого интерфейса.
Итак, во что бы это вылилось при подсчете ссылок OLE? Победите меня! Они должны были исчезнуть, если только использовать правильную инкапсуляцию. Ниже приведена диаграмма зависимостей классов. OLE объекты — слева, OLE интерфейсы — справа.
Во временя выполнения, Вы начинаете с SObject, представляющего программу, которую вы связываете. Затем обеспечиваете доступ из объекта к интерфейсу и от интерфейса к DispObject. Вы используете объекты как источники интерфейсов и интерфейсы для вызова специфических методов и получения других объектов.
В заключение. Вы можете загрузить исходный текст примера, который иллюстрирует применение этих методов.
Далее: Создание разделителя окон (сплиттера).
(обратно)Как разделить окно на части
Разделительная полоска (сплиттер)
Перевод А. И. Легалова
Англоязычный оригинал находится на сервере компании Reliable Software
Разделительная полоска — полезный элемент, который не входит в состав элементову правления Windows. Насколько трудной его реализовать? Не столь трудно, как это кажется, если Вы знаете хотя бы основы Windows API. Представленное описание может в начале показаться сложным, но вы изучите несколько очень важных методов, которые могут многократно использоваться в различных местах. Работа с дочерними окнами, сбор данных от мыши, рисование с использованием xor (исключающего или) режима — вот только некоторые из них.
Сплиттер — это окно. Точнее — это дочернее окно. Оно позиционировано между двумя другими дочерними окнами — мы назовем их левым и правым подокном, соответственно (или верхним и нижним для горизонтального расщепителя). Должно также быть основное окно, явялющееся родителем для трех дочерних.
Без дальнейшей суеты приведем код WinMain, который осуществляет начальные установки.
// Create top window class
TopWinClassMaker topWinClass(WndProcMain, ID_MAIN, hInst, ID_MAIN);
topWinClass.Register();
// Create child pane classes
WinClassMaker paneClass(WndProcPane, IDC_PANE, hInst);
paneClass.SetSysCursor(IDC_IBEAM);
paneClass.SetDblClicks();
paneClass.Register();
Splitter::RegisterClass(hInst);
// Create top window
ResString caption(hInst, ID_CAPTION);
TopWinMaker topWin(caption, ID_MAIN, hInst);
topWin.Create();
topWin.Show(cmdShow);
В начале мы регистрируем классы. Верхний оконный класс связан с его оконной процедурой WndProcMain, которую мы рассмотрим через мгновение. Два дочерних подокна совместно используют тот же самый класс окна, связанный с WndProcPane. Затем регистрируется наш собственный класс сплиттера (мы скоро увидем его код). В заключение, создается и отображается верхнее окно. Дочерние окна создаются динамически во время инициализации родительского окна.
Приведем оконную процедуру верхнего окна.
LRESULT CALLBACK WndProcMain(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) {
Controller* pCtrl = GetWinLong<Controller *>(hwnd);
switch (message) {
case WM_CREATE:
try {
pCtrl = new Controller(hwnd, reinterpret_cast<CREATESTRUCT *>(lParam));
SetWinLong<Controller*>(hwnd, pCtrl);
} catch (char const* msg) {
MessageBox(hwnd, msg, "Initialization", MB_ICONEXCLAMATION | MB_OK);
return -1;
} catch (...) {
MessageBox(hwnd, "Unknown Error", "Initialization", MB_ICONEXCLAMATION | MB_OK);
return -1;
}
return 0;
case WM_SIZE:
pCtrl->Size(LOWORD(lParam), HIWORD(lParam));
return 0;
case MSG_MOVESPLITTER:
pCtrl->MoveSplitter(wParam);
return 0;
case WM_DESTROY:
SetWinLong<Controller*>(hwnd, 0);
delete pCtrl;
return 0;
}
return ::DefWindowProc(hwnd, message, wParam, lParam);
}
Имеем обычную оконную процедуру за исключением одного сообщения: MSG_MOVESPLITTER. Это — наше собственное, определяемое пользователем сообщение, которое послано сплиттером его родительскому окну. Но сначала давайте взглянем на контроллер главного окна.
class Controller {
public:
Controller(HWND hwnd, CREATESTRUCT* pCreat);
~Controller();
void Size(int cx, int cy);
void MoveSplitter(int x);
private:
enum { splitWidth = 8 }; // width of splitter
// User Interface
HWnd _hwnd;
//Main controller window
HWnd _leftWin;
HWnd _rightWin;
HWnd _splitter;
int _splitRatio; // in per cent
int _cx;
int _cy;
};
Контроллер содержит дескриптор своего окна, двух дочерних подокон, и окна сплиттера. Он также сохраняет текущий коэффициент разбиения, в процентах.
Конструктор контроллера отвечает за создание дочерних окон.
Controller::Controller(HWND hwnd, CREATESTRUCT * pCreat) : _hwnd (hwnd), _leftWin (0), _rightWin (0), _splitter (0), _splitRatio (50) {
// Create child windows
{
ChildWinMaker leftWinMaker(IDC_PANE, _hwnd, ID_LEFT_WINDOW);
leftWinMaker.Create();
_leftWin.Init(leftWinMaker);
leftWinMaker.Show();
}
{
ChildWinMaker rightWinMaker(IDC_PANE, _hwnd, ID_RIGHT_WINDOW);
rightWinMaker.Create();
_rightWin.Init(rightWinMaker);
rightWinMaker.Show();
}
Splitter::MakeWindow(_splitter, _hwnd, ID_SPLITTER);
}
Когда пользователь перемещает полоску расщепителя, родитель получает сообщение MSG_MOVESPLITTER . Параметр wParam содержит новое расстояние полосы расщепителя от левого края родительского окна. В ответ на такое сообщение, родитель должен также изменить размеры дочерних подокон и переместить расщепитель. Он делает это, вызывая метод Size.
void Controller::MoveSplitter(int x) {
_splitRatio = x * 100 / _cx;
if (_splitRatio < 0) _splitRatio = 0;
else if (_splitRatio > 100) _splitRatio = 100;
Size(_cx, _cy);
}
Вообще же, Size вызывается всякий раз, когда пользователь изменяет размеры основного окна, но тот код который вытолько что видели, мы вызываем также тогда, когда сплиттер перемещается.
void Controller::Size(int cx, int cy) {
_cx = cx;
_cy = cy;
int xSplit = (_cx * _splitRatio) / 100;
if (xSplit < 0) xSplit = 0;
if (xSplit + splitWidth >= _cx) xSplit = _cx - splitWidth;
_splitter.MoveDelayPaint(xSplit, 0, splitWidth, cy);
_leftWin.Move(0, 0, xSplit, cy);
_rightWin.Move(xSplit+splitWidth, 0, cx-xSplit-splitWidth, cy);
_splitter.ForceRepaint ();
}
Обратите внимание на используемый здесь важный прием. Мы перемещаем расщепитель, но задерживаем его перерисовку до изменения его обоих подокон, расположенных слева и справа. Эта методика устраняет некоторое неприятное смазывание изображения.
Выше была представлена реализация клиентского кода. Теперь, я надеюсь, Вам будет интересно увидеть реализацию сплиттера.
Прежде всего нам приятно объединить зависимые функции в пространство имен. Вам видны вызовы Splitter::RegisterClass и Splitter::MakeWindow. Splitter в этих именах — это namespace.
namespace Splitter {
void RegisterClass(HINSTANCE hInst);
void MakeWindow(HWnd& hwndSplitter /* out */, HWnd hwndParent, int childId);
};
Ниже приводится реализация этих функций.
LRESULT CALLBACK WndProcSplitter(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam);
void Splitter::RegisterClass(HINSTANCE hInst) {
WinClassMaker splitterClass(WndProcSplitter, "RsSplitterClass", hInst);
splitterClass.SetSysCursor(IDC_SIZEWE);
splitterClass.SetBgSysColor(COLOR_3DFACE);
splitterClass.Register();
}
void Splitter::MakeWindow(HWnd& hwndSplitter, HWnd hwndParent, int childId) {
ChildWinMaker splitterMaker("RsSplitterClass", hwndParent, childId);
splitterMaker.Create(); hwndSplitter.Init(splitterMaker);
splitterMaker.Show();
}
Курсор мыши IDC_SIZEWE мы связываем с классом расщепителя — это стандартная, «направленная с запада на восток», двунаправленная стрелка. Мы также устанавливаем фоновую кисть к COLOR_3DFACE.
Оконная процедура расщепителя имеет дело с созданием/разрушением расщепителя, прорисовкой и перемещением мыши.
LRESULT CALLBACK WndProcSplitter(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) {
SplitController* pCtrl = GetWinLong<SplitController*>(hwnd);
switch (message) {
case WM_CREATE:
try {
pCtrl = new SplitController(hwnd, reinterpret_cast<CREATESTRUCT *>(lParam));
SetWinLong<SplitController*>(hwnd, pCtrl);
} catch (char const * msg) {
MessageBox(hwnd, msg, "Initialization", MB_ICONEXCLAMATION | MB_OK);
return -1;
} catch (...) {
MessageBox(hwnd, "Unknown Error", "Initialization", MB_ICONEXCLAMATION | MB_OK);
return -1;
}
return 0;
case WM_SIZE:
pCtrl->Size(LOWORD(lParam), HIWORD(lParam));
return 0;
case WM_PAINT:
pCtrl->Paint();
return 0;
case WM_LBUTTONDOWN:
pCtrl->LButtonDown(MAKEPOINTS(lParam));
return 0;
case WM_LBUTTONUP:
pCtrl->LButtonUp(MAKEPOINTS(lParam));
return 0;
case WM_MOUSEMOVE:
if (wParam & MK_LBUTTON) pCtrl->LButtonDrag(MAKEPOINTS(lParam));
return 0;
case WM_CAPTURECHANGED:
pCtrl->CaptureChanged();
return 0;
case WM_DESTROY:
SetWinLong<SplitController*>(hwnd, 0);
delete pCtrl;
return 0;
}
return ::DefWindowProc(hwnd, message, wParam, lParam);
}
Это, в значительной степени, стандартный код. Подробности, как обычно, находятся в методах контроллера. Конструктор очень прост.
SplitController::SplitController(HWND hwnd, CREATESTRUCT * pCreat) : _hwnd (hwnd), _hwndParent (pCreat->hwndParent) {}
Прорисовка более интересна. Мы должны имитировать эффекты 2.5-размерности Windows. Мы делаем это путем тщательного отбора перьев.
class Pens3d {
public:
Pens3d();
Pen& Hilight() { return _penHilight; }
Pen& Light() { return _penLight; }
Pen& Shadow() { return _penShadow; }
Pen& DkShadow() { return _penDkShadow; }
private:
Pen _penHilight;
Pen _penLight;
Pen _penShadow;
Pen _penDkShadow;
};
Pens3d::Pens3d() : _penLight(GetSysColor(COLOR_3DLIGHT)), _penHilight(GetSysColor(COLOR_3DHILIGHT)), _penShadow(GetSysColor(COLOR_3DSHADOW)), _penDkShadow(GetSysColor(COLOR_3DDKSHADOW)) {}
void SplitController::Paint() {
PaintCanvas canvas(_hwnd);
{
PenHolder pen(canvas, _pens.Light());
canvas.Line(0, 0, 0, _cy - 1);
}
{
PenHolder pen(canvas, _pens.Hilight());
canvas.Line(1, 0, 1, _cy - 1);
}
{
PenHolder pen(canvas, _pens.Shadow());
canvas.Line(_cx - 2, 0, _cx - 2, _cy - 1);
}
{
PenHolder pen(canvas, _pens.DkShadow());
canvas.Line(_cx - 1, 0, _cx - 1, _cy - 1);
}
}
Более сложной является обработка сообщений от мыши, хотя значительная часть этого кода довольно стандартна. Мы должны обработать перемещение мыши и нажатие кнопки.
void SplitController::LButtonDown(POINTS pt) {
_hwnd.CaptureMouse();
// Find x offset of splitter
// with respect to parent client area POINT
ptOrg = {0, 0};
_hwndParent.ClientToScreen(ptOrg);
int xParent = ptOrg.x;
ptOrg.x = 0;
_hwnd.ClientToScreen(ptOrg);
int xChild = ptOrg.x;
_dragStart = xChild - xParent + _cx / 2 - pt.x;
_dragX = _dragStart + pt.x;
// Draw a divider using XOR mode
UpdateCanvas canvas(_hwndParent);
ModeSetter mode(canvas, R2_NOTXORPEN);
canvas.Line (_dragX, 0, _dragX, _cy - 1);
}
Когда левая кнопка мыши нажата над клиентской областью расщепителя, мы выполняем следующие задачи. Сначала мы фиксируем мышь. Пользователь может и, возможно будет, перемещают курсор мыши вне полоски расщепителя. Фиксация мыши гарантирует, что все ее сообщения будут теперь направлены к нам, даже в том случае, когда курсор мыши будет блуждать по всему экрану.
Затем мы преобразуем локальные координаты сплиттера в координаты родительского окна. Мы делаем это конвертацией начальных координат родителя к экранным координатам координатам дисплея и преобразованием начальные координаты нашего расщепителя также к экранным координатам дисплея. Разница дает нам начальное положение относительно клиентской области родителя. Мы делаем дополнительные арифметические вычисления, чтобы найти координату x центра расщепителя, потому что это - то, что мы будем перемещать.
Чтобы предоставить пользователю, перемещающему сплиттер, обратную связь, мы рисуем одиночную вертикальную линию, которую будем перемещать поперек клиентской области родительского окна. Обратите внимание на две важных детали. Холст, который мы создаем, связан с родителем — мы используем дескриптор окна родителя. Режим перерисовки использует логическую операцию xor (исключающее или). Это означает, что пикселы, которые мы рисуем, — конвертируются с первоначальными пикселами с использованием xor. Логическая операция xor имеет полезную особенность. Если Вы примените ее дважды, Вы восстановите оригинал. Этот самый старый прием в компьютерной графике — метод простой анимации. Вы рисуете что-то, используя xor режим и стираете простым рисованием его же снова в xor режиме. Итак, рассмотрим код перемещения, представленный ниже.
void SplitController::LButtonDrag(POINTS pt) {
if (_hwnd.HasCapture()) {
// Erase previous divider and draw new one
UpdateCanvas canvas(_hwndParent);
ModeSetter mode(canvas, R2_NOTXORPEN);
canvas.Line(_dragX, 0, _dragX, _cy - 1);
_dragX = _dragStart + pt.x;
canvas.Line(_dragX, 0, _dragX, _cy - 1);
}
}
Мы рисуем вертикальную линию в xor режиме, используя предыдущую сохраненную позицию. Так как это рисование происходит во второй раз, мы рисуем эту линию в том же самом месте и, в результате, будут восстановлены первоначальные пикселы из-под этой линии. Затем мы рисуем новую линию в новой позиции, также в xor режиме. Мы запоминаем эту позицию, чтобы в следующий раз, когда вызовется LButtonDrag, мы могли стереть ее также. И так далее, пока пользователь не отпустит кнопку мыши.
void SplitController::LButtonUp(POINTS pt) {
// Calling ReleaseCapture will send us the WM_CAPTURECHANGED
_hwnd.ReleaseMouse();
_hwndParent.SendMessage(MSG_MOVESPLITTER, _dragStart + pt.x);
}
В этой точке мы должны стереть вертикальную строку в последний раз. Однако, мы не делаем это непосредственно — мы используем здесь небольшой прием. Мы прекращаем сбор данных мыши. Как побочный эффект, Windows посылает нам сообщение WM_CAPTURECHANGED. Во время обработки этого сообщения, мы фактически и стираем вертикальную строку.
void SplitController::CaptureChanged() {
// We are losing capture
// End drag selection -- for whatever reason
// Erase previous divider
UpdateCanvas canvas(_hwndParent);
ModeSetter mode(canvas, R2_NOTXORPEN);
canvas.Line(_dragX, 0, _dragX, _cy - 1);
}
Почему мы делаем это таким образом? Потому, что Windows может заставить нас, прекратить обработку данных от мыши прежде, чем пользователь опустит ее кнопку. Это может случиться, например, когда другое приложение внезапно решает распахнуть его окно, в то время как пользователь находится в процессе перемещения. В этом случае наше окно никогда не получило бы сообщение об отжатии кнопки. Если бы мы не были так умны, мы бы не были способны чисто перемещаться. К счастью, перед завершением обработки данных мыши, Windows сумеет послать нам сообщение WM_CAPTURECHANGED, и мы примем его к сведению, чтобы сделать нашу очистку.
Вернемся снова к LBUTTONUP — когда пользователь заканчивает перемещение, мы посылаем родителю наше специальное сообщение MSG_MOVESPLITTER, передавая ему новую позицию центра полосы расщепителя, измеряемой в координатах клиентской области родителя. Вы уже видели клиентский код, реагирующий на это сообщение.
Здесь показано, как можно определить клиентское сообщение.
// Reserved by Reliable Software Library
const UINT MSG_RS_LIBRARY = WM_USER + 0x4000;
// wParam = new position wrt parent's left edge
const UINT MSG_MOVESPLITTER = MSG_RS_LIBRARY + 1;
В заключение представлен фрагмент из очень полезного класса HWnd, который инкапсулирует многие базисных функции API Windows, имеющие дело с окнами. В частности, рассмотрите методы MoveDelayPaint и ForceRepaint, который мы использовали в перерисовке полоски расщепителя.
class HWnd {
public:
void Update() {
::UpdateWindow(_hwnd);
}
// Moving
void Move(int x, int y, int width, int height) {
::MoveWindow(_hwnd, x, y, width, height, TRUE);
}
void MoveDelayPaint(int x, int y, int width, int height) {
::MoveWindow(_hwnd, x, y, width, height, FALSE);
}
// Repainting
void Invalidate() {
::InvalidateRect(_hwnd, 0, TRUE);
}
void ForceRepaint() {
Invalidate();
Update();
}
private:
HWND _hwnd;
};
Как обычно, Вы можете загрузить полный исходный текст приложения, которое использовалось в этом примере.
Далее: Следующая обучающая программа рассказывает о растрах.
(обратно)Bitmaps
In this tutorial we'll learn how to load bitmaps from resources and from files, how to pass them around and blit them to the screen. We'll also see how to create and use an empty bitmap as a canvas, draw a picture on it and then blit it to the screen. Finally, we'll combine these techniques to write a simple program that uses double-buffering and timer messages to show a simple animation involving sprites.
First of all, in most cases Windows provides storage for bitmaps and takes care of the formatting of bits. The programmer gets access to the bitmap through a handle, whose type is HBITMAP. (Remember to set the STRICT flag when compiling Windows programs, to make sure HBITMAP is a distinct type, rather than just a pointer to void.)
Since a bitmap is a resource (in the Resource Management sense), the first step is to encapsulate it in a “strong pointer” type of interface. Notice the transfer semantics of the constructor and the overloaded assignment operator, characteristic of a resource that can have only one owner at a time.
We instruct Windows to release the resources allocated to the bitmap by calling DeleteObject.
class Bitmap {
public:
Bitmap() : _hBitmap (0) {}
// Transfer semantics
Bitmap(Bitmap& bmp) : _hBitmap(bmp.Release()) {}
void operator=(Bitmap& bmp) {
if (bmp._hBitmap != _hBitmap) {
Free();
_hBitmap = bmp.Release();
}
}
HBITMAP Release() {
HBITMAP h = _hBitmap;
_hBitmap = 0;
return h;
}
~Bitmap() {
Free();
}
// implicit conversion for use with Windows API
operator HBITMAP() {
return _hBitmap;
}
protected:
Bitmap(HBITMAP hBitmap) : _hBitmap(hBitmap) {}
void Free() {
if (_hBitmap) ::DeleteObject(_hBitmap);
}
HBITMAP _hBitmap;
};
Now that the management issues are out of the way, we can concentrate on loading bitmaps. The simplest way to include a bitmap in your program is to add it to the resource file. In the resource editor of your development environment you can create new bitmaps or import them from external files. You can either give them names (strings) or numerical ids. When you want to access such a bitmap in your program you have to load it from the resources. Here are two methods that do just that. You have to give them a handle to the program instance.
void Bitmap::Load(HINSTANCE hInst, char const * resName) {
Free();
_hBitmap = (HBITMAP)::LoadImage(hInst, resName, IMAGE_BITMAP, 0, 0, LR_CREATEDIBSECTION);
if (_hBitmap == 0) throw WinException("Cannot load bitmap from resources", resName);
}
void Bitmap::Load(HINSTANCE hInst, int id) {
Free();
_hBitmap = (HBITMAP)::LoadImage(hInst, MAKEINTRESOURCE(id), IMAGE_BITMAP, 0, 0, LR_CREATEDIBSECTION);
if (_hBitmap == 0) throw WinException("Cannot load bitmap from resources");
}
Loading a bitmap directly from a file is also very simple and can be done using the same API, LoadImage. Remember, it will only work if the file is a Windows (or OS/2) bitmap — such files usually have the extension .bmp. There is no simple way of loading other types of graphics files, .gif, .jpg, .png, etc. You have to know their binary layout and decode them explicitly (there are other web sites that have this information).
void Bitmap::Load(char* path) {
Free();
_hBitmap = (HBITMAP)::LoadImage(0, path, IMAGE_BITMAP, 0, 0, LR_LOADFROMFILE);
if(_hBitmap == 0) throw WinException("Cannot load bitmap from file", path);
}
Once you got hold of a bitmap, you may want to enquire about its dimensions. Here's how you do it.
void Bitmap::GetSize(int& width, int& height) {
BITMAP bm;
::GetObject(_hBitmap, sizeof(bm), &bm);
width = bm.bmWidth;
height = bm.bmHeight;
}
Finally, you might want to create an empty bitmap and fill it with your own drawings programmatically. You have to specify the dimensions of the bitmap and you have to provide a device context (Canvas) for which the bitmap is targeted. Windows will create a different type of bitmap when your target is a monochrome monitor or printer, and different when it's a graphics card set to True Color. Windows will create a bitmap that is compatible with the target device.
Bitmap::Bitmap(Canvas& canvas, int dx, int dy) : _hBitmap (0) {
CreateCompatible(canvas, dx, dy);
}
void Bitmap::CreateCompatible(Canvas& canvas, int width, int height) {
Free();
_hBitmap = ::CreateCompatibleBitmap(canvas, width, height);
}
How do you display the bitmap on screen? You have to blit it. Blit stands for "block bit transfer" or something like that. When you blit a bitmap, you have to specify a lot of parameters, so we'll just encapsulate the blitting request in a separate object, the blitter. This is a very handy object that sets the obvious defaults for blitting, but at the same time lets you override each and any of them.
A blitter transfers a rectangular area of the bitmap into a rectangular area of the screen. The meaning of various parameters is the following:
• Source position: pixel coordinates of the upper left corner of the bitmap area, to be transferred. The default is the upper left corner of the bitmap.
• Destination position: pixel coordinates within the target window of the upper left corner of the transferred area. The default is upper left corner of the window.
• Area dimensions: the dimensions of the rectangular area to be transferred. The default is the dimensions of the bitmap.
• Transfer mode. The way bitmap pixels are combined with existing window pixels. The default, SRCCOPY, copies the pixels over existing pixels. You may also specify more involved logical operations, like SRCAND (Boolean AND), SRCPAINT (Boolean OR), etc. (see your compiler's help on BitBlt).
class Blitter {
public:
Blitter(Bitmap& bmp) : _bmp (bmp), _mode (SRCCOPY), _xDst (0), _yDst (0), _xSrc (0), _ySrc (0) {
bmp.GetSize(_width, _height);
}
void SetMode(DWORD mode) {
_mode = mode;
}
void SetDest(int x, int y) {
_xDst = x;
_yDst = y;
}
void SetSrc(int x, int y) {
_xSrc = x;
_ySrc = y;
}
void SetArea(int width, int height) {
_width = width;
_height = height;
}
// transfer bitmap to canvas
void BlitTo(Canvas & canvas);
private:
Bitmap& _bmp;
int _xDst, _yDst;
int _xSrc, _ySrc;
int _width, _height;
DWORD _mode;
};
The BlitTo method performs the transfer from the bitmap to the window (or printer) as described by its Canvas.
void Blitter::BlitTo(Canvas& canvas) {
// Create canvas in memory using target canvas as template
MemCanvas memCanvas (canvas);
// Convert bitmap to the format appropriate for this canvas
memCanvas.SelectObject(_bmp);
// Transfer bitmap from memory canvas to target canvas
::BitBlt(canvas, _xDst, _yDst, _width, _height, memCanvas, _xSrc, _ySrc, _mode);
}
The API, BitBlt, transfers bits from one device to another. That's why we have to set up a fake source device. This "memory canvas" is based on the actual canvas--in this case we use target canvas as a template. So, for instance, if the target canvas describes a True Color device, our MemCanvas will also behave like a True Color device. In particular, when our bitmap is selected into it, it will be converted to True Color, even if initially it was a monochrome or a 256-color bitmap.
The simplest program that loads and displays a bitmap might look something like this: There is a View object that contains a bitmap (I assume that the file "picture.bmp" is located in the current directory). It blits it to screen in the Paint method.
class View {
public:
View() {
_background.Load("picture.bmp");
}
void Paint(Canvas& canvas) {
Blitter blitter(_background);
blitter.BlitTo(canvas);
}
private:
Bitmap _background;
};
A sprite is an animated bitmap that moves over some background. We already know how to display bitmaps — we could blit the background first and then blit the sprite bitmap over it. This will work as long as the sprite is rectangular. If you want to be more sophisticated and use a non-rectangular sprite, you need a mask.
The two pictures below are that of a sprite (my personal pug, Fanny) and its mask. The mask is a monochrome bitmap that has black areas where we want the sprite to be transparent. The sprite, on the other hand, must be white in these areas. What we want is to be able to see the background through these areas.
The trick is to first blit the background, then blit the mask using logical OR, and then blit the sprite over it using logical AND.
ORing a black mask pixel (all zero bits) with a background pixel will give back the background pixel. ORing a white mask pixel (all one bits) with a background will give a white pixel. So after blitting the mask, we'll have a white ghost in the shape of our sprite floating over the background.
ANDing a white sprite pixel (all ones) with a background pixel will give back the background pixel. ANDing a non-white sprite pixel with the white (all ones) background (the ghost from previous step) will give the sprite pixel. We'll end up with the sprite superimposed on the background.
What remains is to implement the animation. The naive implementation would be to keep re-drawing the image: background, mask and sprite, changing the position of the mask and the sprite in each frame. The problem with this approach is that it results in unacceptable flutter. The trick with good animation is to prepare the whole picture off-line, as a single bitmap, and then blit it to screen in one quick step. This technique is called double buffering — the first buffer being the screen buffer, the second one — our bitmap.
We'll also use Windows timer to time the display of frames.
class WinTimer {
public:
WinTimer(HWND hwnd = 0, int id = -1) : _hwnd (hwnd), _id (id) {}
void Create(HWND hwnd, int id) {
_hwnd = hwnd;
_id = id;
}
void Set(int milliSec) {
::SetTimer(_hwnd, _id, milliSec, 0);
}
void Kill() {
::KillTimer(_hwnd, _id);
}
int GetId() const {
return _id;
}
private:
HWND _hwnd;
int _id;
};
We'll put the timer in our Controller object and initialize it there.
class Controller {
public:
Controller(HWND hwnd, CREATESTRUCT* pCreate);
~Controller();
void Timer(int id);
void Size(int x, int y);
void Paint();
void Command(int cmd);
private:
HWND _hwnd;
WinTimer _timer;
View _view;
};
Controller::Controller(HWND hwnd, CREATESTRUCT * pCreate) : _hwnd (hwnd), _timer (hwnd, 1), _view(pCreate->hInstance) {
_timer.Set (100);
}
Once set, the timer sends our program timer messages and we have to process them.
LRESULT CALLBACK MainWndProc(HWND hwnd, UINT message, WPARAM wParam, LPARAM lParam) {
Controller* pCtrl = WinGetLong<Controller*>(hwnd);
switch (message) {
...
case WM_TIMER:
pCtrl->Timer(wParam);
return 0;
...
}
return ::DefWindowProc(hwnd, message, wParam, lParam);
}
void Controller::Timer(int id) {
_timer.Kill();
_view.Step();
UpdateCanvas canvas(_hwnd);
_view.Update(canvas);
::InvalidateRect(_hwnd, 0, FALSE);
_timer.Set(50);
}
void Controller::Paint() {
PaintCanvas canvas(_hwnd);
_view.Paint(canvas);
}
The Update method of View is the workhorse of our program. It creates the image in the buffer. We then call InvalidateRectangle to force the repaint of our window (the last parameter, FALSE, tells Windows not to clear the previous image — we don't want it to flash white before every frame).
Here's the class View, with the three bitmaps.
class View {
public:
View(HINSTANCE hInst);
void SetSize(int cxNew, int cyNew) {
_cx = cxNew;
_cy = cyNew;
}
void Step() { ++_tick; }
void Update(Canvas& canvas);
void Paint(Canvas& canvas);
private:
int _cx, _cy;
int _tick;
Bitmap _bitmapBuf; // for double buffering
Bitmap _background;
int _widthBkg, _heightBkg;
Bitmap _sprite;
Bitmap _mask;
int _widthSprite, _heightSprite;
};
View::View(HINSTANCE hInst) : _tick (0) {
// Load bitmap from file
_background.Load("picture.bmp");
// Load bitmap from resource
_background.GetSize(_widthBkg, _heightBkg);
// Load bitmaps from resources
_sprite.Load(hInst, IDB_FANNY);
_mask.Load(hInst, IDB_MASK);
_sprite.GetSize(_widthSprite, _heightSprite);
DesktopCanvas canvas;
_bitmapBuf.CreateCompatible(canvas, 1, 1);
_cx = 1;
_cy = 1;
}
And here's the implementation of Update. We create a bitmap canvas in memory, making it compatible with the current display canvas. We blit the background image into it, then blit the mask and the sprite (notice the change of position for each frame). Finally, we transfer the complete bitmap into our buffer (overloaded assignment operator at work!).
void View::Update(Canvas& canvas) {
const double speed = 0.01;
Bitmap bmp(canvas, _cx, _cy);
BitmapCanvas bmpCanvas(canvas, bmp);
RECT rect = { 0, 0, _cx, _cy };
bmpCanvas.WhiteWash(rect);
// Do the off-line drawing
Blitter bltBkg(_background);
bltBkg.BlitTo(bmpCanvas);
int xRange = (_widthBkg - _widthSprite) / 2;
int yRange = (_heightBkg - _heightSprite) / 2;
int x = xRange + static_cast<int>(xRange * sin(speed * _tick));
int y = yRange + static_cast<int>(yRange * cos(4 * speed * _tick));
Blitter bltMask(_mask);
bltMask.SetMode(SRCPAINT);
bltMask.SetDest(x, y);
bltMask.BlitTo(bmpCanvas);
Blitter bltSprite(_sprite);
bltSprite.SetMode(SRCAND);
bltSprite.SetDest(x, y);
bltSprite.BlitTo(bmpCanvas);
// update the buffer
_bitmapBuf = bmp;
}
For completeness, here's the definition of bitmap canvas. You draw directly on this canvas using standard canvas methods, like Line, Text, SetPixel, etc... Here we only blit bitmaps into it.
class BitmapCanvas: public MemCanvas {
public:
BitmapCanvas(HDC hdc, HBITMAP hBitmap) : MemCanvas(hdc) {
// convert bitmap to format compatible with canvas
_hOldBitmap = reinterpret_cast(::SelectObject(_hdc, hBitmap));
}
~BitmapCanvas() {
::SelectObject(_hdc, _hOldBitmap);
}
private:
HBITMAP _hOldBitmap;
};
class MemCanvas: public Canvas {
public:
MemCanvas(HDC hdc) : Canvas(::CreateCompatibleDC(hdc)) {}
~MemCanvas() {
::DeleteDC(_hdc);
}
};
Now, if you want more speed, read about DirectDraw.
(обратно)Примечания
1
Имеется превосходная статья Элен Ульман (Ellen Ullman), которае должна быть рекомендована для чтения каждому, кто все еще чувствует позывы к использованию MFC или OWL. Она доступно интерактивно:
Часть 1
Часть 2
или, в печатном виде, в августовском издании журнала Харпера за 1998 год. Предлагаем Вам несколько цитат:
"… В этом мире программирования, написание моего кода перемещалось с акцента на задачу, в сторону становления набором придатков к архитектуре системы, выстроенной Microsoft."
"… Для чего изучать весь сложный код, который волшебники генерируют для меня, если он и так всегда работает?"
"… Искушение никогда не знать, что лежит в основе той легкости, подобно ослабляющей пассивности телевидения. Успокаивающая пустота, когда театр темен. Как приятно ощущать себя потребителем! (подчеркнуто мной. А.Л. )"
Если вы — энтузиаст объектно-ориентированного программирования, то найдете это цитирование официальных Руководящих принципов MFC для написания расширений библиотеки классов довольно забавным.
Ограничьте использование "Private" в Ваших классах. Это необходимо, чтобы пользователи, были способны использовать разработанные Вами MFC-дружественные классы способами, которые Вы могли бы первоначально не предусмотреть. Храня большую часть методов, элементов данных, и общих операторов публично, Вы допускаете гибкость в их использовании. В MFC, даже функции, объявленные в разделе Реализации класса обычно общие (public) или защищенные (protected).
(обратно)2
Меня задело за живое введение к главе по агрегации в прекрасной (хотя так или иначе тупой) книге "Внутри COM" Дейла Роджерсона ("Inside COM" by Dale Rogerson). Если бы он знал реальную историю, он не был бы столь непреклонен в его защите агрегирования.
(обратно)
Комментарии к книге «Применение Windows API», А. И. Легалов
Всего 0 комментариев