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

В COM+ объектные ссылки были ограничены контекстом, и для использования объектных ссылок в глобальных переменных нужна была Global Interface Table (GIT). В CLR областью действия объектных ссылок является AppDomain (эквивалент процесса в CLR), и объектные ссылки можно использовать в глобальных переменных без всякого маршалинга.

В COM+ все объекты прикреплены к контексту, в котором были инициализированы, и по умолчанию маршалятся в другие контексты по ссылке. В результате даже те объекты, которым не нужны сервисы типа транзакций или декларативной безопасности, оказываются замкнуты в конкретном контексте процесса. Чтобы избежать этого, разделяемые объекты часто агрегируют freethreaded-маршалер (FTM), делающий их контекстно-независимыми при вызове изнутри процесса, но маршалящий по значению за границы процесса. Объекты, требующие межпроцессного доступа через копию объекта, вместо proxy обычно реализуют IMarshal для обеспечения семантики маршалинга по значению.

В CLR по умолчанию используется маршалинг по значению между AppDomains и контекстная независимость внутри AppDomains, см. рисунок 1.

Рис. 1. Объект CLR

Это значит, что по умолчанию объект никогда не получит proxy. Вместо этого внутри исходного AppDomain-а доступ к объекту будет осуществляться напрямую, а доступ между AppDomain-ами производится путем копирования объекта. Как показано на рисунке 2, классы, унаследованные от System.MarshalByRefObject, контекстно-независимы внутри AppDomains, но маршалятся по ссылке между AppDomain-ами (грубый говоря, это эквивалент агрегирования FTM в COM+).

Рис. 2. MarshalByRefObject в CLR

Объекты, наследующие функциональность от System.ContextBoundObject, приколоты к контексту, в котором они инициализированы (см. рисунок 3), точно так же, как по умолчанию в COM+.

Рис. 3. ContextBoundObject в CLR

И все это доступно без явного кодирования, просто изменением базового класса.

Итак, наш небольшой анализ показывает, что ориентация Microsoft на COM заменяется ориентацией на CLR. Но остается вопрос, так что же, COM умер? По сути, COM жив и жалеет всех живых. Во-первых, у CLR пока нет собственных средств межмашинного взаимодействия. Такое взаимодействие осуществляется с помощью старого доброго COM. Во-вторых, большое количество современных продуктов целиком и полностью ориентировано на COM и ActiveX.

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

Чтобы решить эту задачу, достаточно вспомнить, что строка состояния – это самое обыкновенное окно, на котором можно создавать дочерние окна. В данном случае нам потребуется создать контрол типа progress bar, задав для него стиль WS_CHILDи строку состояния в качестве родительского окна. Когда индикатор прогресса создан, мы работаем с ним, а затем уничтожаем его.

Следующий фрагмент демонстрирует создание индикатора прогресса на строке состояния.

// Получаем указатель на главное окно.

CMainFrame *pFrame = dynamic_cast(AfxGetMainWnd());

// Находим объект строки состояния.

CStatusBar &sb = pFrame->m_wndStatusBar;

// Определяем прямоугольник, в котором будет размещаться индикатор прогресса.

// В нашем примере он будет занимать всю первую панель строки состояния.

CRect rect;

sb.GetItemRect(0, rect);

// Создаём индикатор прогресса.

CProgressCtrl pc;

pc.Create(WS_CHILD | WS_VISIBLE, rect, &sb, 0);

pc.SetRange(0, 100);

pc.SetPos(0);

pc.SetStep(1);

// Имитируем выполнение длительного процесса.

for(int i=0; i<100; i++) {