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

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 пикселей меньше. Причем и немаксимизированные окна не могут "влезть" в эту полосу.

До встречи!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В Visual C++ 6.0 появился ещё один способ подключения DLL, сочетающий в себе почти все достоинства двух рассмотренных ранее методов – отложенная загрузка DLL (delay-load DLL). Отложенная загрузка не требует поддержки со стороны операционной системы (а значит будет работать даже под Windows 95), а реализуется линкером Visual C++ 6.0.

При отложенной загрузке DLL загружается только тогда, когда приложение обращается к одной из содержащихся в ней функций. Это происходит незаметно для программиста (то есть вызывать LoadLibrary/GetProcAddress не требуется). После того как работа с функциями библиотеки завершена, её можно оставить в памяти или выгрузить посредством функции __FUnloadDelayLoadedDLL. Вызов этой функции – единственная модификация кода, которую может потребоваться сделать программисту (по сравнению с неявным подключением DLL). Если требуемая DLL не обнаружена, приложение аварийно завершается, но и здесь ситуацию можно исправить, перехватив исключение с помощью конструкции __try/__except. Как видим, отложенная загрузка DLL – весьма удобное средство для программиста.

Теперь рассмотрим, каким образом описанные способы подключения DLL используются на практике. Для этого будем считать, что нам требуется вызвать функцию X, экспортируемую библиотекой MyLib.dll. Пусть функция X имеет простейший прототип: void X(void);