Здравствуйте, AndrewVK, Вы писали:

AVK>Не надо обобщать. У нас в группе школьные отличники оставались отличниками максимум до 3 семестра. Дальше отличниками становились как раз те, кто действительно что то приобретал от обучения. Я, к примеру, в первом семестре ходил на пересдачу по одному предмету, а по остальным были тройки. Начиная же с 4 семестра я всегда сдавал 100% экзаменов на пятерки, даже если предметы были непрофильными. Вот так вот.

Интересно у вас там.

1. Что случилось с 4-го семестра? Все предметы стали интересными без разбору?

2. Писал все лекции, посещал все практики и др.?

3. Сколько было отличников и всего людей в группе?

4. ВУЗ, факультет, кафедра?

Здравствуйте, Cyberax, Вы писали:

C>Ну давайте смотреть.

Давай.

C>Начнем с объектов передачи данных:
C>1. IDataObject с поддержкой сериализации, прозрачного создания проксей,
C>различными типами форматов.

На фиг не упал. Сериализация и так есть. Причем логично было бы на сегодня текстовые и векторые форматы сериализовать в ХМЛ.

C>2. IOleObject — управление размерами, отображением, моникерами для
C>linking'а. Так же, управление состоянием и глаголы.

Бред фантазии неопытных разработчиков из МС. Дизайн OLE содержит тонны таких уродцев.

C>3. IOLEClientSite/IOleContainer — взаимодействие с объектом.
C>4. IOleControl — управление акселераторами.
C>5. IDropSource/IDropTarget — управление OLE D&D.

Аналоги уже есть в подсистеме контролов.

C>5. IDropSource/IDropTarget — управление OLE D&D.

Есть обертка над ОЛЕ, но само ОЛЕ-решине довольно кривое. Я бы переписал на менеджед коде.

C>7. IOleInPlaceUIWindow — согласование места для тулбаров.

Тоже бы сделал более простую реализацию.

C>8. IOleUndoManager — совместный Undo/Redo.

Аналогично. К тому же в студии уже есть подобные интерфейсы, но более универсальные (управление транзакциями).

C>9. IViewObject — отображение содержимого документа без создания окон.

Опять же задача пустяковая.

C>10. И т.п.

И т.п. там конечно много. Но ты уж меня извени, я знаю об этой кухни не по наслышке. За дизайн ОЛЕ и ОЛЕ-контролов нужно отрезать разные части тела. Это полнейший бедлам и бессмыслица. Изучение этого дерьма становится сущим адом. Особненно если учесть качесво документации.
Все тоже самое можно сделать куда проще.

C>Из этого всего контролы в .NET обеспечивают примерно функциональность
C>IOleControl и часть IOleObject. Это совсем небольшая часть от всей
C>функциональности OLE.

Как видишь, большую часть они покрывают. А то чего нет без проблем пишется на дотнете в чистом виде.

Рельно для создания аналога ОЛЕ на дотнете нужно не так много. И сделать это не сложно. Так что проблема только в одном. В совместимости с прошлыми версиями.

Главное, что сама основа у дотнета куда более подходит для этой задачи. А интерфейсы ОЛЕ нужно выбросить на помойку хотя бы из-за их противоречивости и запутанности.

Думаю, что рано или поздно будет создан некий управляемый ОЛЕ3. Не удивлюсь если на базе Авалона.

C>Причем сильно в этой системе ничего изменить не получится — просто
C>интерфейсы из COMовских станут .NETовскими.

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

Я уже не раз ворчал на WinAPI. По сравнению с FCL из дотнета — это чудовищьное уродство. ОЛЕ здесь ничем не отличается. Его давно пора переписывать. Настало время чистых решений.

Здравствуйте, Кодёнок, Вы писали:
Кё>1. Что случилось с 4-го семестра? Все предметы стали интересными без разбору?
А как раз примерно с 4-5 семестра студент наконец понимает, что именно от него требуется на сессии, и подбирает верный баланс между пьянкой и учебой. Я на все пятерки не вышел, но головняков и неожиданных троек на третьем-четвертом курсах уже не было. Даже скучновато стало — интрига ушла, сессия перестала быть пугающим водоворотом, стало понятно, что собственно зубрежка — вещь бесполезная в принципе, и главное — не донести максимум знаний до экзамена, а максимально эффективно подать донесенные.

VladD2 wrote:
> C>Начнем с объектов передачи данных:
> C>1. IDataObject с поддержкой сериализации, прозрачного создания проксей,
> C>различными типами форматов.
> На фиг не упал. Сериализация и так есть. Причем логично было бы на
> сегодня текстовые и векторые форматы сериализовать в ХМЛ.
Сериализация — это мелочь (IStreamPersist/IStoragePersist я тут даже не
упомянул). Нужно именно согласование форматов.

Я уже приводил пример — картинка из Visio вставляется в Word как
OLE-объект, а в MSPaint как растровая картинка.

> C>2. IOleObject — управление размерами, отображением, моникерами для
> C>linking'а. Так же, управление состоянием и глаголы.
> Бред фантазии неопытных разработчиков из МС. Дизайн OLE содержит тонны
> таких уродцев.
Придумай лучше. Глаголы, положим, можно заменить на reflection+атрибуты.
Но что делать с моникерами и управлением extent'ами?

> C>3. IOLEClientSite/IOleContainer — взаимодействие с объектом.
> C>4. IOleControl — управление акселераторами.
> C>5. IDropSource/IDropTarget — управление OLE D&D.
> Аналоги уже есть в подсистеме контролов.
Только для IOleControl, для сайта и контейнера — далеко не полная
функциональность.

> C>5. IDropSource/IDropTarget — управление OLE D&D.
> Есть обертка над ОЛЕ, но само ОЛЕ-решине довольно кривое. Я бы переписал
> на менеджед коде.
Чтобы получить кривое решение на managed-коде?

Я работал с D&D на Java (managed-код!) — разницы нет никакой по
сравнению с COM. Просто интерфейсы становятся не COM-интерфейсами, а
просто Java-интерфейсами.

> C>7. IOleInPlaceUIWindow — согласование места для тулбаров.
> Тоже бы сделал более простую реализацию.
Чего там упрощать? Там 6 методов для согласования границ объекта.

> C>8. IOleUndoManager — совместный Undo/Redo.
> Аналогично. К тому же в студии уже есть подобные интерфейсы, но более
> универсальные (управление транзакциями).
Так кто же спорит, что оно по-отдельности все просто?

