| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Delphi: WinAPI и системное программирование > Приложене и DLL особенности их взаимодействия |
| Автор: Alexeis 15.11.2006, 11:17 |
| Насколько я знаю при загрузке DLL происходит отображение ее образа в память процесса. Для DLL же вообще просто, она воспринимает все как единое адресное пространство. Т.о. если Dll используется только с программой на делфи, то должно функционировать так как будто это все единое целое. Однако, на практике, такого не происходит. Во первых как уже многие знают для работы со строками нужно иметь общий менеджер кучи. Во-вторых, и главное неверно определяется RTTI т.е. информация о типах во время исполнения программы. В чем это проявляется? А вот в чем. Пусть в приложении мы создали компонент Timage, и поместили в него тем или иным образом изображение, например битмап. Теперь передаем объект (т.е. указатель на него в DLL) и пробуем обратится к его содержимому (содержимому Image, т.е. Bitmap). Поскольку Timage является контейнером для разного типа изображений, то перед проведением очередной операции имага проверяет, что у в ней (jpeg, bitmap, метафайл или что-то еще.), однако в этот момент наступает облом. Если проверка производится из DLL, то возвращается информация о том, что не существует никакого внутреннего битмапа, тогда как он на самом деле есть. Аналогичная операция произведенная из приложения, дает верную информацию о битмапе. Теперь дальше, к чему это приводит, а к тому, что имага думает что раз ничего нет, то надо его создать, и на всякий случай сносит имеющийся битмап (просто готовит контейнер для создания нового битмапа) и естественно создает новый пустой. Т.о. даже операция ЧТЕНИЯ!!! приводит к тому, что теряется исходное изображение. Теперь собственно вопрос. В чем состоит особенность взаимодействия приложения и вызванной им DLL, что не позволяет корректно получить RTTI? p.s. тема создана для поддержки соседней темы из раздела Delphi: Графика, звук и видео, http://forum.vingrad.ru/index.php?showtopic=121571 |
| Автор: Alexeis 15.11.2006, 13:03 |
| Вопрос решен Snowy. Он почему-то не захотел отписаться. Дело в том, что DLL и экзе имеют различные экземпляры классов в памяти, таким образом (exe)TBitmap <> (dll)TBitmap и соответственно имеют различные указатели на класс. Т.о. в Dll ведется проверка на принадлежность к классу TBitmap, используя ссылку на класс (dll)TBitmap, тогда как исходный был создан в exe и имеет указатель на (exe)TBitmap. Значит указатель (exe)TBitmap, для dll не является верным, что и приводит неверной идентификации. Можно с уверенностью сказать, что такая работа не предусмотрена, разработчиками делфи, хотя для простых объектов может иногда и работать. Все зависит от того какие операции производятся. Но в общем случае такая передача приведет к неопределенной ситуации. Вместо этого можно передавать дескрипторы Windows объектов, поскольку они расположены в ядре Windows и управляются при помощи функций. Еще возможен вариант, это управление через интерфейсы, т.е. все вызовы реализует исходный объект, а длл их только инициирует. И, конечно, еще вариант с BPL, вместо длл, но это уже потребует наличия библиотек rtl.bpl и vcl.bpl которые имеют немалый вес, хоть и легко архивируются. |
| Автор: bazzzman 16.11.2006, 05:12 | ||
| Эта тема уже обсуждалась: http://forum.vingrad.ru/topic-112350/hl/bazzzman/index.html Может пригодится мое мнение…  Я пришел в следующему решению:
Где Controls[1] это контрол, который добавила dll на главную форму exe. Надо использовать именно TForm(Controls[1]), is и as не работают как раз из-за разных указателей на базовый класс (о чем ты и писал). Далее можем нормально работать с with TForm(Controls[1]) как с формой. Вызывать методы, менять свойства. Решение стабильно на Delphi 7. |
| Автор: Alexeis 16.11.2006, 11:17 |
| bazzzman, Мы таким образом указываем, что вместо класса (exe)TBitmap, нужно использовать (dll)TBitmap. Вроде неплохое решение, НО! все внутренние объекты, которые могут находится в Private области связаны с классами в ExE! а не Dll. Т.е. Если мы хорошо понимаем структуру класса, то такой финт ушами сработает, но опять же в общем случае это решение работать не будет. Т.е. все же это сомнительный ход, который не стоит использовать в коммерческих разработках, потому как при сохранении интерфеса внутреннее содержимое класса может меняться время от времени. |
| Автор: bazzzman 16.11.2006, 12:59 | ||||
Я как раз работаю с родными классами VCL которые никогда меняются. Для примера: ипользую TForm, но не TMySuperForm. Добавлено @ 13:05
У меня работает очень стабильно. Я конечно использую TForm из dll по минимуму, как визуальный контейнер-транслятор контролов из dll в exe. Еще раз: работает очень стабильно D7. |
| Автор: Alexeis 16.11.2006, 16:32 | ||
 С каждой новой версией делфи, класс TForm меняется, причем иногда эти изменения весьма серьезны. За время от делфи 3 до делфи 2006 он увеличился в размерах в несколько раз. В таких условиях говорить о переносимости проектов на новую версию компилятора нет смысла. Хочется все таки подытожить. Не смотря на то, что существует возможность прямой передачи объектов из экзешника в Длл, такие операции являются потенциально опасными и не должны использоваться. |
