Применение Windows API, Легалов А. И.

Применение Windows API

на обложку

Легалов А. И.

Шрифт:

Рекомендуемая литература: [1]

Brent E. Rector, Joseph M. Newcomer. Win32 Programming. Addison-Wesley

Очень полное и детализированное представление Win32 API. Превосходные ссылки.

И имеется письмо от одного из наших посетителей, Дейва Линенберга (Dave Linenberg).

Я потратил приблизительно 20 минут, просматривая ваш сайт, и действительно наслаждался вашими взглядами на программирование — особенно относительно вздутого характера MFC. Я не мог не поделиться своими наблюдениями.

Имеется превосходная статья Элен Ульман (Ellen Ullman), которае должна быть рекомендована для чтения каждому, кто все еще чувствует позывы к использованию MFC или OWL. Она доступно интерактивно:

Часть 1

Часть 2

или,

в печатном виде, в августовском издании журнала Харпера за 1998 год. Предлагаем Вам несколько цитат:

"… В этом мире программирования, написание моего кода перемещалось с акцента на задачу, в сторону становления набором придатков к архитектуре системы, выстроенной Microsoft."

"… Для чего изучать весь сложный код, который волшебники генерируют для меня, если он и так всегда работает?"

"… Искушение никогда не знать, что лежит в основе той легкости, подобно ослабляющей пассивности телевидения. Успокаивающая пустота, когда театр темен. Как приятно ощущать себя потребителем! (подчеркнуто мной. А.Л. )"

Если вы — энтузиаст объектно-ориентированного программирования, то найдете это цитирование официальных Руководящих принципов MFC для написания расширений библиотеки классов довольно забавным.

Ограничьте использование "Private" в Ваших классах. Это необходимо, чтобы пользователи, были способны использовать разработанные Вами MFC-дружественные классы способами, которые Вы могли бы первоначально не предусмотреть. Храня большую часть методов, элементов данных, и общих операторов публично, Вы допускаете гибкость в их использовании. В MFC, даже функции, объявленные в разделе Реализации класса обычно общие (public) или защищенные (protected).

Я начал писать 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;

};