> C>9. IViewObject — отображение содержимого документа без создания окон.
> Опять же задача пустяковая.
Ага. Оно все пустяковое по-отдельности.

> И т.п. там конечно много. Но ты уж меня извени, я знаю об этой кухни не
> по наслышке. За дизайн ОЛЕ и ОЛЕ-контролов нужно отрезать разные части
> тела. Это полнейший бедлам и бессмыслица. Изучение этого дерьма
> становится сущим адом. Особненно если учесть качесво документации.
В Inside OLE Крейга Брокшмдта все подробно объяснено. Да, общую
структуру OLE понять сложно, но это из-за сложности самой задачи.

У MS дальше начались проблемы на почве ActiveX — совершенно ненужная и
усложненная система windowless-контролов, плохо продуманные оптимизации
рисования (типа поддержки opaque/transparent частей, но без возможности
узнать заранее есть ли у объекта прозрачная часть) и т.п.

Но база OLE сделана на твердую 4.

> Все тоже самое можно сделать куда проще.
Как? Сами попробуйте набросать скелет такой системы.

> Как видишь, большую часть они покрывают. А то чего нет без проблем
> пишется на дотнете в чистом виде.
Я писал свой собственный AD контейнер/сервер на С++ и представляю какой
это объем работ (и хостинг контролов — это такая маленькая часть).

> Главное, что сама основа у дотнета куда более подходит для этой задачи.
> А интерфейсы ОЛЕ нужно выбросить на помойку хотя бы из-за их
> противоречивости и запутанности.
Так может весь .NET FW выбросить и писать на понятном и незапутанном VB6?

> Думаю, что рано или поздно будет создан некий управляемый ОЛЕ3. Не
> удивлюсь если на базе Авалона.
А Авалон еще жив? Я удивлен.

> Я уже не раз ворчал на WinAPI. По сравнению с FCL из дотнета — это
> чудовищьное уродство. ОЛЕ здесь ничем не отличается. Его давно пора
> переписывать. Настало время чистых решений.
Ага. Какой пафос...

При том что та часть API в .NET, которая соответствует Win32API — это
просто тонкая обертка, которая дает слегка более цивиллизованый вид, не
меняя сути.

Здравствуйте, LaptevVV, Вы писали:

R_X>>Работающие программисты нужны не для того, чтобы преподавать, а для того, чтобы вправлять мозги в нужном направлении! Невозможно научиться реально программировать, если писать только игрушечные примеры.

LVV>Фокус в том, что сначала нужно показать ЭЛЕМЕНТАРНОЕ — народ жиж нифига этого не знает...

Даже элементарное можно показать неправильно!

LVV>А какой действующий программер на это способен?! Да практически никакой... Я сам не мог этого, пока не стал преподавать...
LVV>А для уже действующих программистов препод фактически не нужен, поскольку они сами умеют учиться...

Мое убеждение, что лучшие преподаватели — это те, кто сначала были проф. программистами (архитекторами, менеджерами), а потом переключился на преподавание/консультирование. П.Нортон, Д.Кнут, Б.Керниган, Б.Страуструп, Д.Рихтер, Д.Круглински и т.д.

Здравствуйте, LaptevVV, Вы писали:

LVV>Мой опыт работы со студентами различного ума и уровня подготовки это подтверждает... Ктио научился писать процедуры — у того и в дальнейшем проблем не возникает...


ГВ>>Здесь, конечно, можно спорить, "кто перед кем стоял", но если нет какого-то ммм... конкретного воплощения некоторых базовых ограничений (ну хоть тот же запрет на goto или, в более случае ООП — требование соблюдать LSP), то можно попасть в ситуацию с неопределённостью критериев "правильно-неправильно", что весьма не гуд для обучения. Чему учить-то тогда? Быстро выдать что-то работающее? Хех...
LVV>Ну, я студентам говорю так: сначала программа должна правильно работать, а потом посмотрим на недостатки реализации..

Ну, тоже подход. Главное — недостатки реализации не прощать на определённом этапе.

Здравствуйте, Ranger_XL, Вы писали:

R_X>Мое убеждение, что лучшие преподаватели — это те, кто сначала были проф. программистами (архитекторами, менеджерами), а потом переключился на преподавание/консультирование. П.Нортон, Д.Кнут, Б.Керниган, Б.Страуструп, Д.Рихтер, Д.Круглински и т.д.

Знаешь, тут ты прав...

Я сам такой же путь прошел...
И студенты предпочитают общаться со мной, а не с другими преподами...

Здравствуйте, Кодёнок, Вы писали:

Кё>1. Что случилось с 4-го семестра? Все предметы стали интересными без разбору?

Нет, состав преподавателей сменился.

Кё>2. Писал все лекции, посещал все практики и др.?

Неа.

Кё>3. Сколько было отличников

не помню. Человека 4 наверное, может 5.

Кё> и всего людей в группе?

18

Кё>4. ВУЗ, факультет, кафедра?

РГРТА, ФВТ, каф. ЭВМ

Здравствуйте, VladD2, Вы писали:

C>>различными типами форматов.

VD>На фиг не упал. Сериализация и так есть.

VD>Причем логично было бы на сегодня текстовые и векторые форматы сериализовать в ХМЛ.

Да хоть в крестики-нолики. Есть интерфейс, описывающий иерархический персистентный стрим. А что лежит по ту сторону персистенции клиентам сугубо фиолетово, хоть даже реляционная или иерархическая БД.

Этот интерфейс — наследник IStream хорош тем, в качестве эелементов иерархии возвращает точно такие же стримы.
Например, сможешь ли ты восстановить из потока объект, если сборки, где он описан, на машине нет??? (поэкспериментируй)
А в OLЕ — запросто, десериализация всего остального не пострадает. Отсутствующий серверный элемент будет отображать пиктограмкой, но остальной док-т можно будет даже править и без ущерба сохранять.

C>>2. IOleObject — управление размерами, отображением, моникерами для
C>>linking'а. Так же, управление состоянием и глаголы.

VD>Бред фантазии неопытных разработчиков из МС. Дизайн OLE содержит тонны таких уродцев.

Ты не понял насчет линкинга. Объект ведь может быть в 3-х вариациях, от embedded до linked.

C>>3. IOLEClientSite/IOleContainer — взаимодействие с объектом.
C>>4. IOleControl — управление акселераторами.

