Midi окна из dll дайте направление движения

← →
206196131 © (2008-01-06 22:31) [0]

в DLL у меня по сути самодостаточный проект.
Набор и названия функций которые вызывает родительская форма из DLL строго определен. Каким образом можно сделать что то на подобии динамического подключения новых dll при этом не меня кода родительского проекта
Сейчас что то типа
var X1: TForm; begin FLib1 := LoadLibrary(PChar("mdidll0.dll")); @InitPlugin1 := GetProcAddress(FLib1, PChar("InitPlugin")); @DonePlugin1 := GetProcAddress(FLib1, PChar("DonePlugin")); @CreateMDI1 := GetProcAddress(FLib1, PChar("CreateMDI")); InitPlugin1(integer(Application), integer(Screen)); X1 := TForm(CreateMDI1); end;
используется для загрузки плагина

← →
Leonid Troyanovsky © (2008-01-07 05:07) [1]

> 206196131 © (06.01.08 22:31)

> в DLL у меня по сути самодостаточный проект.

http://www.podgoretsky.com/DM/BadTips.html#BT-03

Ну, а если он, дейс-но, самодостаточный, пускай его rundll32.exe

--
Regards, LVT.

← →
206196131 © (2008-01-07 22:02) [2]

http://www.podgoretsky.com/DM/BadTips.html#BT-03

это к чему что тоне совсем понял ?

← →
Германн © (2008-01-07 22:08) [3]

> http://www.podgoretsky.com/DM/BadTips.html#BT-03
>
> это к чему что тоне совсем понял ?
>

К навязчивому желанию запихивать формы в dll.

← →
{RASkov} © (2008-01-07 22:21) [4]

> это к чему что тоне совсем понял ?

> [3] Германн © (07.01.08 22:08)

Просто он читал невнимательно :)

← →
206196131 © (2008-01-07 22:48) [5]

> К навязчивому желанию запихивать формы в dll

а с чего вы взяли что это есть плохо )) аргументируйте и предложите альтернативу.
для ситуации когда есть проект который периодически нужно дополнять новыми возможностями но при этом не затрагивать то что у же есть

← →
Sergey Masloff (2008-01-07 23:01) [6]

206196131 © (07.01.08 22:48) [5]
>а с чего вы взяли что это есть плохо ))
Это общеизвестно. Как и альтернативы. В тысячастопятьдесятпервый раз аргументировать уже как-то не тянет

← →
Anatoly Podgoretsky © (2008-01-07 23:06) [7]

> 206196131 (07.01.2008 22:48:05) [5]

А нафига тебе альтернатива, ты уже все решил.
Верующих переубеждать бесполезно.

← →
206196131 © (2008-01-07 23:08) [8]

> В тысячастопятьдесятпервый раз аргументировать уже как-то
> не тянет

ну как обычно орать) ацтой, это всем 100 лет назад известно ))

зачем тогда этот форум.... что бы на глупые вопросы получать неменее глупые ответы,

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

← →
Anatoly Podgoretsky © (2008-01-07 23:12) [9]

Наезжать будешь в другом месте

← →
206196131 © (2008-01-07 23:12) [10]

> А нафига тебе альтернатива, ты уже все решил.
> Верующих переубеждать бесполезно.
>

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

← →
206196131 © (2008-01-07 23:16) [11]

> Наезжать будешь в другом месте

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

← →
Loginov Dmitry © (2008-01-07 23:47) [12]

> > К навязчивому желанию запихивать формы в dll
>
>
> а с чего вы взяли что это есть плохо )) аргументируйте
> и предложите альтернативу.
> для ситуации когда есть проект который периодически нужно
> дополнять новыми возможностями но при этом не затрагивать
> то что у же есть

Так на данном форуме принято - формы в dll есть зло! (исходит данное убеждение, наверное от [1]) :-D

