Содержание одинаковых модулей в разных пакетах

← →
BFG9k © (2005-10-24 18:30) [0]

Несколько пакетов загружаются в основную программу с помощью LoadPackage. Эти пакеты содержат одинаковые модули и дельфи на это ругается. Как этого избежать ?

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

← →
clickmaker © (2005-10-24 18:36) [1]

> Не хотелось бы загонять повторяющиеся модули в отдельный
> пакет

а придецца. Смысл плодить модули? На то и пакеты, чтоб оптимизировать код

← →
BFG9k © (2005-10-24 18:40) [2]

А в чем смысл DLL и BPL вообще? Динамическая загрузка библиотек - вот что мне нужно ! То что в разных библиотеках повторяются одни и те же модули - это обычная ситуация, что в этом такого страшного ?

← →
clickmaker © (2005-10-24 18:41) [3]

> То что в разных библиотеках повторяются одни и те же модули
> - это обычная ситуация, что в этом такого страшного ?

для DLL да, но не для bpl

← →
BFG9k © (2005-10-25 12:27) [4]

В общем мне это надо обойти. Какая-нибудь директива компилятора или еще что-нибудь. Есть такое мнение, что BPL - это DLL. Значит это ограничение навязано искусственно (а если нет, то в чем причина такого подхода?). А то получается следующее :

Обе BPL используют всего один общий маленький модуль. Создавать из него одного пакет и включать его в requires - много чести.

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

← →
clickmaker © (2005-10-25 12:42) [5]

> Обе BPL используют всего один общий маленький модуль. Создавать
> из него одного пакет и включать его в requires - много чести.
>

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

← →
BFG9k © (2005-10-25 13:00) [6]

Нашел тут статью достаточно хорошую : http://www.softwarer.ru/packages.html

Правда там говорится то же самое : либо создавать другой пакет, либо переименовывать.

> достаточно, чтобы один бпл юзал этот модуль. А второй ссылался
> на первый

Используется следующий механизм:
1. Запускается основная программа.
2. С помощью FindFirst и FindNext она ищет файлы BPL в специальной директории и по очереди их подгружает с помощью LoadPackage

Поэтому bpl "не знает" будет ли он загружен первым, вторым или третьим.

Это будет известно уже при работе программы с помощью EnumModules и GetPackageInfo. Но все пакеты к этому моменту уже собраны и поздно говорить о том, чтобы один из них использовал какой-либо другой.

← →
clickmaker © (2005-10-25 13:12) [7]

> BFG9k © (25.10.05 13:00) [6]

а тебе принципиально юзать именно пакеты, а не DLL? я так понимаю, у тебя что-то типа плагинов...

← →
BFG9k © (2005-10-25 13:21) [8]

У меня что-то вроде среды Delphi - SDI. Основная форма (которая сверху) - контейнер для множества других форм. В DLL можно использовать только модальные формы (проходили), мне же нужно рабоать с экземпляром TForm (в моем случае - потомком TForm). Из DLL же я могу выудить только Handle окна и работать с формами только с помощью Api, не используя дельфи (очень неудобно да и незачем).

В общем пакеты - это то , что нужно.

Ладно, создам еще один пакет "shared", буду везде включать его в requires и подгружать первым.

← →
clickmaker © (2005-10-25 13:30) [9]

> В DLL можно использовать только модальные формы (проходили),
> мне же нужно рабоать с экземпляром TForm (в моем случае
> - потомком TForm). Из DLL же я могу выудить только Handle
> окна и работать с формами только с помощью Api, не используя
> дельфи

я юзал DLL в качестве плагинов и прекрасно работал со всеми возможностями дельфей. Пользовал фреймы, лежащие в длл, как MDI-окна. Но при этом, правда, и экзе и длл должны быть собраны с одними и теми же run-time пакетами

← →
BFG9k © (2005-10-25 13:33) [10]

Переделывать под DLL я уже ничего не буду, но ради интереса:

Ты создавал внутри DLL экземпляр TFrame, передавал его в основную программу и работал с ним ?

← →
clickmaker © (2005-10-25 13:42) [11]

> Ты создавал внутри DLL экземпляр TFrame, передавал его в
> основную программу и работал с ним ?

да, назначал ему парентом MDI-child

← →
BFG9k © (2005-10-25 14:01) [12]

Появилась одна проблема. Что если разные модули имеют одинаковые имена? Казалось бы, переименовать и все. Но как быть с условной компиляцией (IFDEF..ENDIF), когда один и тот же pas файл компилируется по разному в зависимости от того, в какой проект он включен ?

