Есть некоторый класс

При инициализации модуля нужно зарегистрировать этот класс. Проблема в том, что для процедуры RegisterClass требуется TPersistenClass или его потомки...... 
Какие есть решения??
Help!

Зачем?


Смотря какой задачи.


А вы знаете, зачем нужна RegisterClass?

Напрашивается решение 


но должны быть и другие решения (имхо);

Добавлено через 4 минуты и 24 секунды
Это модуль из пакета. Поэтому приходится прописывать в разделе инициализации регистрацию класса. 



Признаюсь - смутно представляю....  хотя суть, имхо, очевидна.


Нужно зарегистрировать TMyCkass))

Почеееемууу?


Зачеееем?

RegisterClass регистрирует класс для системы персистентности Delphi. Зарегистрированный класс можно сохранять в поток и загружать из него вызовами TStream.WriteComponent/ReadComponent.

Что значит зарегистрировать класс, не являющийся потомком TPersistent? В контексте RegisterClass эта операция лишена смысла.

Аналогия: в дверной косяк вставляются двери. 

Вы говорите: При инициализации модуля нужно вставить в косяк окно. Проблема в том, что в дверной косяк можно вставить только дверь. 
Какие есть решения??

Я: зачем вы хотите вставить в дверной косяк окно? В дверной косяк можно вставить только дверь. Поэтому либо берите дверь, либо используйте оконный проём.

Вы снова: Напрашивается решение - использовать для дверного косяка дверь. Но должны быть и другие решения (имхо);
Это модуль из пакета. Поэтому приходится вставлять окно. 
Признаюсь - смутно представляю, для чего нужен дверной косяк....  хотя суть, имхо, очевидна.
Нужно вставить окно в дверной косяк )))

Ясна аналогия? Поэтому скажите, что вам нужно - так и ответ будет корректнее.

вот здесь хорошо описана Ваша проблема http://gunsmoker.blogspot.com/2008/10/x-y-z.html

CodeMonkey, спс за ответ)) ценю чувство юмора. Нелепость желаемого мною - теперь очевидна.
Теперь по порядку.
В пакете bpl реализовывается несколько функций (подробнее по вызову различных сообщений). Почему пакет bpl?.... примем как нечто свыше.
Далее программист в своей программе предусматривает загрузку пакета и радостно пользуется готовыми сообщниями.
Сообщения реализованы как четрые формы, соответсвенно, четыре отдельных модуля. Есть модуль, в котором реализуется простейший класс, поддерживающий некоторый интерфейс (например IMyInterface), чтобы программист мог работать с пакетом. Этот модуль подключает те четрые с формами, вызывает при необходимости нужный месседж. В нем же есть класс (т.е. тот класс который будет обрабатывать запросы от приложения и командовать выводом сообщений, т.е. тупо посредник.

В программе нам нужно лишь проверить
GetClass('TMyClass') и поддержку интерфейса.

Вот я и подумал, зачем мне чего-то мудрить с другими классами, если достаточно TObject для реализации задуманного. 

вот такая вот несложная задача. Просто не хотелось базировать свой на TPersisten.

Добавлено через 8 минут и 2 секунды
Если вы считаете, что ошибка была еще раньше, например при выборе конкретной реализации (имею ввиду интерфейсы). То предложите другой способ общения приложения с пакетом.
Класс с абстрактными методами не катит, ибо с наследованием и изменением функциональности больше проблем, чем при использовании интерфейсов. 

Это сообщение отредактировал(а) Avers - 4.12.2008, 12:49

Что-то я не до конца понял.


Вот это можете пояснить? Зачем это нужно делать в программе? 

Можете подробнее рассказать? Я так и не понял, что из этого у вас лежит в пакете, что - вне его. Откуда главная программа возьмёт класс или интерфейс (и что она вообще должна брать)?

Реализуется несложное взаимодействие.
Есть некоторое Приложение и есть неокторая Форма. По некоторым причинам нужно отделить Форму от Приложения. Упаковываем Форму в пакет bpl.
Пакет:
модуль формы содержит форму и некоторую функцию ShowForm. 
модуль Main использует модуль формы и содержит класс (MyClass), управляющий формой (точнее - класс юзает ShowForm). Класс создается, поскольку форм может быть несколько.... короч, так удобнее (мне лично удобнее и разобраться проще и код править проще).

Теперь связываем Приложение и Пакет.
Для этого пишем интерфейс (Объект - реальзизация = объявление функции ShowForm).

Интерфес поддерфивает MyClass и об этом интерфейсе "знает" Приложение.
Таким образом мы получаем свободу при реализации Формы.

Теперь из программы управляем формой через специально написанный интерфейс, а точнее - запускаем процедуру ShowForm=)))) Для этого:
обявляем некоторый объект, загружаем класс из пакета и создаем объект.
Если бы 

то

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

Конкретно

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

если что-то излишне подробно описал - звиняйте) боялся пропустить че-нить важное)
Если Вы тоже используете пакеты, поделитесь опытом, буду рад)

Брррр...
Если вы уж используете интерфейсы - то и передавайте между bpl и exe именно IMyInterface! Зачем вы передаёте класс? Класс - это же реализация. Насколько я понимаю, идеология такая: нужно передавать интерфейс, но не реализацию.

Я, конечно, хз, но сделал бы как-то так:

Пакет:

Unit2 - интерфейс:


Unit3 - реализация:


Unit4 - получение экземпляра (может быть объединён с Unit2):


Приложение:

Unit1 - использование интерфейса:


Но если вам уж очень сильно охота, то наследуйте свой класс от TPersistent. Почему у вас ограничение в TObject?

P.S. Если бы вы изначально задали вопрос именно вот так вот развёрнуто, то вам бы сразу дали ответ по теме, а не мусолили его несколько дней.

Тоже, наверно, вариант (передавать только интерфейс). Надо попробовать.... Пользуюсь наиболее подходящим методом (из всех найденых на просторах интернета), позволяющим связать  Bpl и Приложение.
....


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

Если использовать в программе Unit4, который в свою оцередь использует Unit2 и Unit3, то смысл наличия пакета теряется (имхо).

Вас смущает необходимость наличия Unit3? Ну так сделайте ссылку косвенно, например:





Хотя тогда уж проще использовать ручную загрузку пакета:

Unit2 - интерфейс (пакет и exe):


Unit3 - реализация (пакет):


Unit1 - использование интерфейса:


Тока что-то это уже совсем-совсем плагины начинает напоминать.

 Вот-вот. В этом вся суть

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

Спасибо) Предолженный вариант с передачей только интерфейса - замечатльно работает.
Даже немного обидно. Когда искал в инете статьи и искходники на эту тему подобного нашлось.... 

Это сообщение отредактировал(а) Avers - 10.12.2008, 13:06