> [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, причина в вилах :)