VD>Аналоги уже есть в подсистеме контролов.

Насчет акселераторов — дудки, остальное — может быть.

C>>5. IDropSource/IDropTarget — управление OLE D&D.

VD>Есть обертка над ОЛЕ, но само ОЛЕ-решине довольно кривое. Я бы переписал на менеджед коде.

А как твой буфер тогда будет работать с не-менейджет кодом? Он же один на всю винду.

C>>7. IOleInPlaceUIWindow — согласование места для тулбаров.

VD>Тоже бы сделал более простую реализацию.

Там итак достаточно просто в этом интерфейсе. Помимо интерфейсовони еще общаются сообщениями виндов. Но зато они имеют совместимую для абсолютно любых тулбаров реализацию — и это круто. Ты бы мог сделать проще, если бы ограничился лишь одной библиотекой тулбаров. А если мне, например, не нравятся стандартные тулбары и я нахожу тулбары от SandBar гораздо более интересными? И еще я не уверен, что они оба смогут работать внутри окна другого процесса.

C>>8. IOleUndoManager — совместный Undo/Redo.

VD>Аналогично. К тому же в студии уже есть подобные интерфейсы, но более универсальные (управление транзакциями).

Речь о реализации. Интерфейсы везде более чем простые.

C>>9. IViewObject — отображение содержимого документа без создания окон.

VD>Опять же задача пустяковая.

Разве наследник System.Windows.Forms сможет нормально работать без СОБСТВЕННОГО окна??? Я как ни пытался его заставить — получается очень плохо, у них все завязано на собственный хендл, буквально в каждом внутреннем методе, где события обрабатываются. И даже сама MC сделала ActiveXHost таким, что он выделяет себе окно.

C>>10. И т.п.

VD>И т.п. там конечно много. Но ты уж меня извени, я знаю об этой кухни не по наслышке. За дизайн ОЛЕ и ОЛЕ-контролов нужно отрезать разные части тела. Это полнейший бедлам и бессмыслица. Изучение этого дерьма становится сущим адом. Особненно если учесть качесво документации.
VD>Все тоже самое можно сделать куда проще.

Вообще-то у меня как бы была возможность сравнивать исходники OLE и исходники Windows.Forms, и что-то я не увидел легкости в последнем и малого количества кода.


VD>Рельно для создания аналога ОЛЕ на дотнете нужно не так много. И сделать это не сложно.

Да, реально это сделать примерно вдвое проще, и было бы неплохо, чтобы кто-нить большой и тяжелый (типа MS) устаканил набор интерфейсов и их протокол для задач, аналогичных OLE. Реализацию можно будет сделать какую угодно и даже сделать бинды на разные GUI библиотеки. Просто если эти интерфейсы разработаем мы, то это так и останется YAOLE2.

VD>Так что проблема только в одном. В совместимости с прошлыми версиями.

У меня есть клиентская реализация для существующего OLE. http://files.rsdn.ru/21096/ss1.PNG (как вам фирма-заказчик?)
Обрати внимание на скрин-шоте на таб-контрол и кнопки Print, Close внизу активной формы.

Серверную часть написать сложнее
Но именно она и представляет наибольший интерес.

VD>Главное, что сама основа у дотнета куда более подходит для этой задачи. А интерфейсы ОЛЕ нужно выбросить на помойку хотя бы из-за их противоречивости и запутанности.

Нет противоречивости. Есть дополнения, когда OLE2 научился работать с windowsless + еще несколько оптимизаций, чтобы некие действия за 1 раз выполнялись. К тому же не забывай, что COM-интерфейсы не допускают перегрузок сигнатур, т.к. COM может использоваться с языками, не имеющими такой возможности, поэтому в названиях методов там некая пестрота. Да, если сделать на дотнете, то можно упорядочить это дело. (Но для меня эти вопросы совершенно не принципиальны, это внутренние кишки енжина и базовых классов, их никто напрямую не юзает)

VD>Вот это самая большая ошибка. Изменить получится и очень сильно. Замена даже базовой компонентной основы уже даст многое. Уйдут тучи грязи, кода в котором можно легко сделать ошибки и появится полноценный дизайн.

Ну, уйдет весь код по сериализации и часть кода по GUI. Если ориентироваться на windowless, то интерфейсы должны быть спроектированы так, чтобы не завязываться на Windows.Forms (!!!). Дополнительно надо разработать windowsless библиотеку (у меня есть заготовка, если кому интересно).

VD>ОЛЕ здесь ничем не отличается. Его давно пора переписывать.

Разочаровало и заставило бросить эксперименты в этом направлении то, что даже следующий офис не будет менейджед. Может быть уже было бы у меня серверное OLE и отлаженный windowsless.

Здравствуйте, VladD2, Вы писали:


V>> Я, напротив, уверен, что MS Office "всех поборол" именно с помощью OLE.

VD>Это преувеличение.

V>> По отдельности его продукты уступали аналогичным от конкурентов на момент "борьбы".

VD>А это просто не соотвествует действительности.

Это признает сам Стив Балмер в своей книге. Кому мне больше доверять? И кстати, мне довелось попользоваться Lotus 123 и Excel-ем того времени, первый был гораздо интереснее и дружелюбнее. Второй постепенно, от версии к версии "слизывали" с первого (постепенно догоняли)

V>> Зато умели работать совместно, что и решило исход схватки.

VD>Откровенно говоря я не часто встречаю использование OLE2. Мы являемся действительно активными пользователями Офиса, но OLE2 настолько криво, что используем мы его очень редко. Так что скорее оно оказалось рекламным трюком.

И ты не встявляешь в документ картинки, формулы, чертежи и графики в документы??? Мы, например, составляем тех-документацию в Ворде, так вот, у нас этого всего как грязи в каждом док-те.

И MS-биндером ты тоже не пользовался?


VD>>>А "серверные документны" — это вообще новоя терминалогия.

V>>Не документы, а элементы документов. Различают серверный и клиентский элемент (item) в OLE.

VD>Это была твоя цитата. Прикажешь домысливать за тобой?

Приказываю читать по написанному а не по придуманному. Еще приказываю вернуться на тот пост и самолично посмотреть.

Здравствуйте, vdimas, Вы писали:

V>Это признает сам Стив Балмер в своей книге. Кому мне больше доверять? И кстати, мне довелось попользоваться Lotus 123 и Excel-ем того времени, первый был гораздо интереснее и дружелюбнее. Второй постепенно, от версии к версии "слизывали" с первого (постепенно догоняли)

