Главная страница
Top.Mail.Ru    Яндекс.Метрика
Текущий архив: 2014.02.02;
Скачать: CL | DM;

Вниз

Зачем формы размещают в *.dll   Найти похожие ветки 

 
Разведка   (2013-08-14 11:44) [0]

Что если не размещать формы в dll при большой программе?


 
DVM ©   (2013-08-14 11:45) [1]


> Зачем формы размещают в *.dll

Чтоб жизнь медом не казалась


 
Разведка   (2013-08-14 11:48) [2]

Я что хотел выяснить то это лучше делать при большом проекте или можно обойтись?


 
sniknik ©   (2013-08-14 12:08) [3]

это лучше вообще не делать... никогда.


 
stas ©   (2013-08-14 13:13) [4]

Разведка   (14.08.13 11:48) [2]
Вопрос из ряда: "Что если я не буду в своем проекте использовать dll"
Смотря для каких целей тебе в проекте dll.


 
Ega23 ©   (2013-08-14 13:30) [5]


> Я что хотел выяснить то это лучше делать при большом проекте
> или можно обойтись?


1. Это геморрой.
2. Многие вообще не понимают, зачем нужны dll.


 
sniknik ©   (2013-08-14 13:41) [6]

> Вопрос из ряда: "Что если я не буду в своем проекте использовать dll"
совсем нет, т.к. на этот вопрос ответ будет - ты не сможешь... практически в любом проекте используется куча dll-ек, не взирая на желание "использовать или  не использовать".


 
stas ©   (2013-08-14 13:47) [7]

sniknik ©   (14.08.13 13:41) [6]
Согласен ).
Я имею ввиду,  думаю и автор, написание собственных dll для использования в своем проекте.


 
Dennis I. Komarov ©   (2013-08-14 14:41) [8]

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


 
Обычный порошок   (2013-08-14 14:53) [9]

это лучше вообще не делать... никогда.

это можно делать всегда и тебе за это ничего не будет.

function bla_bla_bla : integer;
begin
создать форму в длл;
показать форму в длл;
если модалрезалт равно ок зен
 result := какое-то значение
иначе
result := -1;
end;


 
Ega23 ©   (2013-08-14 14:55) [10]


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


Ага. А потом обновится десяток форм и все 10 dll обновлять?


> - использовать диалоги в различных приложениях (например
> LogOn форма)


Что мешает просто вкомпилить эту форму (компонент)?


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


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


 
DVM ©   (2013-08-14 14:57) [11]


> Обычный порошок   (14.08.13 14:53) [9]


> это можно делать всегда и тебе за это ничего не будет.

Модальные конечно можно, но при этом DLL будет включать еще раз весь код VCL и размер ее сильно вырастет. И так столько раз сколько у нас таких DLL с формами. Лучше уж пакеты тогда.


 
Обычный порошок   (2013-08-14 15:00) [12]

понеслась душа в рай.....
началось с того, что будет больно и будет гемор. всегда.

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


 
DVM ©   (2013-08-14 15:02) [13]


> Обычный порошок   (14.08.13 15:00) [12]


> когда стало ясно, что ни боли ни гемора нет

с немодальными еще какой


 
Обычный порошок   (2013-08-14 15:12) [14]

ну то есть гемор есть всегда?


 
DVM ©   (2013-08-14 15:24) [15]


> Обычный порошок   (14.08.13 15:12) [14]

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


 
Ega23 ©   (2013-08-14 15:25) [16]


> ну то есть гемор есть всегда?


Да. как минимум - на поддержке вызовов dll (если динамическая загрузка). В ловле багов, ежели где-то stdcall или cdecl какой-нить забыл проставить.
С ShareMem-ом, либо с передачей всяких строк туда-сюда.
Очень много лишней работы. Выигрыш - непонятно в чём.

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


 
Обычный порошок   (2013-08-14 15:29) [17]

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


 
Dennis I. Komarov ©   (2013-08-14 15:32) [18]


> Ага. А потом обновится десяток форм и все 10 dll обновлять?

да... причем еще не факт что все сразу.


 
Обычный порошок   (2013-08-14 15:33) [19]

кстати я могу щас накидать несколько примеров с формами без длл, в которых будет еще тот гемор (я гарантирую это. 146 %).

может тогда формы и без длл использовать нельзя?


 
Dennis I. Komarov ©   (2013-08-14 15:39) [20]


