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 без разницы, свои проблемы есть у обоих, и оба не нужны для сомнительного удовольствия поставлять/обновлять программу по частям...
служба внедрения/поддержки путается, и в итоге рассылают все одно все скопом "на всякий случай", а размер "всего" с пакетами гораздо больше чем цельный екзешник.
это о дроблении ради уменьшения обновлений.
ради плагинов? ... нормально, вполне себе причина. но! тут как посмотрю автор и то и то пишет, и программу и плагин, и вероятность что дополнительные плагины ктото другой еще будет писать стремится к нулю, так полагаю?
тогда плюнуть и растереть, писать "одним куском" (т.е. екзешником)
а со своими "плагинами" вы сто раз еще запутаетесь и сделаете из программы кусок гуано, и написать второй хотябы (плагин) без жесткого задокументированного протокола вы скорее всего уже не сможете (месяц два пройдет и все, приплыли)... а вы его ведете? т.е. рисуете там схему взаимодействия, документируете и т.д.? вот, вот так и думал.

← →
Германн © (2008-01-09 01:41) [29]

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

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

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

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

← →
Германн © (2008-01-09 01:54) [30]

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

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

← →
206196131 © (2008-01-09 02:12) [31]

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

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

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

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

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

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

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

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

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

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

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

← →
206196131 © (2008-01-09 02:20) [32]

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

← →
206196131 © (2008-01-09 02:22) [33]

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

← →
sniknik © (2008-01-09 02:42) [34]

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

← →
206196131 © (2008-01-09 03:14) [35]

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

← →
Anatoly Podgoretsky © (2008-01-09 03:32) [36]

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

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

← →
Германн © (2008-01-09 04:05) [37]

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

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

← →
206196131 © (2008-01-09 04:24) [38]

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

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

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

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

> Да и когда же ты начнешь читать книжки?

уже

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

> 206196131 © (09.01.08 15:23) [42]
>
> так пацань тема закрыта
> нет смысла дальше продолжать разговор, тк каждый учиться
> на своих граблях))
>

Ох и много будет этих граблей ...

> Ох и много будет этих граблей ...

я и не спорю, но так как других предложении по существу нет буду делать так как я это себе вижу

> Суть ДЛЛ в использование их многими программами, если же
> программа одна, то это уже не суть, а извращение. Все ссылки
> на частичное обновление не выдерживают критики, будет обычный
> dll hell.

У каждого должно быть свое мнение на этот счет. Позвольте высказать свое.
Можно вести речь о том, что dll - это зло и все такое только для примитивнейших систем, где совершенно очевидно, что все можно сделать в одном exe-шнике. Если система простая, то согласен, что нет смысла разбывать на кучу модулей. Если система сложная, но разрабатывается одним человекам, то смысла разбивать вероятно (но с натяжкой), также нет! А вот если система разрабатывается командой, и сложность у нее ОЧЕНЬ высокая, то реализовать все в одном модуле - нет НИКАКОЙ возможности. Т.е. это возможно, но ТОЛЬКО теоретически. Я не могу знать абсолютно всё, и каждый из отдельных членов команды также все не знает! Я делаю головную программу. Она должна работать, скажем, с ключами iButton. Но мне совершенно параллельно, что это такое, и не интересует, как с ними работать, к томуже на то, чтобы разобраться, времени нет! Но я точно знаю, что когда ключик прикладывают к контактной площадке, моя программа должна на это реагировать: считывать код ключа, записывать или считывать данные с него. Соответственно, кому-то поручается работа с ключами. Человек делает библиотеку с тремя функциями - чтение номера ключа, запись данных на ключ, чтение данных с ключа. Далее система устанавливается у клиента. Если требуется доработать / исправить библиотеку, то дорабатывается только она. Если требуется доработать головное приложение, то дорабатывается только оно. Соотвественно, у клиента обновляется только та часть, которая ему нужна. Нет никакого смысла обновлять всю систему.
Далее... Система взаимодействует с оборудованием. Например - с ТРК. Нужно чтобы система по возможности работала со всеми типами ТРК. Их много. Скажем 20 - 30 шт. У каждого типа ТРК свой протокол обмена. Протоколы постоянно меняются, дорабатываются - за этим нужно своевременно следить и вносить изменения. Единственный разумный способ взаимодействия с ТРК - написание индивидуальных драйверов. Получаются небольшие dll-ки размером до 50 Кбайт. Пускай их 20 штук. Но с ними работать в 20 раз проще, чем если бы все они располагались в одном модуле. Покупает клиент себе новую ТРК - вносятся необходимые изменения в один-единственный файл, и только его клиент обновляет. Это кстати был пример, когда деление на модули выручает даже если над системой работает всего один человек, и справедливо не только для ТРК, но и для другого оборудования (кассы, платежные терминалы, дисплеи покупателя и т.д.). Смешивать работу с различным оборудованием в одном модуле - вот ЭТО - ИЗВРАЩЕНИЕ.

