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

void CMyDlg::OnInitMenuPopup(CMenu* pPopupMenu, UINT nIndex, BOOL bSysMenu) {

 if (!bSysMenu) {

  CCmdUI state;

  state.m_pMenu = pPopupMenu;

  state.m_nIndexMax = pPopupMenu->GetMenuItemCount();

  for (state.m_nIndex = 0; state.m_nIndex < state.m_nIndexMax; state.m_nIndex++) {

   state.m_nID = pPopupMenu->GetMenuItemID(state.m_nIndex);

   state.m_pSubMenu = NULL;

   state.DoUpdate(this, state.m_nID < 0xF000);

  }

 }

}

В случае когда всплывающее меню имеет подменю обработчик будет более сложным. За примером такого обработчика можно обратиться к исходным текстам программы DLGCBR32, которые находятся в MSDN.

A4 Это и не должно работать, так как диалоговое окно не посылает сообщение на обновление меню, следует заметить, что такие "казусы" происходят с диалогами достаточно часто, к примеру Диалог не посылает сообщение о командах меню своим детям, как это делают приложениях SDI и MDI, все дело в том что в MFC диалоги работают по другим правилам, чем обычные окна, так как в MFC главный упор сделан на архитектуру Document-View, а диалоги "искуственное" добавление. Я решал подобную проблему, самостоятельно посылать сообщение Меню на обновление, так:

BEGIN_MESSAGE_MAP(CMyDlg, CDialog)

 ...

 ON_MESSAGE(WM_KICKIDLE, OnKickIdle)

 ...

END_MESSAGE_MAP()

LRESULT CMyDlg::OnKickIdle(WPARAM w, LPARAM l) {

 Sleep(50);

 // Самостоятельно обновлять меню ...

 UpdateMenu(this , GetMenu());

 return TRUE;

}

// А это моя функция ...

void UpdateMenu(CWnd *pWnd, CMenu *pMenu) {

 CCmdUI cmdUI;

 cmdUI.m_pMenu = pMenu;

 cmdUI.m_nIndexMax = pMenu->GetMenuItemCount();

 for (cmdUI.m_nIndex = 0; cmdUI.m_nIndex < cmdUI.m_nIndexMax; ++cmdUI.m_nIndex) {

  CMenu* pSubMenu = pMenu->GetSubMenu(cmdUI.m_nIndex);

  if (pSubMenu == NULL) {

   cmdUI.m_nID = pMenu->GetMenuItemID(cmdUI.m_nIndex);

   cmdUI.DoUpdate(pWnd, FALSE);

  } else UpdateMenu(pWnd, pSubMenu);

 }

} /// и все.

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

Авторам всех ответов, и опубликованных, и не опубликованных, большое спасибо!

Из входящей почты:

День добрый,

По всем вопросам, ответы на которые публикуются в рассылке у меня сложилось мнение, которое вероятно ошибочно, что никто их ее читателей не знает такого сайта как www.codeguru.com, который содержит гараздо более полную и полезную информацию и ответы на вопросы, чем те, что публикуются…

Ну, в чем-то возможно и справедливо. Но далеко не во всем. Некоторые не могут свободно работать с MSDN или CodeGuru из-за недостаточного знания английского, или жалко времени в интернет, а кому-то просто лень…

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

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

Полегче со словом "не могут", уважаемый.

http://codeproject.com/docking/tearoffrebars.asp

Вот яркий пример того чего не может быть.

Тот контрол, на который сослался автор письма, в самом деле, благодаря усилиям программиста, который его создал, может "плавать". Но полной функциональности тулбаров он все равно не достигает – стыковаться он по-прежнему может только с одной границей, не возвращается на свое место по double-click и т.д. И потом, я говорил о CReBar. Вряд ли этот модифицированный класс можно так назвать.

Так что полегче со словом "полегче", уважаемый Павел…

Еще письма:

Есть комментарий к ответам на вопрос из номера 18 (по поводу списка компьютеров в сети), точнее к первому из них.

-------------------------

В документации Микрософт сказано, что Функции Netxxx устарели и следует пользоваться функциями WNetxxx. Во-вторых, с использованием функций Netxxx есть проблемы из-за того, что для Windows NT и Windows 9x используются различные библиотеки (в первом случае netapi32.lib, во втором svrapi.lib). Также вызовы функций в этих библиотеках различаются параметрами (кстати, в MSDN приводится версия для WinNT, а для Win9x придется читать заголовочный файл svrapi.h). Кстати, для Windows 9x следует использовать именно svrapi.h, а не lmxxx.h.