> Что мешает просто вкомпилить эту форму (компонент)?

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

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

Не спорю, всегда надо аккуратно....


 
DVM ©   (2013-08-14 15:44) [21]


> Обычный порошок   (14.08.13 15:33) [19]


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

Валяй.


 
Dennis I. Komarov ©   (2013-08-14 15:50) [22]


> DVM ©   (14.08.13 15:02) [13]
>
> > Обычный порошок   (14.08.13 15:00) [12]
>
>
> > когда стало ясно, что ни боли ни гемора нет
>
> с немодальными еще какой

Например...


 
Обычный порошок   (2013-08-14 16:06) [23]

Валяй.

валяю. (но оглядываясь на ниже)
ежели где-то stdcall или cdecl какой-нить забыл проставить.

немодальная форма.
caFree
переменная не обнуляется.
в результате косяк.

пример не дурнее того самого ежели что выше.

навалял?


 
Dennis I. Komarov ©   (2013-08-14 16:07) [24]

Кстати, кто пояснит?
Есть указатель x: PAnyRecInfo. Пусть в приложении есть кусок памяти, в котором храниться инфа от записи.
При вызове stdcall функции из dll AnyFunc(x), как инфа попадет в dll?


 
Ega23 ©   (2013-08-14 16:08) [25]


> ну то есть гемор есть не всегда, можно пхать формы в длл
> и вам за это ничего не будет?


Гемор есть всегда. Для того, чтобы форму запихнуть в dll и аккуратно всё прописать, строк кода и затраченного времени будет больше, чем просто форму вкомпилить в проект.
Посему вопрос: а стоит ли?


 
Ega23 ©   (2013-08-14 16:11) [26]


> При вызове stdcall функции из dll AnyFunc(x), как инфа попадет
> в dll?

Указатель - через стек, ну а унутре уже x^. ...
И опять-таки приколы с типами данных в PAnyRecInfo.


 
Обычный порошок   (2013-08-14 16:14) [27]

Гемор есть всегда. Для того, чтобы форму запихнуть в dll и аккуратно всё прописать, строк кода и затраченного времени будет больше, чем просто форму вкомпилить в проект.
Посему вопрос: а стоит ли?


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


 
Dennis I. Komarov ©   (2013-08-14 16:20) [28]


> Посему вопрос: а стоит ли?

Это же совсем другой вопрос. Цели не были озвучены, как и функционал :)


 
Ega23 ©   (2013-08-14 16:21) [29]


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


Использовать можно всё. Вопрос в целесообразности. В большинстве случаев пихать форму в dll нецелесообразно. Как правило этим грешат начинающие разработчики, которые всё на свете готовы в dll запихнуть, покупаясь на "не надо будет всё приложение билдить".
Я могу понять, когда проект билдится полчаса. Но у нас-то это десятки секунд максимум.


 
Ega23 ©   (2013-08-14 16:23) [30]


>  Но у нас-то это десятки секунд максимум.


"у нас" - это у delphi-разработчиков.


 
Dennis I. Komarov ©   (2013-08-14 16:28) [31]


> Указатель - через стек, ну а унутре уже x^. ...

Не, ты не понял... AnyFunc с какой памятью будет работать?


 
Ega23 ©   (2013-08-14 16:30) [32]


> Не, ты не понял... AnyFunc с какой памятью будет работать?


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


 
Dennis I. Komarov ©   (2013-08-14 16:30) [33]


> И опять-таки приколы с типами данных в PAnyRecInfo.

А чего в них прикольного? :) Вот все API в них и ничего...


 
Ega23 ©   (2013-08-14 16:33) [34]


> А чего в них прикольного? :) Вот все API в них и ничего.
> ..


Дык там и string не найдёшь, везде пчары с длиной. Копирование каждый раз, счётчики ссылок... Ну гемор же.


 
Dennis I. Komarov ©   (2013-08-14 16:39) [35]


> Дык там и string не найдёшь, везде пчары с длиной. Копирование
> каждый раз, счётчики ссылок... Ну гемор же.

да брось... а в dll со стрингами вообще не красиво


 
DVM ©   (2013-08-14 16:43) [36]


> Dennis I. Komarov ©   (14.08.13 15:50) [22]
>
> > DVM ©   (14.08.13 15:02) [13]
> >
> > > Обычный порошок   (14.08.13 15:00) [12]
> >
> >
> > > когда стало ясно, что ни боли ни гемора нет
> >
> > с немодальными еще какой
>
> Например...