Так что единственным правилом, по которому принимается решение о разбивке на модули, является удобство ральнейшего сопровождения системы. Если смысл разбивки ЧЕТКО не осознан, то не стоит приниматься за это дело - все равно толку не будет НИКАКОГО. Если же смысл есть и он осознан - надо разбивать. Все модули во всё время работы системы должны быть совместимыми. Т.е. обновление любого модуля без обновления остальных модулей не должно ухудщить работоспособность системы. Обновления должны улучшать работоспособность системы, но никак не ухудшать. Для этого нужно иметь определенные навыки. Если же доработка модуля приводит к обновлению всех модулей системы (и так каждый раз), то это говорит о том, что у человека недостаточно опыта разрабатывать многомодульную систему, и тут действительно лучше делать все в одном модуле. При работе с плагинами следует максимально полно реализовать обмен данными между модулями. КАЖДАЯ библиотека ОБЯЗАНА уметь возвращать номер версии (желательно целое число). Даже если возможности библиотеки сейчас однозначно определяются набором экспортируемых процедур, рано или поздно номер версии все-равно понадобится. Головное приложение также обязано предоставлять номер версии любой библиотеке. Если в модуль добавляются новые возможности, то следует увеличивать номер версии, а перед использованием этих новых возможностей следует запрашивать номер версии модуля - это определяет, включена ли данная возможность в модуль, или нет. Только так можно избежать эффекта, о котором говорится в [34], т.е. необходимость обновлять всю систему при обновлении какой-то ее части.

Удалено модератором
Примечание: дубль

Loginov Dmitry © (09.01.08 21:34) [45]
а ты разницы не замечаешь? твоих примеров и авторского начинания (по аналогичной технологии та о котороя я "возмущался")

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

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

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

> оба твоих примера - драйвера работающие с устройствами,
> т.е. именно то для чего dll-и и служат. повсеместно

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

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

А причем тут двери? :) iButton"ы разве нужты только чтобы двери открывать? :)

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

Я не внушаю никакие "ложные" надежды. Надеюсь, автору это понятно из последнего абзаца [45], и из нашего обсуждения он сделает для себя вывод, стоит ли тратить время на подобные разбиения.

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

> А причем тут двери? :) iButton"ы разве нужты только чтобы двери открывать? :)
а ты разве не про такую систему которая у нас на проходной, приложил электронную карточку, и дверь открылась. в одном случае, в другом турникет разблокировался. а заодно и учло кто куда пошол.
нет? ну неважно, принцип от этого не страдает, это драйвер устройства.

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

> Насчет адекватных примеров ...

1C чем тебе не адекватный пример, хоть там не DLL но всеже идея как раз отсюда

> 1C чем тебе не адекватный пример, хоть там не DLL
правильно, не dll а ActivX (COM), который как раз для этого и предназначен.

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

> sniknik © (11.01.08 01:34) [51]

+1

Это кстати и к Loginov Dmitry © (09.01.08 21:34) [45]
относится. Хотя в его случае никакой особой разницы нет, в отличие от случая автора сабжа.

> sniknik © (11.01.08 01:34) [51]

м почему эти технолигии всплыли только сейчас )))

> относится. Хотя в его случае никакой особой разницы нет,
> в отличие от случая автора сабжа.
>

Это ты к чему ?

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

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

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