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

И последнее. Порой не хочется заглядывать в русифицированные группы новостей из-за обилия "крутого профессионального жаргона" и некоторой агрессивности участников. Грустно за родной язык. Эдакое подражание новорусскому стилю: "пальцы веером" :). Кстати, англоязычные группы гораздо более традиционные и терпимые, хотя вопросы там бывают дилетантские, а профессиональный уровень отвечающих при этом очень высокий. В этом смысле эта рассылка приятно выделяется, и особо хочется отметить регулярные статьи Александра Шаргина.

[…] хотелось бы также выразить благодарность Александру Шаргину, автору статьи на тему "отладчик" – несмотря на мной многолетний опыт узрел там несколько "приятных мелочей", проверить которые самому руки не доходили.

B свою очередь могу внести небольшое дополнение: если в окне отладчика Watch на одной из закладок поместить выражение

=

где variable – имя переменной, а value#1 – одно из возможных ее значений, то поместив на второй закладке Watch такую же строку с иным значением переменной, мы получаем очень удобный вариант быстрой установки/переключения значений интересующей нас переменной. чаще всего таковыми выступают логические переменные (хотя это и не обчзательно). если же у нас целый набор переменных, значения которых в процессе отладки нужно периодически менять, данный способ будет просто незаменим.

Благодарю всех, кто не поленился написать.

Q. 1. Есть окно нестандартной формы (например, круглое). Но рамка, появляющаяся вокруг него при перемещении, – строго прямоугольной формы. Как избавиться от такой рамки вообще? Или, может быть, ее можно сделать тоже произвольной формы (по контуру окна)?

2. Как избавиться от пунктирной рамки на кнопке, имеющей фокус? Для кнопки, сделанной из красивого рисунка, такая рамка выглядит лишней…

Это все на сегодня. Всего вам доброго!

Всем привет!

Сегодня вас ждет сюрприз. Сегодня в рассылке впервые появится статья по COM. Мне приходило очень много просьб по этому поводу, часто выражалось недовольство тем, что слишком много внимания уделяется MFC. Типичный пример – в рубрике "Обратная связь". Так что по зрелом размышлении я решил начать понемногу освещать в рассылке и тему COM. В связи с этим, тем кто никогда раньше с COM не сталкивался (а думаю среди подписчиков такие есть), предлагаю вам прочитать статью, знакомящую вас с этой технологией.

Я написал это руководство для программистов, которые начинают осваивать COM и нуждаются в помощи для понимания основ этой концепции. Статья содержит краткое введение в спецификацию COM, объясняет основные термины и описывает примеры использования существующих компонентов COM. Прошу обратить внимание, что эта статья не научит вас тому, как писать собственные объекты и интерфейсы.

COM (Component Object Model – Объектно-Компонентная Модель) – одно из трехбуквенных сокращений, которые сегодня очень часто используются в Windows (вспомните – API, MFC, OLE, ATL). Множество новых технологий, разрабатывающихся постоянно, базируется на COM. Документация просто пестрит терминами типа COM object (объект COM), interface (интерфейс), server (сервер) , и так далее, но везде почему-то предполагается, что вы уже знакомы с тем, как COM работает и как ее использовать.

Эта статья является вводной для начинающих, она описывает основные используемые механизмы, а также показывает как использовать объекты COM, поставляемые со стороны (особенно, оболочкой Windows). После знакомства со статьей вы сможете использовать COM-объекты, как встроенные в Windows, так и предоставляемые третьими лицами.

Я предполагаю, что вы уже являетесь специалистом в C++. Я частично использую в своих примерах MFC и ATL, и в этих случаях смысл кода будет поясняться, на случай, если вы не знакомы с этими библиотеками. […]

COM – это метод разделения двоичного кода между разными приложениями, написанными на разных языках программирования. Это не совсем то, что обеспечивает C++, а именно повторное использование исходного кода. ATL – хороший пример такого подхода. Отлаженный исходный код может повторно использоваться и нормально работать только в C++. При этом существует возможность коллизий между именами, не говоря уже о неприятностях при наличии множества копий одинакового кода в ваших проектах.

Windows позволяет разделять код между приложениями с помощью библиотек DLL. Я не раскрою большого секрета, если скажу, что все функции Windows содержатся в различных внешних библиотеках – kernel32.dll, user32.dll и т.д., которые доступны любому Windows – приложению, и более того, должны им использоваться. Но DLL расчитаны на использование только посредством интерфейса С или языков, понимающих стандарты вызова языка C. Таким образом, реализация языка программирования является барьером между создаваемым приложением и уже реализованными процедурами, содержащимися внутри DLL-библиотеки.

В MFC был введен новый механизм разделения двоичного кода – библиотеки расширения MFC (MFC extension DLLs). Но это еще более ограниченный метод, т.к. вы можете использовать его только в приложениях, созданных на основе библиотеки MFC.

COM решает все эти проблемы. Делается это посредством введения двоичного стандарта . При этом спецификация COM требует, чтобы двоичные модули (DLL и EXE) компилировались в соответствие со специфической структурой, которая декларируется этим стандартом. Стандарт также в точности определяет, каким образом COM-объекты должны быть организованы в памяти. Вдобавок, двоичная структура не должна быть зависима от особенностей языка программирования (как, например, стандарта описаний имен в C++). Все это нужно для того, чтобы облегчить доступ к модулю приложения, созданного на любом языке программирования. Двоичный стандарт возлагает "бремя" совместимости на "плечи" компилятора, облегчая задачу вам, как создателю компонентов, и другим людям, которые будут пользоваться вашими компонентами.

Структура расположения COM-объектов в памяти очень похожа на модель, которая используется в C++ виртуальными функциями, поэтому многие компоненты COM создаются с использованием языка C++. Однако, здесь важно заметить, что язык, на котором вы пишите, не имеет значения, поскольку результат можно использовать в будущем с любыми языками программирования.

Строго говоря, COM не является спецификацией, привязанной к Win32. Теоретически, можно портировать ваши COM-объекты в Unix или любые другие ОС. Однако, я никогда не видел, чтобы COM применялась где-то за пределами сферы влияния Microsoft.