Начнем с того, что в DLL и в основной программе в каждой свой RTTI и имеем проблемы из этого вытекающие в виде потенциальной несовместимости даже одних и тех же типов между собой.
Аналогично менеджер памяти в каждой свой.
Для нормальной работы немодальной формы нужен объект TApplication, который как то нужно передать форме в Dll, но опять же читаем про RTTI.
Будут проблемы с фокусом, ресайзом (если форма встраивается в другую) да много чего.
Все решаемо конечно, но зачем спрашивается такой геморрой?


 
Ega23 ©   (2013-08-14 16:48) [37]


> да брось... а в dll со стрингами вообще не красиво


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


 
sniknik ©   (2013-08-14 16:52) [38]

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

> Ну гемор же.
и еще какой...
http://delphimaster.net/view/15-1365767063/
там в последнем посте, оказалось вполне стандартный способ для некоторых "плагинных" компонент для передачи "строк" (выглядят как строки, в доках строки, но не нифига строки... ).


 
DVM ©   (2013-08-14 16:54) [39]


> Обычный порошок   (14.08.13 16:06) [23]


> немодальная форма.
> caFree
> переменная не обнуляется.
> в результате косяк.
>
> пример не дурнее того самого ежели что выше.
>
> навалял?

Это пример того как не надо делать, а именно использовать глобальные переменные.
При нормальном использовании форм согласно документации проблем нет.
При использовании немодальных форм в dll проблема уже есть изначально.


 
Dennis I. Komarov ©   (2013-08-14 17:00) [40]


> Начнем с того, что в DLL и в основной программе в каждой
> свой RTTI и имеем проблемы из этого вытекающие в виде потенциальной
> несовместимости даже одних и тех же типов между собой.
> Аналогично менеджер памяти в каждой свой.
> Для нормальной работы немодальной формы нужен объект TApplication,
>  который как то нужно передать форме в Dll, но опять же
> читаем про RTTI.
> Будут проблемы с фокусом, ресайзом (если форма встраивается
> в другую) да много чего.
> Все решаемо конечно, но зачем спрашивается такой геморрой?
>

ммм, я про Show vs ShowModal, про внутренности это отдельно...


 
jumping jack   (2013-08-14 17:11) [41]

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


 
Dennis I. Komarov ©   (2013-08-14 17:39) [42]


> jumping jack   (14.08.13 17:11) [41]
> зря что ли борланд старался, продумывал формат BPL?
> вам точно взаимодействие с кодом от других компиляторов
> нужно?

Ну вот... Всю "малину" испортил :)


 
robt5   (2013-08-14 17:58) [43]


> Разведка   (14.08.13 11:48) [2]

дллшки нужны для:
1) совместного использования кода несколькими программами (для обычного проекта неактуально)
2) экономии памяти (сейчас вообще неактуально)
3) плагины\расширения которые пишут сторонние прогеры

зы да я кэп


 
Dennis I. Komarov ©   (2013-08-14 21:13) [44]


> зы да я кэп

Разъясните темному смысл этой фразы, плиз...

http://ru.wikipedia.org/wiki/%CA%FD%EF

Материал из Википедии — свободной энциклопедии

7-метилгуанозин
Кэп (5"-кэп, кэп-структура) (от англ. cap — шапочка) — один или несколько модифицированных нуклеотидов на 5"-конце транскриптов, синтезированных РНК-полимеразой II. С химической точки зрения, кэп представляет собой 7-метилгуанозин, соединённый 5",5"-трифосфатным мостиком с первым нуклеотидным остатком транскрипта. В узком смысле под кэпом понимают именно 7-метилгуанозин. Кроме того, первые два нуклеотида транскрипта могут метилироваться по 2"-O-положению рибозы. Кэп способствует эффективному процессингу пре-мРНК, экспорту мРНК из ядра, её трансляции и защите от быстрой деградации[1][2].


 
Dennis I. Komarov ©   (2013-08-14 21:32) [45]


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

Дмитрий, можно мастер-класс по этому пункту

Предположим мне надо в dll отправить скажем TBitmap (ну пусть так, будем там где-нить его рисовать)
Оговариваемся заранее - соглашение у нас stdcall, с ShareMem не пляшем

В приложении есть некий x: TBitmap (x.Create, x.LoadFrom...)
Т.е. менеджер памяти приложения где-то выделил память и поместили туда нечто типа TBitmap.
Пусть в dll есть форма, будем на ней рисовать этот битмэп

Функция DllFormShow (y: TBitmap)

Получается TBitmap(x) совсем не TBitmap(y)? Подерутся?
Если да, тогда вопрос: Как лучше передать в dll что-то вроде TBitmap? Ведь по сути такой же указатель как и PChar.
Как RTTI библиотеки будет интерпретировать переданный указатель x?


 
Dennis I. Komarov ©   (2013-08-14 21:50) [46]


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

Ну не до такой же степени... Ясный пень про внутри и речи не было :)
А ShareMem это опять же дельфиная сущность...


 
Германн ©   (2013-08-14 22:04) [47]


