Comments on Блог GunSmoker-а: Разработка системы плагинов в Delphi, часть 2: раз...

Окей, будем считать так: в статье взят IStream, чт...

2012-01-11T01:10:22.062+04:00

Окей, будем считать так: в статье взят IStream, чтобы было меньше писать кода, а у себя - пишите свой аналог. :)

По поводу IStream и TStream. Когда-то напоролся на...

2012-01-11T00:55:00.201+04:00

По поводу IStream и TStream. Когда-то напоролся на такой "подводный камень". Дело в том что на TStreamAdapter-е не реализован метод IStream.Clone. На практике этот метод довольно часто используется сторонними модулями (особенно написанными на других языках), когда IStream нужно хранить некоторое время на стороне модуля т.к. позволяет работать со своим seek без дублирования ресурса.
Почему-то очень часто проверку HResult на Clone опускают :( В результате подсовываешь адаптер - и получаешь эксепшн.

А самое печальное во всем этом то, что нельзя реализовать свой TStreamAdapter с IStream.Clone, в силу неправильно заложенной архитектуры (видимо не задумались когда-то разработчики делфи, а потом переделывать не стали).
Клонирование нужно делать на уровне каждого вида ресурса (TFileStream/TMemoryStream/TКакойтоStream).
Текущая архитектура скрывает сам ресурс (хендл, указатель памяти и т.п.) внутри самого TStream наследника, а значит и не возможно нормальное клонирование. Решение - выносить ресурс отдельно с подсчетом ссылок.

Поэтому прежде чем использовать повсеместно стандартные TStream наследники и TStreamAdapter нужно хорошенько подумать понадобится ли вам Clone, и если да - то реализовывать свои TStream наследники, а так же TStreamAdapter.

Я помнится хорошенько так попал, когда 80% кода было написано :)

Поясню, почему был выбран IStream - потому что это...

2012-01-10T22:40:45.962+04:00

Поясню, почему был выбран IStream - потому что это хоть какой-то стандарт.

Например, в Delphi есть готовые классы-переходники. Подозреваю, что аналогичные вещи есть и в других языках. Т.е. если использовать IStream - то вам придётся писать меньше кода, поскольку код уже написан.

Но никто не запрещает не использовать IStream. Вполне можно было бы создать свой интерфейс по аналогии (скажем, гипотетический IDataStream), и по аналогии же написать переходники к TStream.

Плюсы: нет проблем с библиотекой типов, т.к. интерфейс свой. Минусы: писать больше кода (как разработчику программы, так и разработчикам плагинов).

Так что выбирайте любой подход, какой больше нравится.

> лучше использовать IServiceProvider

Не уверен, что понял мысль.

Явный доступ к плагинам - таки не айс. Если будет ...

2012-01-09T17:36:27.946+04:00

Явный доступ к плагинам - таки не айс. Если будет нужда перераспределить обязанности плагинов, использовать в одних плагинах другие, управлять порядком загрузки оных - лучше использовать IServiceProvider.
В этом случае неважно, кто реализует функционал: ядро, плагин или мок - клиентский код останется прежним.

Я бы предложил выкинуть IStream - он слишком мощны...

2012-01-09T17:23:38.313+04:00

Я бы предложил выкинуть IStream - он слишком мощный, большинство реализаций все равно не смогут поддерживать этот интерфейс в полном объеме.

К стати об TOleStream. Одно упоминание Vcl.AxCtrls...

2012-01-09T00:13:05.420+04:00

К стати об TOleStream. Одно упоминание Vcl.AxCtrls.pas в котором он описан, раздувает размер библиотеки на метр с лишним. Пришлось вырезать в отдельный файл, благо совсем немного. А то получалось, что при размере хоста в 400 КБ, плагин весил 1,5 МБ.

Исследовал такой вариант: я скомпилировал IDL файл...

2012-01-09T00:04:19.869+04:00

Исследовал такой вариант: я скомпилировал IDL файл с подключенным objidl.idl в TLB файл.

IStreamTLB.idl:

import "objidl.idl";
[
uuid(81DF4D4E-C82D-49FF-B9ED-EA3E93175479),
version(1.0),
helpstring("IStream declaration")
]
library IStreamTLB
{
importlib("stdole32.tlb");
importlib("stdole2.tlb");

[
object,
uuid(30014161-581B-462C-B110-D99BCD789F99),
pointer_default(unique),
helpstring("Dummy interface")
]
interface IMyDummyStream : IUnknown
{
HRESULT UseIStream( [in] IStream* Stream
);
}

};

Build.bat:
@echo off
call "c:\Program Files\Microsoft Visual Studio 10.0\VC\bin\vcvars32.bat"
midl "C:\IStreamTLB.Idl" /out C:\ /h "TestHeader.hpp"

Получил IStreamTLB.tlb. Что интересно - в заголовочнике была верно указана ссылка на первоисточник (objidl.h).

