Выбор структуры приложения с использованием пакетов

← →
{RASkov} © (2008-12-01 00:00) [40]

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

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

← →
Сергей М. © (2008-12-01 00:02) [41]

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

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

Или что ?

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

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

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

← →
{RASkov} © (2008-12-01 00:07) [42]

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

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

← →
monogandhi (2008-12-01 00:11) [43]

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

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

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

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

← →
Сергей М. © (2008-12-01 00:12) [44]

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

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

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

← →
Anatoly Podgoretsky © (2008-12-01 00:14) [45]

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

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

← →
Юрий Зотов © (2008-12-01 00:20) [46]

> monogandhi (30.11.08 23:24) [28]

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

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

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

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

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

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

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

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

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

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

← →
Сергей М. © (2008-12-01 00:28) [47]

> monogandhi (01.12.08 00:11) [43]

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

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

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

← →
Юрий Зотов © (2008-12-01 00:29) [48]

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

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

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

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

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

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

← →
Сергей М. © (2008-12-01 00:30) [49]

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

Не понял ?

← →
Сергей М. © (2008-12-01 00:41) [50]

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

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

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

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

← →
Сергей М. © (2008-12-01 00:50) [51]

> {RASkov}

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

← →
{RASkov} © (2008-12-01 00:57) [52]

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

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

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

← →
{RASkov} © (2008-12-01 01:32) [53]

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

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

← →
{RASkov} © (2008-12-01 01:39) [54]

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

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

← →
Юрий Зотов © (2008-12-01 01:51) [55]

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

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

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

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

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

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

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

← →
Юрий Зотов © (2008-12-01 01:54) [56]

Добавление.

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

← →
Petr V. Abramov © (2008-12-01 01:59) [57]

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

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

← →
Германн © (2008-12-01 02:02) [58]

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

+1

← →
Petr V. Abramov © (2008-12-01 05:06) [59]

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

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

← →
{RASkov} © (2008-12-01 13:47) [60]

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

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

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

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

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

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

← →
Сергей М. © (2008-12-01 13:55) [61]

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

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

← →
{RASkov} © (2008-12-01 14:05) [62]

А вот такой еще вопрос:
Если делать с пакетами, т.е. поставить галку, то вот тот самый список БПЛок под этой самой галкой....
Вопрос по нему. Если я например в программе использую такую структуру:
APPDIR | -STNDRTBPL | -PLUGINS | -hostapp.exe
то как указать, что списпок стандартных БПЛок, т.е. сами эти библиотеки, находятся в папке ..\APPDIR\STNDRTBPL\ ?
Плагины-то грузятся динамически, поэтому там проблем нет, а....
Более того стандартные БПЛки нужны будут и в пакетах-плагинах, а там как это нужно сделать?

← →
{RASkov} © (2008-12-01 14:06) [63]

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

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

← →
{RASkov} © (2008-12-01 14:08) [64]

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

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

← →
{RASkov} © (2008-12-01 14:11) [65]

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

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

← →
AndreyV © (2008-12-01 14:12) [66]

> [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

Выбор структуры приложения с использованием пакетов Найти похожие ветки