На деле же, если компилировать все с bpl-пакетами, то различие между exe и dll полностью стирается. К несчастью, тут есть также противники использования пакетов...

В общем, нужны формы в dll - пожалуйста! Подключай пакеты, и вперед!

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

Ну дык обычный плагин! Ищешь в заданной директории все dll-ки, в которых присутствуют заданные функции... Дальше делаешь с ними все, что тебе нужно.

← →
206196131 © (2008-01-08 01:46) [13]

Loginov Dmitry во пасибо ) то что надо, только я изначально с дугой стороны смотрел. А так за направление респект

← →
Германн © (2008-01-08 02:10) [14]

> 206196131 © (08.01.08 01:46) [13]

Только не забудь про
> В общем, нужны формы в dll - пожалуйста! Подключай пакеты,
> и вперед!

Иначе всё своё время будешь посвящать лечению геморроя.
Или вообще замени длл пакетами. Это самый безгеморройный вариант.
Хотя все эти способы в той или иной степени геморройные из-за зависимости пакетов от версии Дельфи. :(

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

> Хотя все эти способы в той или иной степени геморройные
> из-за зависимости пакетов от версии Дельфи. :(
>

Забыл сказать, что это во многом относится к
> Loginov Dmitry © (07.01.08 23:47) [12]

Это не
> Так на данном форуме принято
. Это суровая правда жизни. :(

← →
Sergey Masloff (2008-01-08 10:01) [16]

Loginov Dmitry © (07.01.08 23:47) [12]
>На деле же, если компилировать все с bpl-пакетами, то различие между >exe и dll полностью стирается.
Не стираются. DLL это универсальный стандарт и использование в нем дельфийской специфики - моветон. Про компиляцию с bpl - лечит лишь от части проблем. Скажем на целевую машину у клиента установит свой софт столь некий столь же хитрый программист у которого Delphi той же версии но с отличным от твоих набором сервиспаков. Имеешь удовольствие наблюдать как твое приложение перестает работать. А после переинсталляции твое работает а "вражеское" нет.
Тогда получается нужно все bpl таскать с каждым приложением устанавливая в отдельный каталог... ну и так далее

← →
Loginov Dmitry © (2008-01-08 10:15) [17]

> Не стираются. DLL это универсальный стандарт и использование
> в нем дельфийской специфики - моветон. Про компиляцию с
> bpl - лечит лишь от части проблем. Скажем на целевую машину
> у клиента установит свой софт столь некий столь же хитрый
> программист у которого Delphi той же версии но с отличным
> от твоих набором сервиспаков. Имеешь удовольствие наблюдать
> как твое приложение перестает работать. А после переинсталляции
> твое работает а "вражеское" нет.
> Тогда получается нужно все bpl таскать с каждым приложением
> устанавливая в отдельный каталог... ну и так далее

Радует то, что в последнее время CodeGear не меняет пакеты от версии к версии. Приложение, написанное на Delphi2007 прекрасно работает с пакетами и от Delphi2006 и от Turbo Delphi 2006. Реальные проблемы могут быть со сторонними пакетами, установленными в System32 - пакет с одним и тем же именем может быть скомпилирован на любой версии Delphi.

← →
Sergey Masloff (2008-01-08 10:26) [18]

Loginov Dmitry © (08.01.08 10:15) [17]
Ну хорошо коли так. А то раньше между сервис-паками даже совместимости не было.

← →
Anatoly Podgoretsky © (2008-01-08 10:48) [19]

> Loginov Dmitry (08.01.2008 10:15:17) [17]

Так 2007 - это просто кушать захотелось.

← →
Leonid Troyanovsky © (2008-01-08 11:14) [20]

> 206196131 © (07.01.08 23:16) [11]

> это не наезд, а просто обидно насам деле за форум

На самом деле, можно даже подумать, что совет использовать
формы в dll был получен на здешнем форуме.

Т.е., кто советовал оное, пусть ответит и на другие вопросы.

Только кажется, что [0] <> "когда все гото".

--
Regards, LVT.

← →
Leonid Troyanovsky © (2008-01-08 11:19) [21]

> 206196131 © (07.01.08 22:48) [5]

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

> 206196131 © (07.01.08 23:12) [10]
>
> > А нафига тебе альтернатива, ты уже все решил.
> > Верующих переубеждать бесполезно.

> мне не нужна альтернатива, нужно просто направление или идея

Т.е., не нужна.
Ортодокс.

--
Regards, LVT.

← →
Leonid Troyanovsky © (2008-01-08 11:25) [22]

> Loginov Dmitry © (07.01.08 23:47) [12]

> Так на данном форуме принято - формы в dll есть зло! (исходит
> данное убеждение, наверное от [1]) :-D

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

--
Regards, LVT.

← →
206196131 © (2008-01-08 16:31) [23]

Оказывается что походу не тут однозначно...

я начал c dll так как это на тот момент был единственный вариант который я представлял себе для реализации задуманного.

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

← →
Anatoly Podgoretsky © (2008-01-08 16:55) [24]

> 206196131 (08.01.2008 16:31:23) [23]

Очень просто, в соответствии с документацией автора.

← →
206196131 © (2008-01-08 18:27) [25]

> Очень просто, в соответствии с документацией автора.

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

И почему dll вам тут не нравятся таки небыло аргументированно ни кем,
дайте хоть сылку на что то вразумительное на тему -- формы в DLL в данной ситуации=ЗЛО

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

← →
Германн © (2008-01-08 18:57) [26]

> дал новую dll есть новые возможности

Эт врядли.

> Насколько я понял Пакеты совсем неиз этой области, плане
> после изменения нужно пере собирать весть проект

Неправильно понял.

← →
206196131 © (2008-01-09 00:34) [27]

Германн аргументы где ваши

>
> > дал новую dll есть новые возможности
>
> Эт врядли.

как это врядли)))
есть форма в dll
а ней 3 едита
и 1 ннопка
procedure TfrmMDI_dll.Button1Click(Sender: TObject); begin edit3.Text:=inttostr(strtoint(edit2.Text)+strtoint(edit1.Text)) end;
усть совсем другая dll ней
procedure TfrmMDI_dll.Button1Click(Sender: TObject); begin edit3.Text:=inttostr(strtoint(edit2.Text)*strtoint(edit1.Text)) end;
теперь наша программа умеет умножать
чем тебе не новая функциональность )))))

