• Главная
• В избранное
• Наш E-MAIL
• Добавить материал
• Нашёл ошибку
• Вниз

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

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

А вот, что случается с объектными данными, чьим фактическим классом является EditorData.

Объект класса EditCtrl, созданный в методе MakeController класса ControllerFactory<EditorCtrl, EditorData> возвращается из него как DlgController* и сохраняется в этой форме как статический член данных ModalDialog.

Если Вы имеете проблемы после моего объяснения, не отчаивайтесь. Объектно ориентированные методы, которые я только описал, трудны, но необходимы. Они названы образцами проектирования. Я настоятельно рекомендую читать книгу: Gamma, Helm, Johnson and Vlissides — Design Patterns, Elements of Reusable Object-Oriented Software или посмотреть Patterns Home Page (домашнюю страницу образцов). Там описано много творческих способов использования полиморфизма, наследования и шаблонизации, чтобы делать программное обеспечение более пригодным для многократного использования.

Далее: Более подробный разговор о холсте.