Рисование перьями и раскрашивание кистями

Перевод А. И. Легалова

Англоязычный оригинал находится на сервере компании 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 {

Перевод А. И. Легалова

Англоязычный оригинал находится на сервере компании 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, которая делает простые вещи, является чрезвычайно сложной.

Перевод А. И. Легалова

Англоязычный оригинал находится на сервере компании 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;

Так, что же мы делаем дальше, когда приложение в наших руках? Как насчет выяснения того, какой документ является в настоящее время активным?

Перевод А. И. Легалова

Англоязычный оригинал находится на сервере компании 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, но во многих случаях это было бы массовым убийством.

Перевод А. И. Легалова

Англоязычный оригинал находится на сервере компании 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) {}

};

]]> http://www.api-windows.info/obolochka-iz-klassov-dlya-com/feed/ 0 http://www.api-windows.info/kratkij-obzor-predstavlennyx-materialov/ http://www.api-windows.info/kratkij-obzor-predstavlennyx-materialov/#comments Tue, 15 Sep 2009 22:58:23 +0000 admin http://www.api-windows.info/kratkij-obzor-predstavlennyx-materialov/ Разработка программ зачастую напоминает священный ритуал, построенный на произнесении ряда обязательных магических заклинаний. Особенно это касается 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;

}

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

Рассказ посвященного лица

Перевод А. И. Легалова

Англоязычный оригинал находится на сервере компании 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, чтобы получить интерфейс.

Перевод А. И. Легалова

Англоязычный оригинал находится на сервере компании 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

Разделительная полоска — полезный элемент, который не входит в состав элементову правления 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

Перевод А. И. Легалова

Англоязычный оригинал находится на сервере компании 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) {

]]> http://www.api-windows.info/ispolzovanie-fabriki-klassov-dlya-okon-dialoga/feed/ 0