____________________________________________________

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

есть такая вот книжка
http://st1.risunok.net/29658/1.jpg

в ней есть такая вот страничка
http://st1.risunok.net/29659/2.jpg

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

Вывод иду читать книжки,тк от вас аргументов не дождаться ))))))

← →
sniknik © (2008-01-09 01:33) [28]

> в ней есть такая вот страничка
> http://st1.risunok.net/29659/2.jpg
где пишется про модули (dcu), а говорили вроде бы про пакеты (bpl).
смотри внимательно на то что читаешь...

хотя, свое имхо, что dll, что bpl без разницы, свои проблемы есть у обоих, и оба не нужны для сомнительного удовольствия поставлять/обновлять программу по частям...
служба внедрения/поддержки путается, и в итоге рассылают все одно все скопом "на всякий случай", а размер "всего" с пакетами гораздо больше чем цельный екзешник.
это о дроблении ради уменьшения обновлений.
ради плагинов? ... нормально, вполне себе причина. но! тут как посмотрю автор и то и то пишет, и программу и плагин, и вероятность что дополнительные плагины ктото другой еще будет писать стремится к нулю, так полагаю?
тогда плюнуть и растереть, писать "одним куском" (т.е. екзешником)
а со своими "плагинами" вы сто раз еще запутаетесь и сделаете из программы кусок гуано, и написать второй хотябы (плагин) без жесткого задокументированного протокола вы скорее всего уже не сможете (месяц два пройдет и все, приплыли)... а вы его ведете? т.е. рисуете там схему взаимодействия, документируете и т.д.? вот, вот так и думал.