Мне плевать на вторитеты. Я вижу факты.

V>И ты не встявляешь в документ картинки, формулы, чертежи и графики в документы???

Вставляю. Но не как ОЛЕ. А как ссылки на файлы. Ранее вставляли Визио-объекты, но это приводило к куче проблем и мы отказались и от этого.

V> Мы, например, составляем тех-документацию в Ворде, так вот, у нас этого всего как грязи в каждом док-те.

Не эффективно и неудобно работать тоже конечно можно. Мы пришли к отказу от ОЛЕ не сразу и тому было много причин. Уверен, что объем обрабатываемой информации у нас значительно больше чем у вас. А людей занимающихся ее обработкой меньше.

V>И MS-биндером ты тоже не пользовался?

Более того. Вообще считаю его извращением.

VD>>Это была твоя цитата. Прикажешь домысливать за тобой?

V>Приказываю читать по написанному а не по придуманному. Еще приказываю вернуться на тот пост и самолично посмотреть.

Яволь май Фурер! Тока цитаты твои и скопрированы они через клипборд.

Здравствуйте, Cyberax, Вы писали:

C>Сериализация — это мелочь (IStreamPersist/IStoragePersist я тут даже не
C>упомянул). Нужно именно согласование форматов.

Еще одно уродливое решение.

C>Я уже приводил пример — картинка из Visio вставляется в Word как
C>OLE-объект, а в MSPaint как растровая картинка.

И что? Какие выводы?

C>Придумай лучше. Глаголы, положим, можно заменить на reflection+атрибуты.
C>Но что делать с моникерами и управлением extent'ами?

Придумать хуже уже будет очень сложно. Проектирование ОЛЕ2 я оцениваю на 2.

Моникеры вообще переусложненное решение. Реально унжно было ввести отдельно ссылки, и отдельно вложенные объекты. Это разные вещи и не фига их смешивать.

Заниматься гипотетическим проектированием прямого ОЛЕ наверно смысла нет. Или мы очень далеко зайдем.

>> C>3. IOLEClientSite/IOleContainer — взаимодействие с объектом.
>> C>4. IOleControl — управление акселераторами.
>> C>5. IDropSource/IDropTarget — управление OLE D&D.
>> Аналоги уже есть в подсистеме контролов.
C>Только для IOleControl, для сайта и контейнера — далеко не полная
C>функциональность.

Все что нужно есть. А лишнее оно и есть лишнее.

>> C>5. IDropSource/IDropTarget — управление OLE D&D.
>> Есть обертка над ОЛЕ, но само ОЛЕ-решине довольно кривое. Я бы переписал
>> на менеджед коде.
C>Чтобы получить кривое решение на managed-коде?

Чтобы получилось прямое решение. Идея называть форматы текстовой строкой — бредовая идея. Нужна просто сериализация объектов и 3-5 стандартных и не замороченных форматов. Сегодня в дрыг-дропе и клипборде используется в основном плоский текст, растровые изображения и весма замороченный формат HTML. Это очень криво.

Интерфейсы IDropSource/IDropTarget тоже криво спроектированы. Куча лишнего и непонятного. Но даже управляемые обретки и те лучше выглядят.

C>Я работал с D&D на Java (managed-код!) — разницы нет никакой по
C>сравнению с COM.


Это в сравнении с менеджед обертками или с КОМ-опвскми интерфейсами?
Начать хотя бы с того, что половина функций вообще к интерфейсам отношения не имеет. Это прос глобальные методы:

WINOLEAPI DoDragDrop(
   IDataObject  * pDataObject,   // Pointer to the data object
   IDropSource  * pDropSource,   // Pointer to the source
   DWORD          dwOKEffect,    // Effects allowed by the source
   DWORD        * pdwEffect      // Pointer to effects on the source
   );

typedef struct
{
    CLIPFORMAT      cfFormat;     // Clipboard format  
    DVTARGETDEVICE *ptd;          // (NULL)       Target device for rendering
    DWORD           dwAspect;     // (DV_CONTENT) How much detail is required for data rendering
    LONG            lindex;       // (-1)         Used when data is split across page boundaries
    DWORD           tymed;        // Storage medium used for data transfer (HGLOBAL, IStream etc)
    
} FORMATETC;
...

Все значения не типизированные. Используются странные структуры, текстовые строки, и куча указателелей в любом из которого без проблем можно ошибиться.

Даже используя менеджед-обертку реализовать дрыг-дроп не так то и просто. А на С++ вообще задалбывает.


>> C>7. IOleInPlaceUIWindow — согласование места для тулбаров.
>> Тоже бы сделал более простую реализацию.
C>Чего там упрощать? Там 6 методов для согласования границ объекта.

Вот их и упрощать. Половина этих методов реально не используется. И вообще работа на уровен "зарезервировать кусок окна" — это лажа полнейшая. Надо вводить абстракции тулбаров и меню и уже на их основе делать расширение.

>> C>8. IOleUndoManager — совместный Undo/Redo.
>> Аналогично. К тому же в студии уже есть подобные интерфейсы, но более
>> универсальные (управление транзакциями).
C>Так кто же спорит, что оно по-отдельности все просто?

Не, в ОЛЕ оно и по отдельности все крайне переусложнено. Крив сам дизайн. Так что даже если ОЛЕ преписать хотя бы на базе КОМ и С++, то все равно можно упростить эту технологию в разы и сделать ее более вменяемой.

Одна из стратегических ошибок — это межпроцессное взаимодействие. Не нужно это для вложенных документов и кратинок! Наоборот нужна внутрипроцессная активация как в случае ОЛЕ-контролов. Тогда и скорости будет хватать, и комуникации упростятся.

>> И т.п. там конечно много. Но ты уж меня извени, я знаю об этой кухни не
>> по наслышке. За дизайн ОЛЕ и ОЛЕ-контролов нужно отрезать разные части
>> тела. Это полнейший бедлам и бессмыслица. Изучение этого дерьма
>> становится сущим адом. Особненно если учесть качесво документации.
C>В Inside OLE Крейга Брокшмдта все подробно объяснено. Да, общую
C>структуру OLE понять сложно, но это из-за сложности самой задачи.

