(Кинула вопрос в конференцию начинающих, но там не ответили, помогите подсказкой, если вам не сложно).

У меня есть класс (не компонент). Подскажите, пожалуйста, примерную последовательность действий(с подробностями разберусь сама), для того, чтобы оформить его как activeX. Чтобы получался невизуальный activeX, который можно кинуть на форму и пользоваться его методами.
Пыталась использовать стандартный ActiveXControl, но он наследует от готового компонента (м.б. я недопоняла).

> Подскажите, пожалуйста, примерную последовательность действий(с
> подробностями разберусь сама)

Милая девушка, примерная последовательность занимает в MSDN с десяток немаленьких топиков, и это действительно только "примерная последовательность", без описания каких-либо тонкостей. Боюсь, что без чтения книг или внимательного изучения MSDN, используя TActiveXControl в качестве примера, Вам никак не обойтись.

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

А Вы уверены, что Вам нужен именно ActiveX? Может быть, будет достаточно обычного COM-объекта, реализующего потомка IDispatch? А чтобы кидать на форму, можно его после регистрации импортировать в Delphi стандартными средствами среды - Project/Import type library и выставить галкку Create Component wrapper.

Скорей всего, вы хотите из имеющего класса сделать компонент, а не ActiveX, потому что на форму в большинстве случаев ложатся компоненты, а не ActiveX-ы

бодаюсь примерно с такой же ситуацией

[quote]А Вы уверены, что Вам нужен именно ActiveX? Может быть, будет достаточно обычного COM-объекта, реализующего потомка IDispatch?[/quote]

сделал обычный сом-объект, тестовые примеры на делфи работают отлично как при создании обьектов руками, так и с сгенерированным компонентом-врапером

а с visual basic-ом одни траблы, кричат "дай активх, мы его положим на форму и не будем гемороится"

и вот как сделать невизуальный активХ? показывать то нечего

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

на делфи все просто - создал базовый объект, загрузил в него настройки исходного файла, потом QueryInterface с IID нужного интерфейса, заполнил где надо свойства и сделал Make - "та-дам!" все класс

при этом интерфейсов конвертации много, так что я переопределяю QueryInterface и для нужных IID создаю обьекты, реализующие эти интерфейсы

а в этом *** vb все ж не как у людей - в мою QueryInterface никогда управление не попадает и vb ругается, что не найден интерфейс

вот они и плачут, просют активХ...

i_hate_vb   (16.02.07 13:07) [3] Опять ты? :)
Зачем тебе для каждой конвертации свой интерфейс? Интерфейс должен быть один, а коклассов - для кадой конвертации свой.
По поздему связыванию доступен только один интерфейс, default.

> Опять ты? :)

угу :)

пожалуюсь - "зачем":

конвертируем файл в че-то; при этом у этой задачи есть настрйоки:
1) имя исходного файла
2) свойства файла (read only), читаются после загрузки п. 1

3) папка, куда ложить результ
4) имя файла, который получится
5) диапазон кадров для обработки (с/по)

6) заголовок окна
7) размер окна
8) что-то-еще

конвертируем файл в что-то другое; у этой задачи настройки такие
1) имя исходного файла
2) свойства файла (read only), читаются после загрузки п. 1

3) папка, куда ложить результ
4) имя файла, который получится
5) диапазон кадров для обработки (с/по)

6) кодек для видео
7) кодек для аудио
8) битрейцт видео
9) что-то еще

получается, что мне для первого случая нужно описать интерфейс, который полностью описывает пункты 1-8 первого прмиера, для второго случая - интерфейс, который полностью описывает пункты 1-9 второго примера, при этом ведь п. 1-2, 3-5 совпадают, все свойства по идее часто можно оставлять "как есть"

так что я сделал кучку интерфейсов "по темам":
пункты 1-2:
ISourceReader
 source_filename: string;
 frames: integer;
 width: integer;
 height: integer;
end;

пункты 3-5:
ITaskProps
 dest_folder: string;
 dest_name: string;
 frame_from: integer;
 frame_to: integer;
end;

все конверторы имеют общего предка
IBaseBuilder
 make;
end;

конвертация в ехе
IEXEMaker = interface (IBaseBuilder)
 caption: string;
 size: size_enum;
end;

конвертация в видео
IVideoMaker = interface (IBaseBuilder)
 video_codec: string;
 video_butrate: integer;
 audio_codec: string;
 audio_bitrate: integer;
end;

плюс интерфейс для событий
IBaseBuilderEvents
 on_video
 on_error
 on_succ
end;

делаю кокласс для конвертации в ехе - реализует интерфейсы ISourceReader (default), IBuilderEvents (source, default), ITaskProps, IExeMaker

В реализации сделал класс
 TSourceReaderAX = class(TActiveXControl, ISourceReader, ITaskProps)

от него хочу наследовать все конверторы... и все ж отлично работает, если б не этот *** vb

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

Ты не учитываешь, что интерфейсы также можно наследовать друг от друга.
Тебя же не удивляет, что TAutoObject реализует и IDispatch, и интерфейс-потомок от него ;)

да так и сделаю, понаследую их друг за другом...

просто "идеологически" оно не очень красиво - не родственники они! ;)

Если не родственники - сделай основной объект, который через методы/свойства выдает нужный интерфейс. Тип свойства - IDispatch, а выдаваться будет конкретный заказанный интерфейс.
Так, например, сделан метод Add у книги Excel - добавить-то можно разные вещи, не только лист. Выдает IDispatch.