> Получается TBitmap(x) совсем не TBitmap(y)? Подерутся?

Cannot assign a TBitmap to a TBitmap


 
Dennis I. Komarov ©   (2013-08-14 22:15) [48]


> Cannot assign a TBitmap to a TBitmap

Хорошо, скормим функции чистый Pointer, а не TBitMap...
Внутрях то что происходит? Почему PChar-ы не дерутся?


 
DVM ©   (2013-08-14 22:30) [49]


> Dennis I. Komarov ©   (14.08.13 21:32) [45]

Не исключено, что с какими то объектами будет все прекрасно работать, но это не значит, что будет работать всегда. Как я уже сказал RTTI dll и основной программы разные, а это значит, что классы с одними и теми же названиями и возможно даже одинаковой реализацией  - это все же разные классы. Не будет работать as/is например.
Еще хуже, если версии делфи на которых собирались DLL и основное приложение - разные. При попытке передать указатель на объект в Dll и обратиться к его методу может произойти все что угодно.


> Получается TBitmap(x) совсем не TBitmap(y)? Подерутся?

Скорее всего даже заработает, но это очень хорошая идея.


> Если да, тогда вопрос: Как лучше передать в dll что-то вроде
> TBitmap? Ведь по сути такой же указатель как и PChar.

На мой взгляд есть 2 варианта:

1) Использовать подход, применяющийся повсеместно в WinApi. Некая функция в dll создает экземпляр объекта и выдает нам указатель (хэндл).
Для работы с этим хэндлом в Dll предусмотрен ряд функций, ну например, для изменения его размера. Но это неудобно, хотя максимально универсально.
2) Пакеты

Еще правда есть вариант с интерфейсами


 
robt5   (2013-08-14 22:32) [50]


> Dennis I. Komarov ©   (14.08.13 21:13) [44]

кэп=капитан очевидность


 
DVM ©   (2013-08-14 22:35) [51]


> DVM ©   (14.08.13 22:30) [49]


> Скорее всего даже заработает, но это очень хорошая идея.

НЕ ОЧЕНЬ ХОРОШАЯ я хотел сказать


 
Dennis I. Komarov ©   (2013-08-14 23:01) [52]


> Не исключено, что с какими то объектами будет все прекрасно
> работать, но это не значит, что будет работать всегда. Как
> я уже сказал RTTI dll и основной программы разные, а это
> значит, что классы с одними и теми же названиями и возможно
> даже одинаковой реализацией  - это все же разные классы.
>  Не будет работать as/is например.

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


 
картман ©   (2013-08-14 23:09) [53]


>  вот почему разные RTTI типы одинаковой реализации разно
> раскидывают в памяти

хотя б строки изменятся.


 
DVM ©   (2013-08-14 23:21) [54]


> но вот почему разные RTTI типы одинаковой реализации разно
> раскидывают в памяти

Разумеется информация о классах и их VMT размещены по разным адресам, as и is из-за этого не работают, а вместе с ними куча методов типа Assign и прочих их использующих. По моему все очевидно.


 
Юрий Зотов ©   (2013-08-14 23:33) [55]

> Dennis I. Komarov ©   (14.08.13 23:01) [52]
> почему разные RTTI типы одинаковой реализации разно раскидывают
> в памяти - вот это не очень понятно

Потому что EXE и DLL компилятся, как два отдельных проекта, ничего не знающих друг о друге. Соответственно, для одного и того же класса X получаем две VMT со всеми вытекающими последствиями.


 
Dennis I. Komarov ©   (2013-08-14 23:55) [56]

Возьмем string (ansistring) - указатель на размер и т.д. Почему его не можем? Да дельфовый тип, но если и то и другое made by Borland...


 
Rouse_ ©   (2013-08-15 00:00) [57]