Далее я зарегистрировал этот файл в системе (я воспользовался Component/Import Component/Import Type Library/Add - это автоматически зарегистрирует библиотеку типов, после чего мастер импорта можно закрыть (понятно, что для регистрации IDE должна быть запущена под администратором). Альтернативно, можно использовать утилиты regtlib.exe или regtlibv12.exe от Microsoft-а.

После регистрации библиотека типов доступна в списке всех библиотек и мы можем отметить её галочкой. После чего у нас появится возможность использовать IStream.

Однако, если потом эту библиотеку типом импортировать в Delphi - она создаст заголовочник без ссылки на существующее объявление IStream, а вместо этого добавит новое определение. В связи с чем мы получим проблемы из-за несовместимости типов IStream из стандартного модуля и нашего заголовочника. Причём это же происходит и с Microsoft-скими библиотеками типов при импорте их в Delphi.

Понятно, что автосгенерированные заголовочники можно легко подправить: вписать в uses модуль ActiveX, а дублирующееся объявление IStream удалить. Но... это будет ручная обработка, которой я и хотел избежать.

Посмотрел примеры TLB от Microsoft - в них IStream...

2012-01-08T21:36:56.887+04:00

Посмотрел примеры TLB от Microsoft - в них IStream вполне себе используется. Например, в imapi2.tlb. Только он не импортируется, а объявлен прямо в этой же библиотеке типов. Исходник этой библиотеки типов (imapi2.idl) содержит строку

import "objidl.idl";

Т.е. в "нашу" библиотеку типов импортируется файл objidl.idl. Таким образом, получается, что это - правильное решение.

Правда, я без понятия, как это сделать с редактором библиотек типов Delphi.

Поэтому предлагаю попробовать сделать такой финт ушами: библиотеки типов типа imapi2.tlb (или других, где есть определение IStream) - они стандартные. Т.е. они уже зарегистрированы в системе. И в них есть нужное нам определение. Поэтому, когда мы создали в Delphi библиотеку типов, можно перейти на вкладку "Uses", щёлкнуть по списку правой кнопкой мыши и выбрать пункт меню "Show all type libraries", после чего отыскать в списке стандартную библиотеку типов с IStream (например, "Microsoft IMAP2 Base Functionality") и установить напротив неё галочку. После этой нехитрой операции во всех полях выбора типов появится IStream* и другие типы, определённые в выбранной нами библиотеке типов.

Список стандартных библиотек типов с определением IStream:

cordebug.tlb
imapi2.tlb
imapi2fs.tlb
metahost.tlb
mscoree.tlb
msvidctl.tlb
SearchAPI.tlb
tuner.tlb
wdstptmgmt.tlb

Хм, про это я не знал. Действительно, IStream нет...

2012-01-08T21:06:25.579+04:00

Хм, про это я не знал.

Действительно, IStream нет в стандартных библиотеках типов, потому что он не предназначен для маршалинга. Гм, мы не используем маршалинг, так что иметь его хотелось бы...

Как я это вижу, правильное решение здесь - включить в наш IDL файл файл objidl.idl (в нём находится определение IStream). Проблема тут в том, что в редакторе библиотеки типов Delphi такое не сделать (или я не нашёл?).

Нормальное (но не слишком удобное решение) с редактором Delphi - использовать IUnknown вместо IStream. Разработчик плагинов после импорта TLB может просто подключить (уже существующий) objidl.h и выполнить запрос IStream у IUnknown (о том, что это надо сделать, будет написано в документации). Это проще всего, но немного неудобно в использовании со стороны плагина (две лишние строчки кода на каждый параметр типа IStream).

Ну или включить IStream в свою библиотеку типов, т.е. переописать его самому. Необязательно, кстати, делать это в отдельной библиотеке типов, можно и в основной. Тут есть два варианта - ввести новый тип или полностью продублировать старый (вместе с GUID). Как-то у меня есть сомнения в правильности последнего. Наверняка это будет работать, но ведь TLB планируется использовать для генерации заголовочников. Поэтому у нас появится новый что-то-там.h, где будет определение IStream. Получится, что у нас будет два файла (стандартный objidl.h и что-то-там.h), где определён IStream. Если же пойти по первому пути, то придётся написать свой TOleStream и свой TStreamAdapter (чтобы они работали с новым IMyStream). Это же нужно будет сделать и со стороны плагина. Так что вроде как с этим подходом в целом получается существенно больше проблем, чем с первыми двумя.

Что здесь лучше всего сделать - я без понятия. Буду благодарен, если кто-то поделится своими мыслями/опытом.

Я бы рекомендовал для начала использовать подход с IUnknown. Две строчки лишнего кода - не большая плата за уже написанный стандартный код. А в дальнейшем надо посмотреть на возможность подключения objidl.idl.

По поводу передачи файлов через IStream. Этот инте...

2012-01-08T18:26:27.212+04:00

По поводу передачи файлов через IStream. Этот интерфейс описан в ObjIdl.h, но, по-видимому, не предназначен для импорта [ссылка], т.е. его нет в списке доступных типов в редакторе библиотеки типов. Там описан способ решения, но тогда придется таскать повсюду свою библиотеку типов, единственная цель которой — экспорт IStream, и регистрировать её. Да и ссылаться полученный код будет, если я правильно понял, на наше объявление IStream. Либо передавать в параметре IUnknown, а потом приводить его в IStream, что тоже по-моему не очень. Либо изобретать что-то своё.