Тут вспомнилось – к Вашему выпуску о читабельности кода:

"Отсутствие коментариев в программе – веский повод для увольнения программиста" – Дональд Кнут

Q. Все, наверное, знают программы, называемые Viewbar, которые показывают рекламные баннеры. Но вот как они ограничивают часть экрана, не позволяя другим окнам находиться поверх них? Например, если разрешение экрана 800×600, как они выделяют полосу сверху, в которой находятся, т.ч. программы, развернутые на полный экран, имеют высоту где-то на 60 пикселей меньше. Причем и немаксимизированные окна не могут "влезть" в эту полосу.

До встречи!

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

Выпуск №22 от 5 ноября 2000 г.

Здравствуйте!

Мне пришла пара писем от подписчиков, где они выразили некоторую неудовлетворенность существующей  в рассылке системой поощрения авторов лучших ответов и статей (для вновьподписавшихся: см. в архиве выпуск No. 18) Они пишут, что "прежде всего надо публиковать самые интересные вопросы."

Я лично с этим целиком и полностью согласен, и всегда фактически стараюсь так и делать, хотя понятие "интересный вопрос" достаточно размыто и каждый понимает его по-своему. Для некоторых, например, интересный вопрос – "Как связать контролы на диалоге с переменными класса?", а для других – …мм, ну, совершенно другое ;)

С другой стороны, у меня нет абсолютно никакой альтернативы для поощрения авторов, кроме как морального поощрения. Думаю мало кого увлечет обещание типа "Вы увидите свое имя в рассылке, оно навечно войдет в скрижали ее истории", и т.д. и т.п.

Так вот, к чему я клоню. РАССЫЛКЕ НУЖЕН ПОСТОЯННЫЙ СПОНСОР И РЕКЛАМОДАТЕЛЬ. Тогда станет возможно назначить материальное вознаграждение за лучший ответ и лучший материал (а, возможно, и лучший вопрос тоже!)

Это будет выгодно прежде всего самим читателям, поскольку качество и интересность вопросов, ответов и статей значительно повысится. Да и авторам, я думаю тоже будет неплохо получить, скажем, энное количество $ потратив несколько минут на ответ.

И тогда, действительно, будет возможно публиковать только САМЫЕ ИНТЕРЕСНЫЕ вопросы.

Так что дело только за вами, уважаемые рекламодатели! Хочу вам напомнить, что рассылку получают около 8500 интересующихся программированием человек.

К читателям: может, у вас есть какие-нибудь идеи или просто интересные мысли по этому поводу? Не стесняйтесь – пишите мне.

Сегодня я предлагаю вам заметку, написанную уже воистину постоянным автором нашей рассылки – Александром Шаргиным.

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

При неявном подключении (implicit linking) линкеру передаётся имя библиотеки импорта (с расширением lib), содержащей список функций DLL, которые могут вызвать приложения. Обнаружив, что программа обращается к одной из этих функций, линкер добавляет информацию о содержащей её DLL в целевой exe-файл. Позже, когда этот exe-файл будет запущен, загрузчик попытается спроектировать необходимую DLL на адресное пространство процесса; в случае неудачи весь процесс будет немедленно завершён.

При явном подключении (explicit linking) приложение вызывает функцию LoadLibrary(Ex), чтобы загрузить DLL, затем использует функцию GetProcAddress, чтобы получить указатели на требуемые функции, а по окончании работы с этими функциями вызывает FreeLibrary, чтобы выгрузить библиотеку и освободить занимаемые ею ресурсы.

Каждый из способов имеет свои достоинства и недостатки. В случае неявного подключения все библиотеки, используемые приложением, загружаются в момент его запуска и остаются в памяти до его завершения (даже если другие запущенные приложения их не используют). Это может привести к нерациональному расходу памяти, а также заметно увеличить время загрузки приложения, если оно использует очень много различных библиотек. Кроме того, если хотя бы одна из неявно подключаемых библиотек отсутствует, работа приложения будет немедленно завершена. Явный метод лишён этих недостатков, но делает программирование более неудобным, поскольку требуется следить за своевременными вызовами LoadLibrary(Ex) и соответствующими им вызовами FreeLibrary, а также получать адрес каждой функции через вызов GetProcAddress.