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

public class MyHookEx {

 public void AnyNameIWant() {

  System.Console.WriteLine("Hook вызван!");

 }

}

Обратите внимание – MyHookEx не имеет явных ссылок на тип-делегат Hook. Вместо этого у него есть метод с сигнатурой, соответствующей сигнатуре Hook, что делает этот тип кандидатом на регистрацию в качестве обработчика для MyClassEx. Чтобы зарегистрировать обработчик, вам нужно только создать экземпляр нового делегата, основанного на типе-делегате Hook:

MyClassEx mc = new MyClassEx();

mc.RegisterHook(new Hook(MyHookEx.AnyNameIWant));

mc.f(); // вызывает MyHookEx.AnyNameIWant()

Обратите внимание на несколько необычный синтаксис инициализации делегата. Компилятор C# скрыто генерирует код инициализации нового объекта-делегата с маркером метаданных для означенного метода.

На таком же принципе построена система обработки событий. Но регистрация обработчика подразумевает возможность подключения нескольких обработчиков событий для одного источника. В C# такое подключение делается с помощью оператора «+=».

Полная поддержка аспектно-ориентированного программирования. MTS и COM+ представили массам аспектно– ориентированное программирование, позволив разработчикам переместить независимые от логики приложения аспекты из исходного кода в декларативные атрибуты. MTS и COM+ ввели также понятие как контекст для управления областью исполнения объекта. Контексты подразделяют процессы и содержат упорядоченную коллекцию именованных контекстных свойств, контролируемых атрибутами класса наподобие Synchronization, ThreadingModel, Transaction и т.д. CLR продвигает эту концепцию дальше и значительно расчищает реализацию.

В MTS и COM+ наборы атрибутов класса и свойств контекста были фиксированными. В CLR можно определить новый атрибут класса, вносящий новые свойства в контекст объекта. Это позволяет стороннему разработчику определять сервисы, поведение которых будет задаваться через атрибуты, контекстные свойства и перехват.

В 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<CMainFrame*>(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++) {

 Sleep(30);

 pc.StepIt();

}

// Уничтожаем индикатор прогресса.

pc.DestroyWindow();

ПРИМЕЧАНИЕ

В этом фрагменте используется приведение типов с помощью dynamic_cast. Этот оператор в свою очередь использует механизм RTTI (информацию о типах на этапе выполнения). Поэтому необходимо включить поддержку RTTI, чтобы приведённый фрагмент мог работать в вашей программе. Поддержка RTTI включается, если задать компилятору ключ /GR. В настройках проекта (Project->Settings) ему соответствует настройка Enable Run-Time Type Information (RTTI) (вкладка C/C++ , категория C++ Language).

Это все на сегодня. До встречи в новом году! 

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

Выпуск №59 от 13 января 2001 г.

Здравствуйте, уважаемые подписчики!

Ну, надеюсь все хорошо отдохнули за праздники, и готовы с новыми силами читать рассылку! ;-)

СТАТЬЯ

Регулярные выражения

Автор: Михаил Купаев

Источник: <Технология Клиент-Сервер>

Пример RegExpTest.zip – 2 KB

Пример RegexNetTest.zip – 11 KB 

Словосочетание «регулярные выражения»,  прямой перевод английского «regular expression», звучит довольно неуклюже. Однако оно уже настолько прижилось, что попало в словари, поэтому придется использовать именно его – за неимением лучшего.

Регулярные выражения – это один из способов поиска подстрок (соответствий) в строках. Осуществляется это с помощью просмотра строки в поисках некоторого шаблона. Общеизвестным примером могут быть символы и <, *, > и |, используемые в командной строке DOS. Первый из них заменяет ноль или более произвольных символов, второй же – один произвольный символ. Так, использование шаблона поиска типа "text?.*" найдет файлы textf.txt, text1.asp и другие аналогичные, но не найдет text.txt или text.htm. Если в DOS использование регулярных выражений было крайне ограничено, то в других местах (то есть операционных системах и языках программирования) они почти достигли уровня высокого искусства. потому, что предметы высокого искусства практически невозможно употреблять в повседневной жизни. Более сложным примером применения регулярных выражений может быть удаление мусора, внесенного Microsoft Word при сохранении документа в формате HTML. Разработчики Word умудрились все сделать по-своему, в результате чего HTML-документ порой становится больше исходного DOC-файла за счет огромного количества понятных только IE5 тегов, вычистить которые вручную нет никакой возможности.