Спасибо за рассказ это тому, кто 7 лет назад тыкал носом в эту книгу кого не попадя. Толко вот второе издание этой книги было удалено из МСДН еще лет 5 назад (если не раньше). Так что найти ее современному программисту крайне сложно. Когда я попытался выяснить почему ее убрали, то оказалось, что она уже "сильно отстала от жизни".

C>У MS дальше начались проблемы на почве ActiveX — совершенно ненужная и
C>усложненная система windowless-контролов, плохо продуманные оптимизации
C>рисования (типа поддержки opaque/transparent частей, но без возможности
C>узнать заранее есть ли у объекта прозрачная часть) и т.п.

Идея безоконных контролов как раз разумна. Проблемы у МС в переусложненности интферйсов и в отсуствии продуманной стратегии. ОЛЕ2 рождалось как-то итеративно и в итоге вышел уродец. К тому же в те времена в МС к дизайну интерфейсов относились довольно халтурно. Именно тогда родились все переусложненные интерфейсы КОМ-а и понимание того, то нужен дотнет позволяющих устранить переусложненность и имеющий четкие принцыпы дизайна.

C>Но база OLE сделана на твердую 4.

На 3 в лучем случае. А рельно на 2. Может это и было круто в 94-ом, но на сегодня это сильно морально устаревшее решение. И я бы давно занялся бы его переписыванием.

>> Все тоже самое можно сделать куда проще.
C>Как? Сами попробуйте набросать скелет такой системы.

Что значит как? Сесть, проанализировать чего нехватает, и пспроетировать. Далее реализовать пару контролов для упрощения реализации и включить во фрэймворк.

Думаю, что если бы не совместимость то давно так бы и сделали.

C>Я писал свой собственный AD контейнер/сервер на С++ и представляю какой
C>это объем работ (и хостинг контролов — это такая маленькая часть).

Я тоже писал и ActiveX-контейнер и поддержку многих вещей из ОЛЕ2. Так что не надо мне мозги пудрить. Я знаю о кривизне дийайна ОЛЕ2 не по нслышке. Более того недавно я писал текствый редактор и был вынужден реализовывать вещи вроде дрыг-дропа и анду. И скажу тебе как на духу, то что проектировалось с нуля выглядит изумительно. А то что основано на обертках ОЛЕ2 очень некрасиво.

>> Главное, что сама основа у дотнета куда более подходит для этой задачи.
>> А интерфейсы ОЛЕ нужно выбросить на помойку хотя бы из-за их
>> противоречивости и запутанности.
C>Так может весь .NET FW выбросить и писать на понятном и незапутанном VB6?

Фрэймворк чистая абстракция. Практически все интерфейсы в нем свои. Ну, а про VB6 — это уже чистая демагогия.

>> Думаю, что рано или поздно будет создан некий управляемый ОЛЕ3. Не
>> удивлюсь если на базе Авалона.
C>А Авалон еще жив? Я удивлен.

Не каждая неразумная фраза тянет на сарказм.

>> Я уже не раз ворчал на WinAPI. По сравнению с FCL из дотнета — это
>> чудовищьное уродство. ОЛЕ здесь ничем не отличается. Его давно пора
>> переписывать. Настало время чистых решений.
C>Ага. Какой пафос...

Никакого. Это мое мнение основаное на немалом опыте использования обоих миров.

C>При том что та часть API в .NET, которая соответствует Win32API — это
C>просто тонкая обертка, которая дает слегка более цивиллизованый вид, не
C>меняя сути.

У тебя явный пробел в понимании. Важна не реализация, а интерфейс. Именно его ты используешь в программе. По этому если интерфейс устраивает, то и ладушки, пусть будет обертка. Проблема с ОЛЕ в том, что хорошо обернуть его очень сложно. Спроектировано все так, что то и дело вылезают уши вроде окон или мет для тулбаров. Плюс ко всему очень большой проблемой является дублирование функций и отсуствие четкого понимания что нужно реально использовать.

Здравствуйте, vdimas, Вы писали:

V>Да хоть в крестики-нолики. Есть интерфейс, описывающий иерархический персистентный стрим. А что лежит по ту сторону персистенции клиентам сугубо фиолетово, хоть даже реляционная или иерархическая БД.

V>Этот интерфейс — наследник IStream хорош тем, в качестве эелементов иерархии возвращает точно такие же стримы.
V>Например, сможешь ли ты восстановить из потока объект, если сборки, где он описан, на машине нет??? (поэкспериментируй)
V>А в OLЕ — запросто, десериализация всего остального не пострадает. Отсутствующий серверный элемент будет отображать пиктограмкой, но остальной док-т можно будет даже править и без ущерба сохранять.

Это не проблема и для ХМЛ-сериализации. Интерфейс тоже можно оставить чистым.

V>Ты не понял насчет линкинга. Объект ведь может быть в 3-х вариациях, от embedded до linked.

Спасибо за оценку моих знаний, но она не врена. Я знаю, что такое моникиры и знаю всю прееусложненность и кривизну этого решения. Жить надо проше. Пусть ссылки будут просто ссылками (как в ХТМЛ), а вложенные объекты вложенными объектами. Не нужна тут абстракция. Или если и нужна, то очнь легенькая.

V>Насчет акселераторов — дудки, остальное — может быть.

Курим System.Windows.Forms.IMessageFilter. Так же укрим подсистему предварительной обработки сообщений контролом метод Control.PreProcessMessage() (на его основе, кстати, делается обработка сообщений для OCX-ов). С их помощью черта лысого можно реализовать. Но нет проблем и еще интерфейс ввести.

V>А как твой буфер тогда будет работать с не-менейджет кодом? Он же один на всю винду.

В этом и проблема. Но думаю, что не так уж трудно будет мостик совместимости наладить.

C>>>7. IOleInPlaceUIWindow — согласование места для тулбаров.

VD>>Тоже бы сделал более простую реализацию.

V>Там итак достаточно просто в этом интерфейсе.

Там не просто, там убого и завязано на примитивы Виндовс.

V>И еще я не уверен, что они оба смогут работать внутри окна другого процесса.

Считаю межпроцессную активацию объектов в ОЛЕ ошибкой. Но если что ремоутинг и Индигу никто не отменял.

V>Речь о реализации. Интерфейсы везде более чем простые.

Нет речь именно об интерфейсах. Они в ОЛЕ2 переусложнены и запутаны. А реализация для конторы класса МС не самая большая проблема.

