Форум: "Прочее";
Текущий архив: 2014.02.02;
Скачать: [xml.tar.bz2];
ВнизЗачем формы размещают в *.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;
Скачать: [xml.tar.bz2];
Память: 0.59 MB
Время: 0.003 c