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

Итак, какие же преимущества мы получим с переходом на .NET? Первое, и главное – платформонезависимость. Хоть на данный момент доступна только одна платформа – Windows 2000, Microsoft обещает, что CLR будет доступна для всех основных платформ. Второе – языконезависимость. .NET программы могут разрабатываться на любых из более чем 40 уже доступных языков. При этом предоставляется очень высокий уровень интеграции. Облегчается задача разработчика, так как CLR берет на себя часть рутинных задач. А также большая и удобная в использовании библиотека объектов.

А недостатки? О недостатках пока говорить рано. Как говориться «знал бы, где упал».

Возможно, мне так и не удалось ответить на вопрос – что же такое .NET? Грандиозный успех, или грандиозный провал – время покажет. Ясно одно, .NET – это самый значительный шаг Microsoft за последнее время. Важнее даже чем Windows 2000 и X-Box. Грядет революция, и рано или поздно нам придется с этим считаться. Мое мнение – лучше рано, чем поздно.

Несколько полезных ссылок:

Тут можно скачать NGWS SDK

Сайт с кучей полезных ресурсов по .NET

Также сайт посвященный C#

И разумеется первоисточник

Здраствуйте Алекс. Спасибо за Вашу рассылку, я с удовольствием читаю ее с первого выпуска. Прочитав выпуск №19 решил обратить Ваше внимание на, как мне кажется, более новый способ создания паналей инструментов различного внешнего вида (а'ля Internet Explorer и т.п.) Для этих целей в MFC появился класс CReBar позволяющий размещать на панели инструментов не только кнопки но и практически любые объекты произошедшие от CWnd и имеющие стиль WS_CHILD. Как правило в качестве таких объектов выступают экземпляры классов CToolBar и CDialogBar. Более подробно об этом можно прочитать в MSDN.

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

Что касается постановки вопроса: "сделать тулбар а'ля WinZip – большие иконки, с подписями…", так это можно сделать в редакторе ресурсов просто "растянув" изображение до нужного размера и написав все, что нужно (естественно, надписи будут статическими). Что же касается размещения элементов управления на панели инструментов за счет "расширения" сепараторов, то это действительно интересно и, главное, более гибко и удобно, чем создание DialogBar.

Вряд ли статический (т.е. являющийся частью изображения ) текст кого-либо устроит. Это, конечно, можно сделать, но вообще-то это не принято.

Q. Как создать такое окно (или это диалогбар?) как Workspace в Visual Studio? То есть, я представляю, что если это диалогбар со списком, то какие стили применить в Create, чтобы его можно было "переносить" и изменять размер?

На этот вопрос было получено удивительно мало ответов. Неужели этим почти никто не интересовался?

A1 Среди заголовочных файлов MFC есть заголовочный файл afxpriv.h, в котором объявлено несколько недокументированных классов, в том числе например класс CDockBar. По-моему именно он обеспечивает создание окон в стиле Visual Studio.

Я хотел бы предостеречь читателей: использование недокументированных классов чревато неприятностями. В том же MSDN написано, что члены и методы класса CDockBar, скорее всего, претерпят сильные изменения в будущем.

A2 Во время оно я боролся с этим вопросом. Вот краткие выводы: DialogBar – ДЕРЬМО. Проще сходить на сайт http://www.datamekanix.com и слить оттуда компонент CSizingControlBar написанный Crisite Posea. Он тоже не предел совершенства, но работает почти так же как и Workspace.

Хочу добавить (как еще один вариант), что я кажется видел класс с такой же функциональностью в Ultimate Toolbox от Dundas Software.

Q. У меня есть приложение MFC на базе диалога. Я решил организовать переключение некоторых режимов через главное меню, т.е. в меню присутствуют названия режимов и активный в данный момент режим помечен точкой. Для этого я создал обработчики ON_UPDATE_COMMAND_UI для соответствующих пунктов меню и в них вызов СCmdUI::SetRadio(). Например:

void CHeatDlg::OnUpdateSolve(CCmdUI* pCmdUI) {

 if (mode == 1) pCmdUI->SetRadio(TRUE);

 else pCmdUI->SetRadio(FALSE);

}

Это не сработало. Похоже, что сообщения ON_UPDATE_COMMAND_UI просто не посылаются. До этого я использовал такой же подход в приложениях SDI и MDI и все работало. Есть какие-нибудь мысли по этому поводу?

Успехов!

Программирование на Visual C++

Выпуск №21 от 29 октября 2000 г.

Все настоящие программисты делятся на три категории: на тех, кто пишет программы, завершающиеся по нажатию F10, Alt-F4 и Alt-X. Все  остальные  принципы  деления надуманны.

Рад снова приветствовать вас!

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

Q. У меня есть приложение MFC на базе диалога. Я решил организовать переключение некоторых режимов через главное меню, т.е. в меню присутствуют названия режимов и активный в данный момент режим помечен точкой. Для этого я создал обработчики ON_UPDATE_COMMAND_UI для соответствующих пунктов меню и в них вызов СCmdUI::SetRadio(). Например:

void CHeatDlg::OnUpdateSolve(CCmdUI* pCmdUI) {

 if (mode == 1) pCmdUI->SetRadio(TRUE);

 else pCmdUI->SetRadio(FALSE);

}

Это не сработало. Похоже, что сообщения ON_UPDATE_COMMAND_UI просто не посылаются. До этого я использовал такой же подход в приложениях SDI и MDI и все работало. Есть какие-нибудь мысли по этому поводу?

A1 Решение проблемы обработчика ON_UPDATE_COMMAND_UI частично кроется в одном из предыдущих выпусков — №18. Ведь этот обработчик вызывается Framework'ом MFC из OnIdle объекта приложения, а в dialog-based программах OnIdle не работает. Тут можно посоветовать использовать в качестве главного окна аппликации скрытое "фиктивное" окно и подсунуть его в качестве родителя диалога.

A2 Дело в том, что вся логика генерации user-interface update command message для меню (создание объекта CCmdUI и т.д.) реализована в CFrameWnd::OnInitMenuPopup. Соответственно в dialog-based приложениях вызов этой функции отсутствует. Очевидно, предполагалось что в диалогах меню не обязательно. Поэтому можно предложить два варианта. Общим в них является необходимость создания обработчика OnInitMenuPopup для вашего диалога. Первый вариант подойдёт, если вы уже повсеместно расставили обработчики ON_UPDATE_COMMAND_UI, и не хотите ничего переделывать: Вы просто копируте тело функции CFrameWnd::OnInitMenuPopup в созданную вами функцию (благо, что исходники доступны), чистите всё лишнее (разобраться достаточно легко) и созданные вами обработчики OnUpdateXXX начинают вызываться Второй вариант предполагает, что вы, что называется "ручками", изменяете состояния пунктов меню прямо в созданной вами выше функции OnInitMenuPopup, используя передаваемый ей как параметр CMenu*. Этот вариант вполне приемлем, если меню не очень большое и структура его не очень разветвлённая. Для некоторых этот вариант также покажется более привлекательным по той причине, что вы всё делаете сами, а не копируете фрагменты чужого кода.

A3 Когда Windows собирается отобразить всплывающее меню, она посылает сообщение WM_INITMENUPOPUP, чтобы программа могла на лету кое-что поменять: отключить некоторые пункты, расставить галочки и т. п. Поэтому базовый способ модификации всплывающих меню состоит в перехвате этого сообщения с последующим использованием функций EnableMenuItem, CheckMenuItem и т.п.

MFC предлагает альтернативный подход. В классе CFrameWnd есть готовый обработчик WM_INITMENUPOPUP, который инициализирует структуру CCmdUI для каждого пункта меню, после чего отправляет сообщение CN_UPDATE_COMMAND_UI, определённое в MFC, сперва классу представления, затем классу документа, затем классу главного окна и, наконец, классу приложения. Каждый из этих классов может внести свою лепту в инициализацию всплывающего меню. Можно инициировать этот процесс, вообще ничего не зная о CN_UPDATE_COMMAND_UI: достаточно вызвать CCmdUI::DoUpdate, и сообщеине дойдёт до написанных программистом обработчиков CN_UPDATE_COMMAND_UI.

Теперь внимание: класс диалога (CDialog) не имеет предопределённого обработчика WM_INITMENUPOPUP. Поэтому сообщения CN_UPDATE_COMMAND_UI никто не посылает, и обработчики ON_UPDATE_COMMAND_UI не вызываются. Необходимо вручную написать обработчик OnInitMenuPopup, воспроизведя в нём часть функциональности класса CFrameWnd. В простейшем случае он может выглядеть так: