Будьте добры, подскажите пожалуйста как лучше осуществить вот какую задумку:

Хочу попробывать научится использовать пакеты(BPL) в приложениях.
На сей момент задумка такая. Есть программа(exe)-загрузчик. Из себя представляет обычное приложение по умолчанию в делфи.
Т.е. одна главная форма, на ней.... (вот тут вопросик что лучше?) Я пока остановился на TTabControl. Как вариант TPageControl или.... ??
Суть такая: Форма, вверху закладки, так вот содержимое закладок должно быть в bpl'ках...

Все это должно быть в динамике, добавили bpl в папку с плагинами, появилась новая закладка при следующем старте программы-загрущика...
т.е. при старте приложения-загрузчика просматриваются файлы bpl и если пакет содежит "вкладку" (тут тоже вопрос), то добавить в
TabControl1.Tabs.Add(имя вкладки из пакета).... так вот вопрос что лучше в пакете использовать.... Я пока остановился на TFrame...

Вообщем у меня пока дуратское сообщение о том, что TFont не совместим c TFont.... :) Это мне уже знакомо, думаю разберусь, но вот подскажите вообще идеи по данной задумке.

> у меня пока дуратское сообщение о том, что TFont не совместим
> c TFont.... :) Это мне уже знакомо


Притча о граблях)


> подскажите вообще идеи по данной задумке


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

Пакеты - это просто #%!@#%^#@#$! какой-то. Неужели для того, чтобы использовать собственного потомка некоторого визуального компонента мне нужно оформлять его в виде отдельного пакета, отдельно компилировать и прочая и прочая?
Это же морока какая и умножение сущностей без всякой меры.

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


Нет.


> отдельно компилировать


Да. А как же без компиляции ? Без нее никуда)


> и прочая и прочая


В Коране об этом ничего не сказано)

Сергей М. ©   (30.11.08 22:25) [3]

А разъясните, пожалуйста, тогда как. Я пробовал просто отнаследовать и в dfm имя подменить, мне сказали чтобы больше так не делал. Пришлось делать пакет.

monogandhi   (30.11.08 22:27) [4]

Имеется в виду, среда ругалась на сие непотребство.

> [1] Сергей М. ©   (30.11.08 22:07)

Т.е. так и оставить (TTabControl в программе) и (TFrame в пакете) ?

>>>>
И если можно, коротко о граблях, пожалуйста... хотя бы о "TFont не совместим c TFont"
т.е. как правильно создать в пакете фрэйм, и как его поместить на TTabControl...?


> [2] monogandhi   (30.11.08 22:22)
> Пакеты - это просто #%!@#%^#@#$! какой-то.

Зря ты так.... я тоже раньше был такого же мнения, но... :)

A причем здесь dfm ?
Компоненты не нуждаются ни в каких dfm'ах - они прекрасно рождаются существуют сами по себе.

Сергей М. ©   (30.11.08 22:30) [7]

Вы что-то все уклончиво говорите. В [2] говорилось о потомке некоего визуального компонента из некой сторонней библиотеки (то есть стороннего пакета, который уже был установлен). Он присутствовал на форме, то есть инстанциировался средой. Насколько я понимаю, для этого нужно указывать его тип. Этого как раз и не удалось сделать.

> {RASkov} ©   (30.11.08 22:29) [6]


exe должен быть собран с опцией использования ран-тайм пакетов - вот и вся премудрость граблей

> В [2] говорилось о потомке некоего визуального компонента
> из некой сторонней библиотеки (то есть стороннего пакета,
>  который уже был установлен). Он присутствовал на форме,
>  то есть инстанциировался средой.


В [2] об этом нет ни слова, не надо выдумывать задним числом.

Сергей М. ©   (30.11.08 22:39) [10]

Цитирую себя же, простите.

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

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

Повторяю эту цитату:


> использовать собственного потомка некоторого визуального
> компонента


Для этого достаточно объявить и реализовать наследника этого компонента. Где он будет объявлен, реализован и использован - об этом речь не шла. Равно как не шла речь и конкретно о дизайн-тайм.

> [9] Сергей М. ©   (30.11.08 22:37)

так... но тогда тут получается EXEшник маленького размера, т.е. нужно будет все библиотеки VCL прикладывать к екзе....
А как сделать так, чтоб экзешнику не требовались никае внешние(VCL) БПЛ....?

> его нужно инстанциировать динамически без всякого упоминания
> в форме?


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

Сергей М. ©   (30.11.08 22:47) [12]

Речь шла о том, нужно ли для этого делать пакет. Насколько я могу понять из ваших слов: "Для этого достаточно объявить и реализовать наследника этого компонента", то пакета создавать не нужно.
Если под объявлением и реализацией наследника вы подразумеваете создание соответствующего класса-потомка, то у меня так не получилось сделать.
Без создания пакета, он не появится на вкладках с компонентами. А замена имени его предка в форме вызывает маловразумительное сообщение дельфи о том, что вот этого имени тут-то не должно быть, и не удалить ли его?
Выходит, что пакет создавать таки нужно. А вы говорите что не нужно. Мне кажется, что где-то здесь есть противоречие.

> {RASkov} ©   (30.11.08 22:51) [13]


> тут получается EXEшник маленького размера, т.е. нужно будет
> все библиотеки VCL прикладывать к екзе


И что этому мешает ?


> как сделать так, чтоб экзешнику не требовались никае внешние(VCL)
> БПЛ....?


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

Сергей М. ©   (30.11.08 22:51) [14]

Можно ли это сделать, не создавая пакет, и если да, то как?

> [16] Сергей М. ©   (30.11.08 22:54)
> [13] {RASkov} ©   (30.11.08 22:51)

если я ставлю данную галку и очищаю строку со списком бплок, то галка снимается.... и опять тажа ошибка :(
можно конечно оставить какой-нибудь пакет и его дополнительно положить в папку с программой.... например специально для этих целей подготовленную...
Но так не верно наверное, или как? :)


> И что этому мешает ?

Ну, не.... я так не расчитывал :)

> [18] {RASkov} ©   (30.11.08 22:57)

т.е. там под галкой есть строка со списком бпл... вот там можно оставить одну какую-нибудь и положить ее к программе в папку...

> monogandhi   (30.11.08 22:53) [15]
>
> Сергей М. ©   (30.11.08 22:47) [12]
>
> Речь шла о том, нужно ли для этого делать пакет


Пакет нужен, прежде всего, в дизайн-тайм, коль речь зашла о dfm.


> Без создания пакета, он не появится на вкладках с компонентами


> Выходит, что пакет создавать таки нужно. А вы говорите что
> не нужно


А у тебя что, язык не поворачивается сказать, что речь изначально идет о дизайн-тайм ?

Для дизайн-тайм пакет обязателен, для ран-тайм не обязателен.

> monogandhi

Что мне тут все портишь??? :)
Заведи себе свою ветку )))

Сергей М. ©   (30.11.08 22:58) [20]

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

{RASkov} ©   (30.11.08 23:02) [21]

Прошу меня извинить, измучался просто с этим весь.

> {RASkov} ©   (30.11.08 22:57) [18]


> ставлю данную галку и очищаю строку со списком бплок


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


> можно оставить одну какую-нибудь и положить ее к программе
> в папку


Тебе что, все равно какую ?)

> два раза я обращал ваше внимание на то, что компонент визуальный


И что ?

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

Сергей М. ©   (30.11.08 23:05) [24]

Да, я уже высказал свою догадку об этом в [11], не пытайтесь защищаться, ваша позиция видна насквозь.
В моем случае проще морочиться с пакетом. Но не будем же побивать друг друга словесами неприличными. Мира, добра и счастья вам.

> [23] Сергей М. ©   (30.11.08 23:03)
> А зачем ты ее чистишь всю ?

Хотел, чтоб стандартные прилинковались к экзе, и все былоб как обычно.... и только мои БПЛки подгружались бы динамично.... если имеются.
не к чему таскать все стандартные пакеты.... я так не планировал :(


> Тебе что, все равно какую ?)

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

Вопрос:
если эту галку [9] не ставить то никак не избавится от этих граблей, например о которых я указал в [0](TFont)?

> В моем случае проще морочиться с пакетом


Что это за "твой случай" такой ?
Ты для кого все это затеял - для себя лично или для будущих сторонних разработчиков-пользователей своего компонента ?

Сергей М. ©   (30.11.08 23:19) [27]

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

> {RASkov} ©   (30.11.08 23:16) [26]



> ставил только последнюю из того списка dclOfficeXP


Любая прикладная bpl, поскольку она безусловно собирается с ран-тайм пакетами, использует стандартные bpl, которые автоматически подключаются к проекту, использующему эту прикладную bpl.
Как минимум это rtl и vcl.

В противном случае нафих нужны такие пакеты, если они будут дублированы в АП процесса ?

> Наиболее просто это можно сделать, создав потомка


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


> для Дельфи это стандартная практика?


Да.


> проект начинает размазываться по пакетам


Не понимаю, почему тебя это так сильно заботит ..

> monogandhi


я надеюсь, ты в курсе, что собранный проект может не использовать bpl ?
Тогда о каком "размазывании" идет речь ?

Сергей М. ©   (30.11.08 23:34) [31]

Нет, об этом я ничего не знаю. Что значит "собранный проект"?
К сожалению, структуру проекта (за исключением добавления новых проектов в группу) я изменять не могу.

> Пакеты - это просто #%!@#%^#@#$! какой-то


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

> [29] Сергей М. ©   (30.11.08 23:26)
> В противном случае нафих нужны такие пакеты, если они будут
> дублированы в АП процесса ?

Зачем? Я расчитывал, что Екзе соберется как обычно со всеми необходимыми библиотеками, а вот плагины, в виде пакетов, подгружались бы при необходимости и наличии в папке с палагинами....
Ведь с dll это еще сложнее... Т.е. пакетами хотел заменить DLL, но тут опять не все гладко :)
Что-то тут не так...

> Что значит "собранный проект"?


Результ сборки проекта - это модуль, содержащий как минимум исполняемый код, реализующий требуемую проектом функциональность.
В зависимости от типа Win-проекта результатом м.б. EXE- или BPL- или DLL-модуль.


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


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

> {RASkov} ©   (30.11.08 23:39) [34]


> пакетами хотел заменить DLL


И правильно !


> Екзе соберется как обычно со всеми необходимыми библиотеками


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


> плагины, в виде пакетов, подгружались бы при необходимости


Кем подгружались-то ?
И что этому мешает ?

> Зачем? Я расчитывал, что Екзе соберется как обычно со всеми
> необходимыми библиотеками, а вот плагины, в виде пакетов,
>  подгружались бы при необходимости и наличии в папке с палагинами.
> ...

а плагины библиотеки не используют? раз TFont испльзуется, то используют.
и будет у тебя столько вариантов класса TFont, сколько плагинов. и при достижении какого-то (небольшого, зависящего от кол-во используемых классов) числа пакетов таскать vcl-bpl станет просто выгодней

Сергей М. ©   (30.11.08 23:44) [35]

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

> [36] Сергей М. ©   (30.11.08 23:47)

> [37] Petr V. Abramov ©   (30.11.08 23:48)

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

Или "в ручки" по всем uses пройтись и составить список пакетов? :) Что-то мне все меньше и меньше нравится эта идея с пакетами :( ...а куда деваться... :)

> [37] Petr V. Abramov ©   (30.11.08 23:48)
> а плагины библиотеки не используют? раз TFont испльзуется,
> то используют.

в плагинах TFrame с контролами и функционалом....

> мороке при установке пакетов другими разработчиками при
> добавлении пакетов кем-либо из них


В чем заключается морока ?
В неумении и/или нежелании грамотно создать dpk-проект, собрать его и включить в инсталл.дистрибутив все требуемые модули ?

Или что ?

Мне непонятно, хоть убей)


> иные среды разработки лишены этого недостатка


С этого момента максимально подробно, с аргументами ...

> > а плагины библиотеки не используют? раз TFont испльзуется, то используют.

Ааааййййй.... кажется въезжаю я в эту всю петрушку.... т.е. vcl.bpl, rtl.bpl как пить дать нужно с программой таскать... а остальное зависит от наполнения фреймов....
Хм... тогда получится, что стандартные пакеты по сути нужны плагинам, так как в программе-загрузчике практически ничего нет, а все контролы находятся на фрэймах в пакетах.... т.е. получится, что при добавлении очередного пакета(плагина) он по возможности подтянет(не сам конечно, а я в ручную) еще пакетик другой в папку с программой.... так я понял эту кашу?

Сергей М. ©   (01.12.08 00:02) [41]

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

>С этого момента максимально подробно, с аргументами ...

В MSVS можно отнаследовать от класса обертки, имея дизайн-тайм свойства базового компонента.

> {RASkov} ©   (30.11.08 23:59) [39]


Статические зависимости определяются любым PE-вьюером.
Простейший входит в поставку Делфи и назфвается tdump.exe
Можно и проще - запустить под встр.отладчиком приложение и вызвать меню среды View -> Debug Windows -> Modules

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

> Сергей М.  (30.11.2008 22:30:07)  [7]

А без компиляции?

> monogandhi   (30.11.08 23:24) [28]

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

Нет проблем, создавайте на здоровье.

> Однако при этом, проект начинает размазываться по пакетам...
> Насколько я понимаю, для Дельфи это стандартная практика?

Если Вы хотите, чтобы Ваш компонент появился в палитре IDE, то он обязан быть помещен в пакет и зарегистрирован, а пакет инсталлирован в IDE (иначе откуда же Ваш компонент в IDE возьмется?). Ну а если появление Вашего компонента в палитре IDE необязательно, то и помещать его в пакет тоже необязательно, можете создавать потомка прямо в программе.

===================================================

Только почему "размазываться"? Например, практически любая сишная программа (включая и саму систему) использует кучу DLL и этому никто не удивляется. И никто не говорит, что программа "размазывается по DLL".

А пакеты Delphi - это те же DLL. И стратегия их использования такая же - в пакет помещается код, который либо используется более, чем в одном проекте (библиотеки), либо расширяет функционал приложения (плагины).

И если код по своему смыслу не должен быть помещен в пакет, то никто и не заставляет его туда помещать.

Так что - никакого размазывания. Размазывание наступает не от того, что без него нельзя, а оттого, что недостаточное понимание Delphi не позволяет грамотно спроектировать структуру программы.

А Ваш совет тренировать телепатор - он, конечно, полезен. Но еще полезнее учить матчасть. Тогда и телепаторы не понадобятся.

> monogandhi   (01.12.08 00:11) [43]


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


> В MSVS можно отнаследовать от класса обертки


Это не аргумент.
Там, мягко говоря, несколько иная концепция и идеология механизма виз.проектирования

> {RASkov} ©   (01.12.08 00:07) [42]

> так я понял эту кашу?

1. Для того, чтобы какой-то кусок кода заработал, он должен быть загружен.

2. Чтобы он был загружен, его надо откуда-то взять.

3. Если EXE (или плагин) скомпилирован с пакетами, то в этом EXE (или плагине), код этих пакетов ОТСУТСТВУЕТ.

4. Значит, все внешние пакеты, которые использует EXE (или плагин)  ОБЯЗАНЫ поставляться вместе с этим EXE (или плагином). Иначе неоткуда будет взять их код.

> Anatoly Podgoretsky ©   (01.12.08 00:14) [45]
> А без компиляции?
>


Не понял ?

> {RASkov} ©   (01.12.08 00:07) [42]


> в программе-загрузчике практически ничего нет


Ну как же нет, если ты только что получил граблями ?)

TFont есть ?
Есть.
Этот класс же не с Луны в программу-загрузчик свалился, а был собственноручно тобой, если угодно, "вкомпилирован" в исп.модуль программы-загрузчика, поскольку ты снял галку.

> {RASkov}


Если ты взводишь в проекте приложения-загрузчика (его правильнее и удобнее называть хост-приложение) галку ран-тайм пакетов, то хост-приложение будет использвать класс TFont в составе загружаемого им станд.пакета vcl.
Этот же пакет требуется пакету твоего плагина, поскольку там тоже фигурирует класс TFont.
При загрузке хост-приложением твоего пакета-плагина сист.загрузчик определит, что модуль стандартного vcl-пакета уже загружен в АП процесса хост-приложения, и с этого момента оба модуля - модуль хост-приложения и модуль твоего пакета-плагина - будут использовать один и тот же экз-р станд.пакета vcl, а значит один и тот же класс TFont.

> [50] Сергей М. ©   (01.12.08 00:41)

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

Я так понял, в такой структуре нужно еще следить за уникальностью имен модулей... т.е. при написании нового плугина для программы нужно помнить какие были имена раньше....
Словил ошибку о использовании Unit1 в другом пакете.... забыл скопировать дословно, это я чтоб много не писать скопировал один пакет и сделал как бы второй плагин....
Я не пишу чего-то серьезного, просто пытаюсь понять эту "пакетную плугонизацию")
http://slil.ru/26386702 - вот примерно о чем я тут. В папке Loader ProjectGroup1.bpg...
Нет проверок на исключения, но не в этом сейчас вопрос)

Может есть предложения как сделать нечто похожее из примера в [52], но более грамотнее...
Я расчитывал, что с плагинами в виде пакетов, будет гораздо проще, чем оказалось...
Не, я конечно не против, все стандартные БПЛки вгрузить в директорию с хост-приложением, но как-то это не... незнаю как подобрать сюда выражение.

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

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

А с другой стороны и альтернатив-то вроде и не остается..... если только ДЛЛ...
Может быть я и не гонюсь за размерами приложения в целом.... т.е. пусть дублируются классы(куски кода).
Главное - удобство написания нового плагина... и самое главное(тут минус у длл) - простота его подключения к хост-приложению(тут вроде бы плюс у BPL, хотя...)...
Соб-сно подключение - это добавление новой вкладки со своими контролами и своим функционалом, ничем не зависящем от других плагинов...

> {RASkov} ©   (01.12.08 01:32) [53]

> Не, я конечно не против, все стандартные БПЛки вгрузить в директорию с
> хост-приложением, но как-то это не... незнаю как подобрать сюда
> выражение.

А что в этом странного? Вы же не удивляетесь куче DLL, почему же куче BPL надо удивляться? Это одно и то же.

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

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

Если же второе, то есть смысл не ограничивать плагинописателей рамками Delphi, а дать им возможность работать на любом языке - но тогда плагины должны быть выполнены в виде DLL и смысл использования BPL пропадает.

Конечно, существует еще и COM, но это отдельный разговор.

Добавление.

Если же разработчик принимает решение, что плагины должны писаться только на Delphi определенной версии, то BPL будет однозначно проще и удобнее.

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

не помню, занимался этим 5 лет назад, как-то можно, завтра вспомню - расскажу.

> Сергей М. ©   (30.11.08 22:07) [1]
>
>
> > у меня пока дуратское сообщение о том, что TFont не совместим
> > c TFont.... :) Это мне уже знакомо
>
>
> Притча о граблях)
>
>

+1

> Германн ©   (01.12.08 02:02) [58]

-2, причина в вилах :)

> [55] Юрий Зотов ©   (01.12.08 01:51)
> А что в этом странного?

Да ну не то что бы странно, а просто некое небольшое неудобство добавилось...
...с поиском нужных, для конкретного приложения и текущего набора плагинов, стандартных BPL.
Или действительно их ВСЕ нужно положить рядом с программой?


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


Да конечно я один буду писать, хотя не уверен на 100%, ибо программку делаю для себя....
я всегда и все делаю для себя и никому не даю потом :) шутка, но только в этой строке.
Спасибо, Юрий, в общем остановлюсь я на БПЛ, наверное, все проще.
Вот еще бы было замечательно...

> [57] Petr V. Abramov ©   (01.12.08 01:59)

Не вспомнил? :)

> действительно их ВСЕ нужно положить рядом с программой?


Их можно положить куда угодно - лишь бы система знала где их искать.

А вот такой еще вопрос:
Если делать с пакетами, т.е. поставить галку, то вот тот самый список БПЛок под этой самой галкой....
Вопрос по нему. Если я например в программе использую такую структуру:


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

> [61] Сергей М. ©   (01.12.08 13:55)

Сорри.... не обновил перед отправкой....

> [61] Сергей М. ©   (01.12.08 13:55)

т.е. мне, для моего нового приложения, которое, не инсталируется и (пере)носится на флэшке, нужно будет при запуске править переменную PATH?

> [61] Сергей М. ©   (01.12.08 13:55)
> > действительно их ВСЕ нужно положить рядом с программой?

В прочем в данной строке вопрос был не о путях, а о кол-ве ("ВСЕ") :)

> [64] {RASkov} ©   (01.12.08 14:08)

Windows найдёт рядом с exe, туда и положи.

> мне, для моего нового приложения, которое, не инсталируется..нужно будет при запуске править переменную PATH?


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

> вот тот самый список БПЛок под этой самой галкой


> Плагины-то грузятся динамически


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

> [67] Сергей М. ©   (01.12.08 14:13)
> Зачем ?

Ну как зачем? Неужели мне все в кучу свалить? :) Я то хотел порядок.... т.е. нечто как в [62]...
Переменная PATH есть же для конретного процесса и существыует вместе с ним.... или я путаюсь?)

> Windows найдёт рядом с exe, туда и положи.

Это понятно, я там в примере по ссылке в [52] именно на этом и сыграл - поиск и загрузку бплок....
Но это просто демка, пробник, а уже потом хочется структоризовать каталог с программой..

> Неужели мне все в кучу свалить?


В кучу не надо.

Пакеты общесистемного и общеприкладного назначения клади в %WINDOWS%\SYSTEM - там им и место.

В кр.случае организуй для них отдельную директорию (а-ля C:\Program Files\Common Files\Borland Shared\Common Packages) и пропиши ее в PATH

А плагины свои кидай прямо в свою стартовую директорию - кроме твоего хост-приложения они никому более нафих не нужны.

> хочется структоризовать каталог с программой


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

> {RASkov}

Пакеты - это те же DLL, и правила поиска у них те же. Посмотрите справку по LoadLibrary, там четко указано, где, как и в каком порядке система ищет библиотеки. Для BPL можно использовать любое хранилище, лишь бы система смогла их найти по одному из этих правил.

Кроме того, сами плагины Вы, видимо, будете грузить вызовом LoadPackage - а там можно напрямую указать путь к загружаемому BPL, без всяких поисков.

> [71] Сергей М. ©   (01.12.08 14:33)
> Пакеты общесистемного и общеприкладного назначения клади
> в %WINDOWS%\SYSTEM - там им и место

Говорил же вроде.... Я на флэшке буду таскать программу и нее же запускать....
мне что, на каждый комп, в который втыкнится моя флэшка, "выгружать" стандартный набор БПЛок? :)


> [72] Сергей М. ©   (01.12.08 14:36)


> [73] Юрий Зотов ©   (01.12.08 14:36)

Да это понятно с плагинами, я про стандартные, которые статично грузятся.... если я хочу их держать не с екзешником, а в спец папке для стандартных пакетов...
то как указать, что списпок стандартных БПЛок, т.е. сами эти библиотеки, находятся в папке ..\APPDIR\STNDRTBPL\ ?
Плагины-то грузятся динамически, поэтому там проблем нет, а....
Более того стандартные БПЛки нужны будут и в пакетах-плагинах, а там как это нужно сделать?

> {RASkov} ©   (01.12.08 14:05) [62]
> APPDIR
>     |
>     -STNDRTBPL
>     |
>     -PLUGINS
>     |
>     -hostapp.exe

Можно взять пример с MS:

APPDIR
    |
    -BIN
        |
        -PLUGINS
        |
        -hostapp.exe
        -module1.bpl
        -module2.bpl

> [71] Сергей М. ©   (01.12.08 14:33)
> В кучу не надо.
> Пакеты общесистемного и общеприкладного назначения клади
> в %WINDOWS%\SYSTEM - там им и место.

Я понял, что автор не хочет оставлять что-либо в системе.

> приложения, которое, не инсталируется и (пере)носится на
> флэшке

> [75] KSergey ©   (01.12.08 14:46)

Хм... точно, что-то я разгорячился с этими плагимнами-пакетами...
Наверно, нечто такую структуру:

> APPDIR
>    |
>    -BIN
>        |
>        -PLUGINS
>        |
>        -hostapp.exe
>        -module1.bpl
>        -module2.bpl

и использую. Только вопрос:

Плугины, находящиеся в папке незнакомой системе, нормально увидят стандартные пакеты или всем этим делом все равно рулит хост приложение?
т.е. компоненты VCL находящиеся в моих плагинах и в отдельной папке нормально загрузятся из стандартных пакетов лежащих в другом месте, нежели пакеты-плугины.

APPDIR
 |
 -hostapp.exe
 -rtl.bpl
 -vcl.bpl
 -plugincore.bpl
 -PLUGINS
   |
   -Plug1.bpl
   -Plug2.bpl
rtl, vcl и plugincore грузятся статически +
Приложение должно уметь загрузиться без плагинов...
а уже по ходу дела ручками подгружаешь \PLUGINS\*.bpl (LoadPackage): эти плагины при загрузке регистрируют себя в plugincore и хост приложение общается только с plugincore