Читаем Программирование на Visual C++. Архив рассылки полностью

Да, это может быть полезно, особенно для тех, кто сталкивался (или кому еще только предстоит столкнуться) с разработкой сложных MDI-приложений – они знают, как трудно добиться правильной совместной работы всех дочерних окон. 

ВОПРОС-ОТВЕТ

Q. Нужно изменить шрифт у одного элемента типа CStatic. Делаю это функцией SetFont(CFont font). Фонт меняется у элемента … и у всего окна :(. Включая кнопки и другие элементы типа static. Мне его надо было толстым сделать, так у меня такие кнопки стали — загляденье:)) Кто-нибудь знает в чем дело и как решить ?

LiMar

A. Присланные ответы на этот вопрос сводились к двум следующим: 

1) сделать класс-наследник от CStatic и перекрыть функцию прорисовки – OnPaint;

2) вызывать метод SetFont именно объекта CStatic (или указателя на этот контрол), а не всего диалога.

Порекомендовавшие первый способ явно забыли правило "бритвы" Оккама: не множить сущностей без нужды. (Кстати, нам, программистам, это правило особенно полезно.) Если для того, чтобы поменять шрифт, нужно создавать новый класс, ну уж извините… Этим способом, конечно, можно пользоваться, но я думаю, только в тех случаях, когда без этого не обойтись.

Итак, второй ответ был больше всего похож на искомую истину. Но "похож" – это еще не значит "есть", так что я решил проверить. Сделал простое SDI-приложение, и попробовал в окне About у одной из надписей поменять шрифт. 

Как же я был рад, когда он в самом деле изменился!!!

…Правда, на совершенно не тот, который я хотел. Да и размерчик прежний остался… Это было весело – в любом случае он ставил шрифт System, хотя (у меня много шрифтов!) я прописывал разные. Никакого результата. Способ No.2 у меня не работал. Либо он был неправильный, либо, как впоследствии оказалось, правильный не до конца.

Через некоторое время мне это надоело, и я решил, что раз уж не оказалось пророков среди читателей, пророком придется стать самому (это метафора;)

Самое обидное то, что ответ даже не пришлось искать ! Он лежал на самом видном месте в MSDN. Я ввел "SetFont" в строке поиска и мгновенно обнаружил интереснейшую статью с говорящим само за себя названием – "Correct Use of the SetFont Function in MFC". 

Суть статьи сводилась к следующему:

Обычно в SetFont передают указатель на шрифт – объект CFont. Так вот, обязательно нужно проследить , чтобы этот объект не уничтожился раньше, чем тот контрол, для которого он создается!

Итак, как было у меня раньше (или "способ №2"):

BOOL CAboutDlg::OnInitDialog {

 CDialog::OnInitDialog;

 CFont times;

 times.CreatePointFont(100, "Times New Roman");

 m_Static.SetFont(×);

 times.DeleteObject;

 return TRUE; 

}

m_Static — переменная, представляющая соответствующий Static-контрол. Вместо нее можно воспользоваться указателем, возвращаемым ф-цией GetDlgItem.  Как вы видите, объект CFont уничтожается сразу же после вызова SetFont.

А вот как надо было сделать:

class CAboutDlg : public CDialog {

 …

private:

 CStatic m_Static;

 CFont m_fntTahoma; // добавляем шрифт в диалог

}

BOOL CAboutDlg::OnInitDialog {

 CDialog::OnInitDialog;

 m_fntTahoma.CreatePointFont(100, "Tahoma");

 m_Static.SetFont(&m_fntTahoma);

 return TRUE; 

}

BOOL CAboutDlg::DestroyWindow {

 m_fntTahoma.DeleteObject;

 return CDialog::DestroyWindow;

}

Здесь все работает как надо. Вскоре, когда надоела Tahoma,  я уже наслаждался отлично выглядевшей готической надписью. (Кстати, тут возникает еще вопрос – получается, чтобы нужный шрифт был всегда доступен, нужно распространять его вместе с приложением? Конечно, это не относится к стандартным Windows-шрифтам, типа Arial, Times, Tahoma или Courier. Лучше все-таки обходиться ими, когда возможно).

Тех, кто хочет получить больший контроль над шрифтом – сделать его жирным, курсивом и т.д., отправляю прямиком к той же статье, да еще к функции CFont::CreateFontIndirect.

Я прошу прощения, что, возможно, слишком подробно расписал ответ на этот вопрос (хотя не исключаю, что кому-то это было интересно прочитать). Я преследовал еще одну цель – сказать всем: "Люди, учитесь пользоваться MSDN! На многие ваши вопросы там уже отвечено!"

Ответ на этот вопрос прислали: Николай Чепкий , Igor Sorokin, Alexander Dymerets, Pavel Vasev.

В ПОИСКАХ ИСТИНЫ
Перейти на страницу:

Похожие книги

Основы программирования в Linux
Основы программирования в Linux

В четвертом издании популярного руководства даны основы программирования в операционной системе Linux. Рассмотрены: использование библиотек C/C++ и стан­дартных средств разработки, организация системных вызовов, файловый ввод/вывод, взаимодействие процессов, программирование средствами командной оболочки, создание графических пользовательских интерфейсов с помощью инструментальных средств GTK+ или Qt, применение сокетов и др. Описана компиляция программ, их компоновка c библиотеками и работа с терминальным вводом/выводом. Даны приемы написания приложений в средах GNOME® и KDE®, хранения данных с использованием СУБД MySQL® и отладки программ. Книга хорошо структурирована, что делает обучение легким и быстрым. Для начинающих Linux-программистов

Нейл Мэтью , Ричард Стоунс , Татьяна Коротяева

ОС и Сети / Программирование / Книги по IT
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT
Программист-прагматик. Путь от подмастерья к мастеру
Программист-прагматик. Путь от подмастерья к мастеру

Находясь на переднем крае программирования, книга "Программист-прагматик. Путь от подмастерья к мастеру" абстрагируется от всевозрастающей специализации и технических тонкостей разработки программ на современном уровне, чтобы исследовать суть процесса – требования к работоспособной и поддерживаемой программе, приводящей пользователей в восторг. Книга охватывает различные темы – от личной ответственности и карьерного роста до архитектурных методик, придающих программам гибкость и простоту в адаптации и повторном использовании.Прочитав эту книгу, вы научитесь:Бороться с недостатками программного обеспечения;Избегать ловушек, связанных с дублированием знания;Создавать гибкие, динамичные и адаптируемые программы;Избегать программирования в расчете на совпадение;Защищать вашу программу при помощи контрактов, утверждений и исключений;Собирать реальные требования;Осуществлять безжалостное и эффективное тестирование;Приводить в восторг ваших пользователей;Формировать команды из программистов-прагматиков и с помощью автоматизации делать ваши разработки более точными.

А. Алексашин , Дэвид Томас , Эндрю Хант

Программирование / Книги по IT