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

// выставим флажок – пошло перетаскивание

m_bMoveWindow = TRUE;

// все сообщения от мыши - к нашему окну, независимо от координат

// чтобы мышь не улетала с окна при быстром движении

SetCapture();

// сохраняем координаты окна

GetWindowRect(m_RectDlg);

// сохраняем положение мышки внутри окна программы

ClientToScreen(&point);

m_MouseInDlg = point - m_RectDlg.TopLeft();

// меняем курсор, чтоб веселее было тащить

m_hCursor = m_hCursorDown;

::SetCursor(m_hCursor);

// вызываем обработчик по умолчанию

CDialog::OnLButtonDown(nFlags, point);

}

void CDragWinDlg::OnMouseMove(UINT nFlags, CPoint point) {

if (m_bMoveWindow) // надо тащить

{

// преобразуем координаты мыши в экранные

// именно они нужны будут для SetWindowPos()

ClientToScreen(&point);

// двигаем окно в соответствии с новыми координатами мыши

SetWindowPos(&wndTop, point.x - m_MouseInDlg.x, point.y - m_MouseInDlg.y,

m_RectDlg.right - m_RectDlg.left, m_RectDlg.bottom - m_RectDlg.top,

SWP_SHOWWINDOW);

// поскольку обработчик по умолчанию все равно будет использовать

// первоначальные параметры сообщения

// обратное преобразование ScreenToClient(&point);

// можно не вызывать

}

// вызываем обработчик по умолчанию

CDialog::OnMouseMove(nFlags, point);

}

void CDragWinDlg::OnLButtonUp(UINT nFlags, CPoint point) {

// перетаскивание закончилось

m_bMoveWindow = FALSE;

// "отпускаем" мышку

ReleaseCapture();

// меняем курсор на исходный

m_hCursor = m_hCursorUp;

// вызываем обработчик по умолчанию

CDialog::OnLButtonUp(nFlags, point);

}

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

// заменяем курсор на свой

::SetCursor(m_hCursor);

return TRUE; // !!! было return CDialog::OnSetCursor(pWnd, nHitTest, message);

}

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

Реализован для окна About этого же приложения. Заключается в замене обработчика события WM_NCHITTEST, которое информирует об области, над которой в данный момент находится мышка. Обработчик этого сообщения также можно добавить через MFC ClassWizard. Предварительно на закладке ClassInfo для класса CAboutDlg нужно установить для Message Filter значение Window.

Переписываем функцию – обработчик следующим образом:

UINT CAboutDlg::OnNcHitTest(CPoint point) {

UINT ret = CDialog::OnNcHitTest(point);

// если обработчик по умолчанию говорит нам что мышка

// над клиентской областью окна, заменяем возвращаемое

// значение на HTCAPTION – мышка над заголовком окна,

// а за заголовок перемещать окно можно!

if (ret == HTCLIENT) return HTCAPTION;

return ret;

}

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

Если у вас есть вопрос по программированию, вы можете задать его одном из форумов на RSDN.

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

Всем привет!

Я следил за разработкой многих коммерческих программных продуктов от начального проектирования до выпуска рабочей версии, поэтому я скептически отношусь к концепции "компонент – черный ящик", так как следовать ей все труднее и труднее по мере развития и усложнения проекта. Когда я впервые познакомился с механизмом сериализации в библиотеке MFC [ адекватного перевода английского слова "serialization" нет, поэтому здесь я использовал транслитерацию. В статье этот термин применяется для обозначения процесса сохранения/восстановления данных – прим.пер. ], мне стало интересно, насколько этот механизм гибок и производителен для коммерческого применения. В процессе исследования я обнаружил, что, несмотря на некоторые ограничения, механизм сериализации в MFC основан на современной теории объектно-ориентированного проектирования и более того, этот механизм не привязан к какому-то определенному типу и допускает свое дальнейшее развитие.

Использовать MFC-сериализации несложно. Любой класс, производный от CObject , может переопределить функцию Serialize() , принимающую в качестве параметра объект класса CArchive . В этой функции Вы можете добавить свой код для сохранения и восстановления любых данных Вашего класса.

Сериализация данных производится с помощью операторов operator<< и operator>> , совсем как в случае с классом iostream . Разница в том, что CArchive подразумевает только двоичный формат данных. Подобно iostream , в CArchive реализованы операторы для чтения и записи фундаментальных типов данных, таких как long и char . Отсутствие типа данных int упрощает переносимость между 16– и 32-битными платформами. Встроенные операторы также реализуют перестановку байтов для типов, которые это поддерживают. (За дополнительной информацией о совместимости между платформами с прямой и обратной записью байтов [Little-Endian и Big-Endian] обратитесь к книге "Endian-Neutral Software," by James R. Gillig, DDJ, October/November 1994).

Реализация сериализации в MFC выглядела очевидной и неинтересной до того момента, когда мне понадобилось создать несколько типов документов в одном приложении. Я заметил, что когда я открывал в программе файл, MFC корректно создавала объект документа нужного типа и вызывала соответствующую функцию Serialize() . Это происходило, несмотря на то, что я не написал ни строчки кода, чтобы помочь MFC в создании документов. По крайней мере, я так считал:

Чтобы создавать документ или любой другой вид объектов "на лету", MFC должна решить три проблемы:

Проблема 1. По мере необходимости должны создаваться объекты произвольных типов, но оператор new может работать только с явно указанным типом, поэтому для CObject нужно реализовать некое подобие "виртуальных конструкторов".

Проблема 2. Разработчики должны иметь возможность легко "обучать" CObject создавать новые типы классов. В идеале, это должно делаться в определении и/или реализации класса.

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

Как будет продемонстрировано далее, MFC элегантно решает эти проблемы, используя реестр с автоматической регистрацией типов [ здесь и далее под реестром понимается программная структура, а не реестр WIndows – прим.пер. ] и реализуя виртуальные конструкторы на основе зарегистрированных типов. Идентификация типов во время исполнения (RTTI) библиотеки MFC – вот краеугольный камень этой архитектуры.