> теперь наша программа умеет умножать
> чем тебе не новая функциональность )))))
>

Это не столько новая функциональность самой программы, сколько новая функциональность подключаемого модуля. Хотя это, конечно плюс.

> в ней есть такая вот страничка
> http://st1.risunok.net/29659/2.jpg
>
> на которой ясно русским по белому написано
> что при модификации кого пакета скорее всего вас придется
> пере собирать весь проект.
>
> Вывод иду читать книжки,тк от вас аргументов не дождаться
> ))))))
>

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

> 206196131 © (09.01.08 00:34) [27]

Да. Ещё одно имхо. Очень меня смущает твоё понимание термина "плагин". Создаётся впечатление, что твоя программа, которая их использует - просто пустышка. В ней самой ничего нет, а если и есть, то оно никак (или почти никак) не связано с плагинами. Тогда чем сии плагины в форме dll лучше плагинов в форме exe, которые можно вызвать через CreateProcess?

sniknik про BPL то же самое пишут, если что то кардинально поменяли то нужно пере собирать весь проект....

Да все по полочкам и все расписано (кто/куда/зачем/почему) пройденый этап))

Проект специализированный

В 1 exe не делаю из следующих соображении:
Не всем категориям пользователей нужны определенные функции (в целях безопастности) нет возможности чтото делать нет проблемы.
Локальная безопасность приложении отдельная история.

Плюс удобство обновления дополнения насколько я себе это вижу
а заводить 150 exe файлов не особо хочется

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

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

Все межмодульные взаимодействия ограничиваются одной общей базой данных

> служба внедрения/поддержки

на эту тему нужно будет более детально подумать, человеко фактор не отменить

sniknik благодарчик за конструктивные замечания

хотя что 115 exe что 114 dll тут уже только практика покажет что удобнее

Хотя что 115 exe что 114 dll тут уже только практика покажет что удобнее
На данном этапе делать то что задумано с помошью dll не вызывает особых проблем не считая мелочей жизни

> sniknik про BPL то же самое пишут, если что то кардинально поменяли то нужно пере собирать весь проект....
вообщето я писал не это...
"пересобирать" не надо. обычно... а высылают обычно все равно все, на случай если у клиента в какойто файл потерялся/порушился/очень старая версия/.../на случай если у секретарши критические дни, и и ключ от сейфа с дистрибутивом у нее/просто на всякий случай.
т.е. на практике, то ради чего и делают разбиение программы на пакеты - "удобство обновления/меньший размер обновлений", на практике это НЕ РАБОТАЕТ, наоборот, становиться еще хуже. вот что я писал.

sniknik
я знаю просто начал тебе писать потом отвлекся

> sniknik (09.01.2008 02:42:34) [34]

Суть ДЛЛ в использование их многими программами, если же программа одна, то это уже не суть, а извращение. Все ссылки на частичное обновление не выдерживают критики, будет обычный dll hell.
Кроме того правило использования ДЛЛ - обмен только простыми типами, никаких классов и сложных типов с управляемым временем жизни, с Дельфи ситуация еще усугубляется тем, что у ДЛЛ своя РТТИ и свой менеджер памяти. Вот для этого и были придуманы BPL что бы снять эти недостатки, в тоже время BPL это обычная ДЛЛ только учитывающая реалии Дельфи.

> Anatoly Podgoretsky © (09.01.08 03:32) [36]

Опять промахнулся. "Шикник" это знает. :)
Извини. Ещё раз прикололся. Но это только второй раз!
:)

> Суть ДЛЛ в использование их многими программами, если же
> программа одна,

а если на оборот есть много программ а визуальный интерфейс доступа к ним один

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

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

Midi окна из dll дайте направление движения Найти похожие ветки