> Dennis I. Komarov ©   (14.08.13 23:55) [56]
> Возьмем string (ansistring) - указатель на размер и т.д.
>  Почему его не можем?

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


 
Rouse_ ©   (2013-08-15 00:03) [58]

Ну в добавок не забывай что строки в той-же семере и XE4 (к примеру) это ни разу не указатель на размер...


 
Rouse_ ©   (2013-08-15 00:20) [59]


> Rouse_ ©   (15.08.13 00:03) [58]

зы: в том смысле что в помимо восьмибайтного хидера в виде refcount и size в семерке, в юникодных дельфях еще и кодировка 4-ех байтная туда вплетается, по сути дающая размер хидера в 12 байт. Отсель вытекает что даже при использовании шаремема семерка может быть слегка ошарашена библиотекой от юникодной сборки...


 
Dennis I. Komarov ©   (2013-08-15 00:34) [60]


> Rouse_ ©   (15.08.13 00:20) [59]

Так не честно. Это уже разные типы по сути... Я же говорю о разном отражении RTTI одинаковых типов в памяти


 
Rouse_ ©   (2013-08-15 00:42) [61]


> Я же говорю о разном отражении RTTI одинаковых типов в памяти

Конечно разные, RTTI нельзя рассматривать как оторванную от концепта сущность.
Сделаю аналогию - в автомобиле 4 колеса, ездят одинаково, все круглые, все из резины и железяк всяких. Можно сказать 4 экземпляра одного и того-же класса, но вот тормоза, подведенные к каждому из колес, разные.


 
[ВладОшин] ©   (2013-08-15 09:25) [62]

В наст. вр. dll юзаю только в одном случае - если нужна связь со сторонними прогами.
Именно dll требовали разработчики 2х программ, от которых нам нужна инфа. Начали было обговаривать форматы экспорта/импорта, но потом решили, что экспорт будет online, по факту. Для этого они дергают нашу функцию из dll. Появилось событие - вызвали. А мы уже вольны подкладывать свои dll? которые сделают как нам надо


 
Inovet ©   (2013-08-15 09:30) [63]

> [62] [ВладОшин] ©   (15.08.13 09:25)

Так это не пихание туда форм.


 
[ВладОшин] ©   (2013-08-15 09:57) [64]


> Так это не пихание туда форм.

дык, елы-палы, братушка, о чем и речь :)

dll, как фугу, - неправильно приготовишь и чииникакуру :)
а на вкус (говорят:)) не так чтоб уж очень.
Так зачем есть? :)

Путь самурая
Прервался земноводным
Печальная смерть


 
sniknik ©   (2013-08-15 14:02) [65]

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


 
[ВладОшин] ©   (2013-08-15 14:45) [66]


> sniknik ©   (15.08.13 14:02) [65]

Там же понятно  (, вроде :) )
Не использую.

Если бы мог советовать - посоветовал бы не юзать. Не стоит.
Если надо - только простые типы возвращать(, сверившись в размерности с типами С+)

После того как cxDbGrid от devexpress (версию библиотеки не помню, ранняя какая-то) "мертво съедал" dblClick, и поправить не удалось никак (Tapplication, Tscreen, и проч., и проч. передавал) бросил это дело.

Потом, как правильно заметили - перекомпилить приложение на delphi  - дело секунд, чем прописывать все эти передачи всего в dll. Даже если написать шаблон свой заранее.

на Королевстве статьи почитать можно
И у гансмокера

зы
Но если Мастера уже сказали все по теме -
что еще делать нам смертным? Только про кулинарию и остается :)



Страницы: 1 2 вся ветка

Текущий архив: 2014.02.02;
Скачать: CL | DM;

Наверх




Память: 0.66 MB
Время: 0.016 c
2-1363698120
NBAH1990
2013-03-19 17:02
2014.02.02
Определение темы текста по словарю.


2-1364484308
ch_dark
2013-03-28 19:25
2014.02.02
помогите не могу разобраться с меню


2-1364394906
8-bytes
2013-03-27 18:35
2014.02.02
приложение в трехзвенке


15-1376365256
Ротанг
2013-08-13 07:40
2014.02.02
Как настроить почту в Windows 8


15-1376669029
Потапов А.В.
2013-08-16 20:03
2014.02.02
Посоветуйте планшет на андроид