V>Разве наследник System.Windows.Forms сможет нормально работать без СОБСТВЕННОГО окна???

К сожалению нет. Но это не проблема. Да и можно пользоваться сразу Авалоном в котором окон вообще нет.

V>Вообще-то у меня как бы была возможность сравнивать исходники OLE и исходники Windows.Forms, и что-то я не увидел легкости в последнем и малого количества кода.

Мне плевать на исходники. Меня интересует простота использования.

VD>>Рельно для создания аналога ОЛЕ на дотнете нужно не так много. И сделать это не сложно.

V>Да, реально это сделать примерно вдвое проще, и было бы неплохо, чтобы кто-нить большой и тяжелый (типа MS) устаканил набор интерфейсов и их протокол для задач, аналогичных OLE.

Вот и я о том же.

V> Реализацию можно будет сделать какую угодно и даже сделать бинды на разные GUI библиотеки. Просто если эти интерфейсы разработаем мы, то это так и останется YAOLE2.

Полностью согласен. Потому даже не заикаюсь об этом.

Не ясно тогда, о чем ты опять со мной споришь?

ЗЫ

Вообще у меня часто складывается печатление, что ты вроде бы как со мной согласен, но цепляшся к мало значимым мелочам или интерпретации терминов и начинается бессмысленный и долгий спор.

VladD2 wrote:
> C>Я уже приводил пример — картинка из Visio вставляется в Word как
> C>OLE-объект, а в MSPaint как растровая картинка.
> И что? Какие выводы?
Простой сериализацией не обойдешься.

> C>Придумай лучше. Глаголы, положим, можно заменить на reflection+атрибуты.
> C>Но что делать с моникерами и управлением extent'ами?
> Придумать хуже уже будет очень сложно. Проектирование ОЛЕ2 я оцениваю на 2.
> Моникеры вообще переусложненное решение. Реально унжно было ввести
> отдельно ссылки, и отдельно вложенные объекты. Это разные вещи и не фига
> их смешивать.
В OLE нет ссылок, есть _linked_ objects. Для пользователя с ними работа
точно так же прозрачно идет.

> Заниматься гипотетическим проектированием прямого ОЛЕ наверно смысла
> нет. Или мы очень далеко зайдем.
А попробуй. Просто опиши интерфейсы/классы и что они будут делать.

> C>Только для IOleControl, для сайта и контейнера — далеко не полная
> C>функциональность.
> Все что нужно есть. А лишнее оно и есть лишнее.
Нет Бога кроме Аллаха и Microsoft пророк Его? Хотя нет, вроде цитата
по-другому звучала.

> Чтобы получилось прямое решение. Идея называть форматы текстовой строкой
> — бредовая идея. Нужна просто сериализация объектов и 3-5 стандартных и
> не замороченных форматов.
Ага. Чтобы когда потребовалось передавать свои объекты — нужно было
курить бамбук. Еще умные идеи будут?

> Сегодня в дрыг-дропе и клипборде используется
> в основном плоский текст, растровые изображения и весма замороченный
> формат HTML. Это очень криво.

> C>Я работал с D&D на Java (managed-код!) — разницы нет никакой по
> C>сравнению с COM.
> Это в сравнении с менеджед обертками или с КОМ-опвскми интерфейсами?
Вот пример кода на Java:

  Transferable transferable =(Transferable) dragNode.getUserObject();
  Cursor cursor = selectCursor (e.getDragAction())
  dragSource.startDrag(e, cursor, transferable, this);

Вот аналог на C++:

DragSrcHelper dragSrcHelper;
CComPtr<IDataObject> pdobj=getTransferObject(&dragSrcHelper);
::DoDragDrop(pdobj, &dragSrcHelper, DROPEFFECT_COPY, NULL);

Разница только в синтаксисе.

> Начать хотя бы с того, что половина функций вообще к интерфейсам
> отношения не имеет. Это прос глобальные методы:
О Боже! Ну заверните их в синглтоны для полного спокойствия разума. Типа
чтобы все объектно-ориентировано было.