Такой уже не включишь в Shared.bpl :(

← →
Reindeer Moss Eater © (2005-10-25 14:43) [13]

Что если разные модули имеют одинаковые имена?

А вот не надо так делать и не будет проблем.
А что если вообще все модули имеют одинаковые имена?

← →
BFG9k © (2005-10-25 15:06) [14]

Ну хорошо, условная компиляция исключается ?

Почему весь свет должен видеть, какие модули я использую в bpl ? Неужели нельзя скрыть эту информацию ?

← →
Игорь Шевченко © (2005-10-25 15:22) [15]

Never attribute to malice which can be adequately explained by stupidity.

> Неужели нельзя скрыть эту информацию ?

Более того, нельзя даже скрыть приватные поля объектов в этих модулях.

Есть парвила игры, хочешь - принимай, хочешь - отказывайся.

← →
BFG9k © (2005-10-25 15:36) [16]

> Есть парвила игры, хочешь - принимай, хочешь - отказывайся.

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

← →
Игорь Шевченко © (2005-10-25 15:41) [17]

BFG9k © (25.10.05 15:36) [16]

Да просто на протяжении ветки народ пытается донести мысль, что в пакетах модули не должны пересекаться...Поэтому пытаться изменить что-либо в этом направлении можно только двумя путями - либо переименованием, либо вынесением общих модулей в дополнительный пакет (пакеты). Второе предпочтительнее.

← →
BFG9k © (2005-10-25 16:00) [18]

Это все понятно. Я ищу людей, которые сталкивались с такой проблемой и хочу узнать, не удалось ли им решить ее малой кровью.

Насчет условной компиляции. Можно ли из pas файла получить dcu с другим именем с помощью какой-нибудь директивы компилятора ?

← →
Reindeer Moss Eater © (2005-10-25 16:08) [19]

Можно ли из pas файла получить dcu с другим именем с помощью какой-нибудь директивы компилятора ?

Не надо страдать ерундой.

Допустим у меня в uses написано myunit
А dcu от него называется yourunit.

Предтавь после этого себя на месте компилятора и попробуй что - нибудь придумать мудрое.

← →
Игорь Шевченко © (2005-10-25 16:12) [20]

BFG9k © (25.10.05 16:00) [18]

> удалось ли им решить ее малой кровью

Удалось. Вынесением общих модулей в отдельный пакет. Это сделать быстрее, чем дискутировать на форуме.

← →
BFG9k © (2005-10-25 16:31) [21]

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

Представим себе такую ситуацию. Есть бызовый класс :

TAbstractForm=class(TForm)

Содержащий его модуль - один на все пакеты, его мы включаем в тот самый отдельный пакет.

Если нам нужно обращаться к формам, содержащимся в пакетах, извне - обращаемся к базовуму классу.

Сами формы представляют собой потомков базового класса:

TForm1=class(TAbstractForm)

Создание формы происходит внтури экспортируемой функции, которая возвращает в основную программу экземпляр формы:

function CreateForm(AOwner:TComponent):TAbstractForm; begin Result:=TForm1.Create(AOwner); end;

Так вот, эту экспортируемую функцию (и еще кое что) придется писать N раз в N числе практически одинаковых модулей. А если что-либо изменится, то N раз изменять. Здесь я использовал условную компиляцию, поэтому экспорт функции у меня фактически осуществляется в одном общем модуле на все N пакетов. Если бы в пакетах этот модуль бы назывался по-разному, это бы решило проблему.

← →
BFG9k © (2005-10-25 16:47) [22]

Придумал вроде. Использовать директиву компилятора {$I <имя_файла>} в N количестве PAS файлов. Эти N файлов будут по-разному называться и иметь одну и ту же основу.

> Так вот, эту экспортируемую функцию (и еще кое что) придется
> писать N раз в N числе практически одинаковых модулей.

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

TAbstractForm=class(TForm)

TClassOfAbstractForm = class of TAbstractForm;

procedure CreateAnyForm(AClass : TClassOfAbstractForm);
begin
with AClass.Create(Application) do
begin
end;
end;

Все это реализуется в одном месте общего пакета. И все дочерние пакеты создают экземпляры своих форм вызывая CreateAnyForm

Reindeer Moss Eater © (25.10.05 16:52) [24]

> procedure CreateAnyForm(AClass : TClassOfAbstractForm);

Тут уже я перестаю понимать. В пакете надо создать конкретного наследника TAbstractForm, насколько я уяснил. Каким образом может помочь такая функция (я все-таки надеюсь, что это функция, возвращающая ссылку на созданную форму, а не процедура) ?

Конструктор у TAbstractForm виртуальный.
Общий пакет в котором реализован TAbstractForm умеет создвать наследников этого класса.
Нужный тип наследника передается из пакета в котором реализован наследник.
Таким образом создается экземпляр конкретного наследника TAbstractForm.

Вынес TAbstractForm в пакет Shared.

Включил в Shared в requires остальных пакетов.

Как мне добиться того, чтобы модули этих пакетов видели тип TAbstractForm и могли создавать от него потомков ?

Add To Repository

Добавил в закладку Forms. Наследование недостпуно - только Copy. Указываешь директорию (зачем?) - ошибка : Cannot Copy a Repository Project to a directory underneath itself.

Разобрался, спасибо.

Хотя не совсем. Добавляю форму в репозиторий, создаю от нее потомка - модуль с формой включается в contains :( Как же все-таки вытащить ее из Shared , помещенной в requires ?

Содержание одинаковых модулей в разных пакетах Найти похожие ветки