Ситуация:
Есть приложение (предположим, что это пустая форма)
Приложение подгружает мою dll.
В dll передается Application от основого приложения.
Необходимо из dll создать компонент (например Panel)
на основной форме.
Второй день бьюсь — одни AV вылетают....
Но можно и без пакаджей.
Главное чтобы менеджер памяти для приложения и для DLL был один (в файлах проектов (exe и dll) ShareMem должен быть первым из подключенных модулей).
Я так делал и не раз уже.
ТОлько одно НО, в данном случае нужно быть очень внимательным при работе.
Иначе AV как сыпались так и будут сыпаться.
... -= RSDN@Home 1.1.4 beta 3 rev 279 =- А в Winamp'e — Весь в работе
Дункан Маклауд любил ходить в лес и издеваться над кукушками.
138385660
Здравствуйте, Shtirliz, Вы писали:
S>Но можно и без пакаджей. S>Главное чтобы менеджер памяти для приложения и для DLL был один (в файлах проектов (exe и dll) ShareMem должен
На этом пути таки ждет немало неприятных сюрпризов — см., например, пример с RTTI.
Работа "без пакеджей" лично мне напоминает фильм "Волга-Волга". Конкретно, эпизод:
— Это — первая мель.
КРАМС! БУХ! БРАМС!
— А это — вторая ((
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, Shtirliz, Вы писали:
S>>Но можно и без пакаджей. S>>Главное чтобы менеджер памяти для приложения и для DLL был один (в файлах проектов (exe и dll) ShareMem должен
S>На этом пути таки ждет немало неприятных сюрпризов — см., например, пример с RTTI.
В этом согласен , потому и написал, что нада быть очень осторожным, чтобы не напороться на "вторую мель".
... -= RSDN@Home 1.1.4 beta 3 rev 279 =- А в Winamp'e — Весь в работе
Дункан Маклауд любил ходить в лес и издеваться над кукушками.
138385660
Здравствуйте, Demon_TM, Вы писали:
D_T>Ситуация: D_T>Есть приложение (предположим, что это пустая форма) D_T>Приложение подгружает мою dll. D_T>В dll передается Application от основого приложения. D_T>Необходимо из dll создать компонент (например Panel) D_T>на основной форме. D_T>Второй день бьюсь — одни AV вылетают....
Передавать классы, строки и т.д. через границы dll — НЕПРАВИЛЬНО!
Ибо любое отлтчие версии компилера, выравнивания и тому подобного несёт глюки.
Интерфейсы, числа, пакованные записи — самое то для передачи.
При этом нет зависимости от компилятора, хоть на асме пиши.
По ситуации: я использовал интерфейсы в своём случае.
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, DJ KARIES, Вы писали:
DK>>Передавать классы, строки и т.д. через границы dll — НЕПРАВИЛЬНО!
S>Безусловно. Если есть возможность для извращений — надо извращаться.
Надо стремиться обходиться без извращений.
DK>>Ибо любое отлтчие версии компилера, выравнивания и тому подобного несёт глюки.
S>А зачем Вы компилируете части одной и той же программы разными версиями компилятора?
Отвечу вопросом на вопрос.
А зачем Вы разбиваете одну свою программу на кучу глючных dll?
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, DJ KARIES, Вы писали:
DK>>При этом нет зависимости от компилятора, хоть на асме пиши.
S>Нет. И до тех пор, пока нет необходимости писать на асме — нафига?
DK>>По ситуации: я использовал интерфейсы в своём случае.
S>Хм. Интерфейсы-то интерфейсами, но работать все равно не будет. Тем более, если закладываться на разные версии компилятора.
Интерфейсы независимы от компилятора, по сути это пакованные записи, т.е. таблицы виртуальных методов с выравниванием по границе в 1 байт.
Потому и работает COM независимо от компиляторов, т.к. есть двоичная совместимость.
А строки в Delphi, классы и непакованные записи/массивы могут быть двоично несовместимыми.
Если хочется обойтись малой кровью, и завязать всё на конкретной версии Delphi, используйте bpl.
Здравствуйте, DJ KARIES, Вы писали:
DK>Интерфейсы независимы от компилятора, по сути это пакованные записи, т.е. таблицы виртуальных методов с выравниванием по границе в 1 байт. DK>Потому и работает COM независимо от компиляторов, т.к. есть двоичная совместимость.
Осталось выяснить:
а) как часто нужна двоичная совместимость для произвольного приложения
б) зачем нужна двоичная совместимость, если передаваться через нее будут двоично несовместимые данные (или ты считаешь TWinControl двоично совместимым?)
DK>Если хочется обойтись малой кровью, и завязать всё на конкретной версии Delphi, используйте bpl.
Нахрена стрелять из пушки по воробьям? Разумнее обойтись малой кровью, используя dll.
Здравствуйте, DJ KARIES, Вы писали:
DK>>>Передавать классы, строки и т.д. через границы dll — НЕПРАВИЛЬНО! S>>Безусловно. Если есть возможность для извращений — надо извращаться. DK>Надо стремиться обходиться без извращений.
Хм. Давайте я теперь попрошу Вас согласовать два Ваших утверждения из квоты выше Неудобно понимать человека, который противоречит сам себе.
DK>>>Ибо любое отлтчие версии компилера, выравнивания и тому подобного несёт глюки. S>>А зачем Вы компилируете части одной и той же программы разными версиями компилятора? DK>Отвечу вопросом на вопрос. DK>А зачем Вы разбиваете одну свою программу на кучу глючных dll?
Карел Чапек, шестой из двенадцати принципов литературной полемики.
Здравствуйте, Softwarer, Вы писали:
DK>>Если хочется обойтись малой кровью, и завязать всё на конкретной версии Delphi, используйте bpl.
S>Нахрена стрелять из пушки по воробьям? Разумнее обойтись малой кровью, используя dll.
Если вы передаёте в dll объекты VCL, то у вас по-любому отпадает возможность использовать с этой откомпилированной dll исполняемые модули, откомпилированные компиляторыми, отличными от того, которым эту dll откомпилили
В этом случае БЕЗОПАСНЕЕ и ВЫГОДНЕЕ использовать bpl.
bpl — это dll, но использующая специальные борландовские соглашения для того, чтобы работать с дельфийскими классами, строками, и т.д. через барьер в виде динамических библиотек.
Здравствуйте, DJ KARIES, Вы писали:
DK>>>Если хочется обойтись малой кровью, и завязать всё на конкретной версии Delphi, используйте bpl. S>>Нахрена стрелять из пушки по воробьям? Разумнее обойтись малой кровью, используя dll. DK>Если вы передаёте в dll объекты VCL, то у вас по-любому отпадает возможность использовать с этой откомпилированной dll исполняемые модули, откомпилированные компиляторыми, отличными от того, которым эту dll откомпилили
В первую очередь я бы задал вопрос, для чего такая возможность нужна. В тех редких случаях, когда она нужна — приходится делать более строгий интерфейс, работать "большой кровью". Но лично я куда чаще видел вариант "сделали из общих соображений, мучаемся, а нахрена нам была эта совместимость — так и не поняли".
DK>В этом случае БЕЗОПАСНЕЕ и ВЫГОДНЕЕ использовать bpl.
Не так. Использовать bpl в этом случае не безопаснее и не выгоднее. Основной минус bpl — они экспортируют очень много лишнего. Нормально написанные dll обладают хорошей совместимостью по версиям (в плане написанных в разное время, откомпилированных разными группами разработчиков итп). BPL очень часто требуют перекомпиляции из-за мелких, технических изменений в связанных модулях.
DK>bpl — это dll, но использующая специальные борландовские соглашения для того, чтобы работать с дельфийскими классами, строками, и т.д. через барьер в виде динамических библиотек.
bpl — это dll, использующая несколько дополнительных соглашений для согласования содержащихся модулей итп. С классами, строками итд она работает абсолютно так же, как нормально сделанная dll. Единственно, в отличие от dll, ее нельзя заставить работать с ними ненормально.
Здравствуйте, Demon_TM, Вы писали:
D_T>Ситуация: D_T>Есть приложение (предположим, что это пустая форма) D_T>Приложение подгружает мою dll. D_T>В dll передается Application от основого приложения. D_T>Необходимо из dll создать компонент (например Panel) D_T>на основной форме. D_T>Второй день бьюсь — одни AV вылетают....
Покажи код создания
Здравствуйте, Softwarer, Вы писали:
S>Здравствуйте, DJ KARIES, Вы писали:
DK>>>>Если хочется обойтись малой кровью, и завязать всё на конкретной версии Delphi, используйте bpl. S>>>Нахрена стрелять из пушки по воробьям? Разумнее обойтись малой кровью, используя dll. DK>>Если вы передаёте в dll объекты VCL, то у вас по-любому отпадает возможность использовать с этой откомпилированной dll исполняемые модули, откомпилированные компиляторыми, отличными от того, которым эту dll откомпилили
S>В первую очередь я бы задал вопрос, для чего такая возможность нужна. В тех редких случаях, когда она нужна — приходится делать более строгий интерфейс, работать "большой кровью". Но лично я куда чаще видел вариант "сделали из общих соображений, мучаемся, а нахрена нам была эта совместимость — так и не поняли".
Правильное решение — юзать интерфейсы, WideString'и, Packed Record'ы и т.д.
Не желательно привязываться к Delphi, к тому же определённой версии.
DK>>В этом случае БЕЗОПАСНЕЕ и ВЫГОДНЕЕ использовать bpl.
S>Не так. Использовать bpl в этом случае не безопаснее и не выгоднее. Основной минус bpl — они экспортируют очень много лишнего. Нормально написанные dll обладают хорошей совместимостью по версиям (в плане написанных в разное время, откомпилированных разными группами разработчиков итп). BPL очень часто требуют перекомпиляции из-за мелких, технических изменений в связанных модулях.
BPL уменьшают число проблем, возникающих при работе c VCL через межмодульный (exe-dll-dll) барьер.
DK>>bpl — это dll, но использующая специальные борландовские соглашения для того, чтобы работать с дельфийскими классами, строками, и т.д. через барьер в виде динамических библиотек.
S>bpl — это dll, использующая несколько дополнительных соглашений для согласования содержащихся модулей итп. С классами, строками итд она работает абсолютно так же, как нормально сделанная dll. Единственно, в отличие от dll, ее нельзя заставить работать с ними ненормально.
И я о том же.
Если вы пишете СЕРЬЁЗНУЮ систему, то вы не завязываете бинарную совместимость на особенностях Delphi выбранной на данный момент версии.
Разве НОРМАЛЬНЫЙ программист станет передавать в dll какой-нибудь TWinControl или TObject?
НЕТ!
Передавать объекты/строки/непакованные записи Delphi передавать можно только в случае, когда вы уверены, что два обменивающихся модуля откомпилированы одним и тем же компилятором с одними и теми же настройками выравнивания и теми же версиями всех библиотек.
Здравствуйте, DJ KARIES, Вы писали:
DK>Правильное решение — юзать интерфейсы, WideString'и, Packed Record'ы и т.д. DK>Не желательно привязываться к Delphi, к тому же определённой версии.
Неаргументированное утверждение, громко повторенное три раза, становится верным
Вы бы назвали хоть одну причину этого "не желательно", хорошо бы вместе с оценкой, как часто эта причина встречается.
DK>Если вы пишете СЕРЬЁЗНУЮ систему, то вы не завязываете бинарную совместимость на особенностях Delphi выбранной на данный момент версии.
Если я пишу серьезную систему, мне совершенно незачем постоянно думать о бинарной совместимости. Она отлично поддерживается без малейших усилий с моей стороны.
DK>Разве НОРМАЛЬНЫЙ программист станет передавать в dll какой-нибудь TWinControl или TObject? DK>НЕТ!
Если считать нормальным программиста ОРУЩЕГО, БЕЗАРГУМЕНТАРНОГО и ДЕМАГОГИЧЕСКОГО — ничего не могу сказать по поводу того, как он станет действовать.
DK>Передавать объекты/строки/непакованные записи Delphi передавать можно только в случае, когда вы уверены, что два обменивающихся модуля откомпилированы одним и тем же компилятором с одними и теми же настройками выравнивания и теми же версиями всех библиотек.
То есть примерно в 98% случаев разработки серьезных приложений.
Дункан Маклауд любил ходить в лес и издеваться над кукушками.
((
, потому и написал, что нада быть очень осторожным, чтобы не напороться на "вторую мель". 
Неудобно понимать человека, который противоречит сам себе.