> typedef struct
> {
> CLIPFORMAT cfFormat; // Clipboard format
> DVTARGETDEVICE *ptd; // (NULL) Target device for rendering
> DWORD dwAspect; // (DV_CONTENT) How much detail is required for data rendering
> LONG lindex; // (-1) Used when data is split across page boundaries
> DWORD tymed; // Storage medium used for data transfer (HGLOBAL, IStream etc)
> } FORMATETC;
> ...
> Все значения не типизированные.
Нетипизированы здесь только dwAspect (который есть комбинация флагов из
enum'ов DVASPECT и DVASPECT2) и tymed (enum TYMED).

CLIPFORMAT, DVTARGETDEVICE — это _типизированые_ поля.

> Используются странные структуры,
> текстовые строки, и куча указателелей в любом из которого без проблем
> можно ошибиться.
Просто смешно. Ну замените DWORD'ы на умные enum'ы и будет вам щастье.

> Даже используя менеджед-обертку реализовать дрыг-дроп не так то и
> просто. А на С++ вообще задалбывает.
Писать нормально надо, значит. У меня добавление D&D к моему контролу
заняло 40 минут. Потребовалось:
1. Написать обработчик OnDrag, в нем сделать объект данных типа
CF_STREAM, куда сериализовать указатель на текущий объект
(CoMarshalInterface), а потом вызавать DoDragDrop.
2. В объекте-приемнике подключить
http://www.codeproject.com/shell/dragdrop.asp
3. Реализовать метод OnDrop у наследника CIDropTarget. Вот его полный код:

virtual bool OnDrop(FORMATETC* pFmtEtc, STGMEDIUM& medium, DWORD *pdwEffect)
{
    if(pFmtEtc->cfFormat == CF_3DD && medium.tymed == TYMED_ISTREAM)
    {
        com_ptr<DCF2::IDataSample> sample;
        HRESULT hr = CoUnmarshalInterface(
            medium.pstm,__uuidof(DCF2::IDataSample),
            (LPVOID*)sample.out());
        if (FAILED(hr))
            return true;
        ctrl->BindData(sample);
    }
    return true; //let base free the medium
}

Все! Система OLE мне обеспечивает полную прозрачность между приложениями.

Где аналог не .NET?

>> > C>7. IOleInPlaceUIWindow — согласование места для тулбаров.
>> > Тоже бы сделал более простую реализацию.
> C>Чего там упрощать? Там 6 методов для согласования границ объекта.
> Вот их и упрощать. Половина этих методов реально не используется. И
> вообще работа на уровен "зарезервировать кусок окна" — это лажа
> полнейшая. Надо вводить абстракции тулбаров и меню и уже на их основе
> делать расширение.
В этом куске окна я могу нарисовать все что мне угодно. Ну ладно,
введите IWindowPiece для успокоения объектно-ориентированой совести.

> Одна из стратегических ошибок — это межпроцессное взаимодействие. Не
> нужно это для вложенных документов и кратинок! Наоборот нужна
> внутрипроцессная активация как в случае ОЛЕ-контролов. Тогда и скорости
> будет хватать, и комуникации упростятся.
А в OLE можно и внутрипроцессную активацию использовать (Брокшмидта,
говорите, читали?). Просто возможна и внешняя активация без особых затрат.

> C>Но база OLE сделана на твердую 4.
> На 3 в лучем случае. А рельно на 2. Может это и было круто в 94-ом, но
> на сегодня это сильно морально устаревшее решение. И я бы давно занялся
> бы его переписыванием.
Ага. Поменял бы глобальные функции на синглтоны и вместо уродливых
страшных указателей типа DVTARGETDEVICE сделал бы ITargetDevice?

>> > Все тоже самое можно сделать куда проще.
> C>Как? Сами попробуйте набросать скелет такой системы.
> Что значит как? Сесть, проанализировать чего нехватает, и
> пспроетировать. Далее реализовать пару контролов для упрощения
> реализации и включить во фрэймворк.
Так я уже пробовал написать свою компонентную систему. Как в анекдоте —
OLE получилось.

Нет, в OLE можно кое-что доработать (хотя бы интерфейсы упорядочить и
ввести методы настройки трансформаций координат). Но сам дизайн и
архитектура — вполне себе нормальны.

> Я тоже писал и ActiveX-контейнер и поддержку многих вещей из ОЛЕ2. Так
> что не надо мне мозги пудрить.
AX-контейнер (вы сами мне ссылку на него посылали) — это едва четверть
всего, что нужно сделать.

> C>Так может весь .NET FW выбросить и писать на понятном и незапутанном VB6?
> Фрэймворк чистая абстракция. Практически все интерфейсы в нем свои. Ну,
> а про VB6 — это уже чистая демагогия.
OLE2 — тоже чистая абстракция. И что?

> C>А Авалон еще жив? Я удивлен.
> Не каждая неразумная фраза тянет на сарказм.
В Vista: WinFS отменили, Monad shell отменили, .NET сильно урезали в
значимости. Так что я действительно удивлен.

> У тебя явный пробел в понимании. Важна не реализация, а интерфейс.
Странно. Я всегда считал важным прежде всего архитектуру. А интерфейс —
деталью реализации. Своеобразным "usability-сахаром".

Поэтому пользоваться libxml с простым С-интерфейсом удобнее
красивоинтерфейсного MSXMLя.

Здравствуйте, Sinclair, Вы писали:

S>А как раз примерно с 4-5 семестра студент наконец понимает, что именно от него требуется на сессии, и подбирает верный баланс между пьянкой и учебой. Я на все пятерки не вышел, но головняков и неожиданных троек на третьем-четвертом курсах уже не было. Даже скучновато стало — интрига ушла, сессия перестала быть пугающим водоворотом, стало понятно, что собственно зубрежка — вещь бесполезная в принципе, и главное — не донести максимум знаний до экзамена, а максимально эффективно подать донесенные.

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

Здравствуйте, VladD2, Вы писали:


V>>Это признает сам Стив Балмер в своей книге. Кому мне больше доверять? И кстати, мне довелось попользоваться Lotus 123 и Excel-ем того времени, первый был гораздо интереснее и дружелюбнее. Второй постепенно, от версии к версии "слизывали" с первого (постепенно догоняли)

VD>Мне плевать на вторитеты. Я вижу факты.

В данном случае Стив Балмер не то, чтобы просто авторитет со стороны, а первоисточник.

V>>И ты не встявляешь в документ картинки, формулы, чертежи и графики в документы???

VD>Вставляю. Но не как ОЛЕ. А как ссылки на файлы.

Если содержимое описываемой диаграммы не видно в тексте тех-доки, то такая дока в первую очередь неудобна, т.е. бессмысленна. Если диаграмма видна, то вы юзаете linked — это тоже ОЛЕ. Один из 3-х режимов.

V>>И MS-биндером ты тоже не пользовался?

VD>Более того. Вообще считаю его извращением.

Согласен, с помощью OLE можно было бы обойтись, если бы не одно НО! — Оформление заголовков страниц, разрывы и т.д. в документах, сделаных в разных ср-вах: Word, Excel, PPoint.

Здравствуйте, VladD2, Вы писали:

VD>Здравствуйте, vdimas, Вы писали:

V>>Да хоть в крестики-нолики. Есть интерфейс, описывающий иерархический персистентный стрим. А что лежит по ту сторону персистенции клиентам сугубо фиолетово, хоть даже реляционная или иерархическая БД.

V>>Этот интерфейс — наследник IStream хорош тем, в качестве эелементов иерархии возвращает точно такие же стримы.
V>>Например, сможешь ли ты восстановить из потока объект, если сборки, где он описан, на машине нет??? (поэкспериментируй)
V>>А в OLЕ — запросто, десериализация всего остального не пострадает. Отсутствующий серверный элемент будет отображать пиктограмкой, но остальной док-т можно будет даже править и без ущерба сохранять.

VD>Это не проблема и для ХМЛ-сериализации. Интерфейс тоже можно оставить чистым.

Как это не проблема? Ты хочешь сказать, что если одной из сборок нет на целевой машине, я смогу "поднять" документ, затем снова сохраню и ничего не потеряю из информации? А можно код этого чуда на дотнет?

V>>Ты не понял насчет линкинга. Объект ведь может быть в 3-х вариациях, от embedded до linked.

VD>Спасибо за оценку моих знаний, но она не врена. Я знаю, что такое моникиры и знаю всю прееусложненность и кривизну этого решения. Жить надо проше. Пусть ссылки будут просто ссылками (как в ХТМЛ), а вложенные объекты вложенными объектами. Не нужна тут абстракция. Или если и нужна, то очнь легенькая.

Именно для описываемого и нужна, и не легенькая, а полновесная. Помнишь с чего ветка началась, ты сказал, что в дотнет "и так уже все есть". На самом деле, там есть только аналог COM, хоть и более удобный. А именно OLE придется все же делать дополнительно, если хотим получить аналогичную функциональность.

V>>Насчет акселераторов — дудки, остальное — может быть.

VD>Курим System.Windows.Forms.IMessageFilter. Так же укрим подсистему предварительной обработки сообщений контролом метод Control.PreProcessMessage() (на его основе, кстати, делается обработка сообщений для OCX-ов). С их помощью черта лысого можно реализовать. Но нет проблем и еще интерфейс ввести.

Не надо рассказывать как это можно сделать. Тем более, что ты перечислил не все методы.
Речь о том, что ничего не готово прямо сейчас.

V>>А как твой буфер тогда будет работать с не-менейджет кодом? Он же один на всю винду.

VD>В этом и проблема. Но думаю, что не так уж трудно будет мостик совместимости наладить.

Еще один?
Этот мостик — суть танцы вокруг сериализаций и меток форматов. Не слишком ли жирно для такой ерунды кучу мостиков?


V>>И еще я не уверен, что они оба смогут работать внутри окна другого процесса.

VD>Считаю межпроцессную активацию объектов в ОЛЕ ошибкой.

Да ну как тебе сказать... А по мне — очень удобно. Если сервак элемента накроется — не накроется контент остального документа.

VD>Но если что ремоутинг и Индигу никто не отменял.

Ты опять про пути реализации. Прямо сейчас есть возможность помещать свои тулбары в окна других процессов или нет? Т.е., все-таки делать надо? И почему ты считаешь, что там все убого? Только лишь потому, что ориентировано на винды? Я просмотрел интерфейсы — нифига подобного. HWND-это просто хендл. На винды завязана лишь РЕАЛИЗАЦИЯ, при желании можно сделать реализацию на любой GUI.

V>>Вообще-то у меня как бы была возможность сравнивать исходники OLE и исходники Windows.Forms, и что-то я не увидел легкости в последнем и малого количества кода.

VD>Мне плевать на исходники. Меня интересует простота использования.

Какие-то проблемы в использовании OLE в разработке? Да, под дотнетом проблематично без собственных велосипедов. В MFC или ATL — весьма просто. Ну да это мы отвлеклись...

VD>>>Рельно для создания аналога ОЛЕ на дотнете нужно не так много. И сделать это не сложно.

V>>Да, реально это сделать примерно вдвое проще, и было бы неплохо, чтобы кто-нить большой и тяжелый (типа MS) устаканил набор интерфейсов и их протокол для задач, аналогичных OLE.

VD>Вот и я о том же.

V>> Реализацию можно будет сделать какую угодно и даже сделать бинды на разные GUI библиотеки. Просто если эти интерфейсы разработаем мы, то это так и останется YAOLE2.

VD>Полностью согласен. Потому даже не заикаюсь об этом.

VD>Не ясно тогда, о чем ты опять со мной споришь?

Ты же говорил, что все уже есть
А я оцениваю разработку OLE-подобной схемы как минимум в человеко-год. (и то оптимистично) Со всеми режимами, удобствами в меню, тулабарах, независимостью от Windows.Forms и пр.

VD>ЗЫ

VD>Вообще у меня часто складывается печатление, что ты вроде бы как со мной согласен, но цепляшся к мало значимым мелочам или интерпретации терминов и начинается бессмысленный и долгий спор.

Да нет, просто за живое задел, с этим ОЛЕ
Я потратил 2 недели безвылазно, а ты мне — "да все было готово"

vdimas wrote:
> Как это не проблема? Ты хочешь сказать, что если одной из сборок нет на
> целевой машине, я смогу "поднять" документ, затем снова сохраню и ничего
> не потеряю из информации? А можно код этого чуда на дотнет?
Писал в свое время такое "чудо" для Java. Всего-то надо написать
реализацию обхода по графу объектов

> HWND-это просто хендл. На винды завязана лишь РЕАЛИЗАЦИЯ, при желании
> можно сделать реализацию на любой GUI.
Кстати, в OpenOffice так и сделано. У них обобщенная реализация OLE,
которая в Винде использует Виндовые средства. В Линуксе используется
самопальная эмуляция.

> Ты же говорил, что все уже есть
> А я оцениваю разработку OLE-подобной схемы как минимум в человеко-год.
> (и то оптимистично) Со всеми режимами, удобствами в меню, тулабарах,
> независимостью от Windows.Forms и пр.
Больше бери. Тем более, что если делать — то надо некоторые недоработки
в OLE будет исправлять.

Здравствуйте, vdimas, Вы писали:

VD>>Это не проблема и для ХМЛ-сериализации. Интерфейс тоже можно оставить чистым.

V>Как это не проблема? Ты хочешь сказать, что если одной из сборок нет на целевой машине, я смогу "поднять" документ, затем снова сохраню и ничего не потеряю из информации? А можно код этого чуда на дотнет?

На событие XmlSerializer.UnknownNode глядел?

Здравствуйте, Cyberax, Вы писали:

C>vdimas wrote:
>> Как это не проблема? Ты хочешь сказать, что если одной из сборок нет на
>> целевой машине, я смогу "поднять" документ, затем снова сохраню и ничего
>> не потеряю из информации? А можно код этого чуда на дотнет?
C>Писал в свое время такое "чудо" для Java. Всего-то надо написать
C>реализацию обхода по графу объектов

Э-э нет, мне подавай готовое решение ср-вами дотнет. Это нужно писать собственные форматтеры на каждый из вариантов — бинарный и XML, которые, встретив неразрешимый референс, будут десериализовать его в некий "черный ящик", который сумеет сериализовать свое содержимое обратно. А если учесть, что предлагается сохранение произвольного графа объектов, вместо четкого разделения на однонаправленный граф вложенных элементов, то этот упомянутый "черный ящик" должен будет уметь корректировать индексы референсов на объекты во время последующего сохранения (во время сериализации те объекты, на которые есть референсы, нумеруются). В общем, для реализации даже этой этой мини-задачи "в духе дотнет" придется малость попотеть.

C>Больше бери. Тем более, что если делать — то надо некоторые недоработки
C>в OLE будет исправлять.

Ну там рефакторинг небольшой, и надо закрыть пару хаков в нем, когда он сообщения виндов в окошки других процессов посылает. Надо все явно на интерфейсы перевести.