![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Midi окна из dll дайте направление движения [D7, WinXP]
206196131 © (2008-01-06 22:31:00)в 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;
используется для загрузки плагина
sniknik (2008-01-09 02:42:00) [21]> sniknik про BPL то же самое пишут, если что то кардинально поменяли то нужно пере собирать весь проект....
вообщето я писал не это...
"пересобирать" не надо. обычно... а высылают обычно все равно все, на случай если у клиента в какойто файл потерялся/порушился/очень старая версия/.../на случай если у секретарши критические дни, и и ключ от сейфа с дистрибутивом у нее/просто на всякий случай.
т.е. на практике, то ради чего и делают разбиение программы на пакеты - "удобство обновления/меньший размер обновлений", на практике это НЕ РАБОТАЕТ, наоборот, становиться еще хуже. вот что я писал.
206196131 (2008-01-09 02:22:00) [22]Хотя что 115 exe что 114 dll тут уже только практика покажет что удобнее
На данном этапе делать то что задумано с помошью dll не вызывает особых проблем не считая мелочей жизни
206196131 (2008-01-09 02:20:00) [23]хотя что 115 exe что 114 dll тут уже только практика покажет что удобнее
206196131 (2008-01-09 02:12:00) [24]sniknik про BPL то же самое пишут, если что то кардинально поменяли то нужно пере собирать весь проект....
Да все по полочкам и все расписано (кто/куда/зачем/почему) пройденый этап))
Проект специализированный
В 1 exe не делаю из следующих соображении:
Не всем категориям пользователей нужны определенные функции (в целях безопастности) нет возможности чтото делать нет проблемы.
Локальная безопасность приложении отдельная история.
Плюс удобство обновления дополнения насколько я себе это вижу
а заводить 150 exe файлов не особо хочется
> без жесткого задокументированного протокола
все строго регламентировано, да и специфика проекта такая что библиотеки самодостаточные никаких мудрых взаимодействий между различными модулями
Все межмодульные взаимодействия ограничиваются одной общей базой данных
> служба внедрения/поддержки
на эту тему нужно будет более детально подумать, человеко фактор не отменить
sniknik благодарчик за конструктивные замечания
Германн (2008-01-09 01:54:00) [25]
> 206196131 © (09.01.08 00:34) [27]
Да. Ещё одно имхо. Очень меня смущает твоё понимание термина "плагин". Создаётся впечатление, что твоя программа, которая их использует - просто пустышка. В ней самой ничего нет, а если и есть, то оно никак (или почти никак) не связано с плагинами. Тогда чем сии плагины в форме dll лучше плагинов в форме exe, которые можно вызвать через CreateProcess?
Германн (2008-01-09 01:41:00) [26]
> теперь наша программа умеет умножать
> чем тебе не новая функциональность )))))
>
Это не столько новая функциональность самой программы, сколько новая функциональность подключаемого модуля. Хотя это, конечно плюс.
> в ней есть такая вот страничка
> http://st1.risunok.net/29659/2.jpg
>
> на которой ясно русским по белому написано
> что при модификации кого пакета скорее всего вас придется
> пере собирать весь проект.
>
> Вывод иду читать книжки,тк от вас аргументов не дождаться
> ))))))
>
Вот это правильно. Читай книжки. Но читай вдумчиво, тогда может быть поймешь суть второго абзаца того параграфа. Да и кстати поймешь разницу между dll и bpl (в контексте того, почему запихивать формы в dll - плохо, а в bpl - абсолютно естественно).
sniknik (2008-01-09 01:33:00) [27]> в ней есть такая вот страничка
> http://st1.risunok.net/29659/2.jpg
где пишется про модули (dcu), а говорили вроде бы про пакеты (bpl).
смотри внимательно на то что читаешь...
хотя, свое имхо, что dll, что bpl без разницы, свои проблемы есть у обоих, и оба не нужны для сомнительного удовольствия поставлять/обновлять программу по частям...
служба внедрения/поддержки путается, и в итоге рассылают все одно все скопом "на всякий случай", а размер "всего" с пакетами гораздо больше чем цельный екзешник.
это о дроблении ради уменьшения обновлений.
ради плагинов? ... нормально, вполне себе причина. но! тут как посмотрю автор и то и то пишет, и программу и плагин, и вероятность что дополнительные плагины ктото другой еще будет писать стремится к нулю, так полагаю?
тогда плюнуть и растереть, писать "одним куском" (т.е. екзешником)
а со своими "плагинами" вы сто раз еще запутаетесь и сделаете из программы кусок гуано, и написать второй хотябы (плагин) без жесткого задокументированного протокола вы скорее всего уже не сможете (месяц два пройдет и все, приплыли)... а вы его ведете? т.е. рисуете там схему взаимодействия, документируете и т.д.? вот, вот так и думал.
206196131 (2008-01-09 00:34:00) [28]Германн аргументы где ваши
>
> > дал новую 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
на которой ясно русским по белому написано
что при модификации кого пакета скорее всего вас придется пере собирать весь проект.
Вывод иду читать книжки,тк от вас аргументов не дождаться ))))))
Германн (2008-01-08 18:57:00) [29]
> дал новую dll есть новые возможности
Эт врядли.
> Насколько я понял Пакеты совсем неиз этой области, плане
> после изменения нужно пере собирать весть проект
Неправильно понял.
206196131 (2008-01-08 18:27:00) [30]
> Очень просто, в соответствии с документацией автора.
а если я сам автор какой подход использовать, но при этом не лезть в код основной программы.
Мне не нужно пересобирать все барахло однажды уже откомпиленное.
Нужно просто добавлять новые функционально в уже существующий проект по принципу
дал новую dll есть новые возможности
дал модифицированную dll есть изменения/обновления
И почему dll вам тут не нравятся таки небыло аргументированно ни кем,
дайте хоть сылку на что то вразумительное на тему -- формы в DLL в данной ситуации=ЗЛО
Насколько я понял Пакеты совсем неиз этой области, плане после изменения нужно пере собирать весть проект
Anatoly Podgoretsky (2008-01-08 16:55:00) [31]> 206196131 (08.01.2008 16:31:23) [23]
Очень просто, в соответствии с документацией автора.
206196131 (2008-01-08 16:31:00) [32]Оказывается что походу не тут однозначно...
я начал c dll так как это на тот момент был единственный вариант который я представлял себе для реализации задуманного.
Как вообще обычно делают разного рода платины и дополнения к уже существующему софту.
может я не стой стороны подхожу
Leonid Troyanovsky (2008-01-08 11:25:00) [33]
> Loginov Dmitry © (07.01.08 23:47) [12]
> Так на данном форуме принято - формы в dll есть зло! (исходит
> данное убеждение, наверное от [1]) :-D
Это не убеждение, а вполне практичное знание.
И если даже исходило от меня, то лишь потому,
что я стоял на плечах гигантов.
--
Regards, LVT.
Leonid Troyanovsky (2008-01-08 11:19:00) [34]
> 206196131 © (07.01.08 22:48) [5]
> а с чего вы взяли что это есть плохо )) аргументируйте
> и предложите альтернативу.
> 206196131 © (07.01.08 23:12) [10]
>
> > А нафига тебе альтернатива, ты уже все решил.
> > Верующих переубеждать бесполезно.
> мне не нужна альтернатива, нужно просто направление или идея
Т.е., не нужна.
Ортодокс.
--
Regards, LVT.
Leonid Troyanovsky (2008-01-08 11:14:00) [35]
> 206196131 © (07.01.08 23:16) [11]
> это не наезд, а просто обидно насам деле за форум
На самом деле, можно даже подумать, что совет использовать
формы в dll был получен на здешнем форуме.
Т.е., кто советовал оное, пусть ответит и на другие вопросы.
Только кажется, что [0] <> "когда все гото".
--
Regards, LVT.
Anatoly Podgoretsky (2008-01-08 10:48:00) [36]> Loginov Dmitry (08.01.2008 10:15:17) [17]
Так 2007 - это просто кушать захотелось.
Sergey Masloff (2008-01-08 10:26:00) [37]Loginov Dmitry © (08.01.08 10:15) [17]
Ну хорошо коли так. А то раньше между сервис-паками даже совместимости не было.
Loginov Dmitry (2008-01-08 10:15:00) [38]> Не стираются. DLL это универсальный стандарт и использование
> в нем дельфийской специфики - моветон. Про компиляцию с
> bpl - лечит лишь от части проблем. Скажем на целевую машину
> у клиента установит свой софт столь некий столь же хитрый
> программист у которого Delphi той же версии но с отличным
> от твоих набором сервиспаков. Имеешь удовольствие наблюдать
> как твое приложение перестает работать. А после переинсталляции
> твое работает а "вражеское" нет.
> Тогда получается нужно все bpl таскать с каждым приложением
> устанавливая в отдельный каталог... ну и так далее
Радует то, что в последнее время CodeGear не меняет пакеты от версии к версии. Приложение, написанное на Delphi2007 прекрасно работает с пакетами и от Delphi2006 и от Turbo Delphi 2006. Реальные проблемы могут быть со сторонними пакетами, установленными в System32 - пакет с одним и тем же именем может быть скомпилирован на любой версии Delphi.
Sergey Masloff (2008-01-08 10:01:00) [39]Loginov Dmitry © (07.01.08 23:47) [12]
>На деле же, если компилировать все с bpl-пакетами, то различие между >exe и dll полностью стирается.
Не стираются. DLL это универсальный стандарт и использование в нем дельфийской специфики - моветон. Про компиляцию с bpl - лечит лишь от части проблем. Скажем на целевую машину у клиента установит свой софт столь некий столь же хитрый программист у которого Delphi той же версии но с отличным от твоих набором сервиспаков. Имеешь удовольствие наблюдать как твое приложение перестает работать. А после переинсталляции твое работает а "вражеское" нет.
Тогда получается нужно все bpl таскать с каждым приложением устанавливая в отдельный каталог... ну и так далее
Германн (2008-01-08 02:15:00) [40]
> Хотя все эти способы в той или иной степени геморройные
> из-за зависимости пакетов от версии Дельфи. :(
>
Забыл сказать, что это во многом относится к
> Loginov Dmitry © (07.01.08 23:47) [12]
Это не
> Так на данном форуме принято
. Это суровая правда жизни. :(