Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Про размещение класса в пакетах, DLL'ках и т.д. [D7, Win95/98, WinME, NT4, Win2k, WinXP]


_Seldon_ ©   (2005-08-14 16:53:00) 

задача: есть некий абстрактный класс, используется он для прорисовки некоторых частей интерфейса. И есть множество классов-наследнико от него, реализующих тот или иной способ отрисовки. Эти классы-наследники и другие части программы совместно используют некоторые модули. Нужно теперь вынести каждый класс-наследник в отдельную DLL'ку и обеспечить возможность подключения их к основной программе.
1) Делал через пакеты (используя LoadPackage) - работает, но мне очень не нравится, что если пакет с классом отмечен в Projects\Options\Packages как runtime пакет, и он требует, допустим, пакет Vcl70.bpl, то он (Vcl70.bpl) тоже считается runtime пакетом и не линкуется к exe файлу. {1} К тому же получается, что программа будет работать только с теми пакетами, которые извесны на момент компиляции и указаны в Projects\Options\Packages. Если же не указывать пакет, то не работает (скорее всего по причине, что и обычная DLL - см. ниже) {2}
2) Делал через обычные DLL'ки: не работает по причине того, что модули, используемые совмесно программой и классом, лежащим в DLL, дублируются и по сути основная программа и DLL используют совершенно разные модули. {3}

Сейчас вижу один выход: избавится от совместного использования модулей или сделать интерфейс для доступа DLL'ок к модулям основной программы. И то и другое очень трудоемко.

Отсюда вопрос: как ещё можно решить эту задачу? Можно ли обойти {1}, {2} или {3}?


tesseract   (2005-08-15 10:39:00) [1]

Темы? - ресурсы что-ли ?  а как это к классам относится? хочешь просто как ресурсы в dll запихать так в чём проблема поиск по форуму даст кучу ответов.


_Seldon_   (2005-08-14 22:29:00) [2]


> Во блин даёшь DLL чихать хотела на локальные переменные
> приложения, общие там юниты или нет у неё "относительно
> своё" адресное пространство и локальные переменные свои
> для каждой instance. Ты думаешт почему в вин апи каждый
> раз надо дескриптор чаго-нибудь передавать?
дык я про это и говорил, только более простым языком :)


>  У меня был такой же период (лет пять назад студентом) после
> этого честно решил что без геммороя жизнь светлее а пиво
> вкуснее....
хе-хе :) дык не я это всё писал, если интересно, я хочу темы TBX (аддон к Toolbars2000 - g32.org) перенести в dll'ки...


tesseract   (2005-08-14 17:33:00) [3]

>>>в программе написано uses Unit1; и в Dll тоже самое написано. и если программа вызовет процедуру из этого юнита, меняющую например локальную переменную этого юнита, то Dll об этом не узнает и в её копии юнта эта переменная будет иметь старое значение

Во блин даёшь DLL чихать хотела на локальные переменные приложения, общие там юниты или нет у неё "относительно своё" адресное пространство и локальные переменные свои для каждой instance. Ты думаешт почему в вин апи каждый раз надо дескриптор чаго-нибудь передавать?

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


_Seldon_   (2005-08-14 17:21:00) [4]


> Для решения этой проблемы изобрели COM

COM не знаю совсем :) но видно придётся выучить


> Избавится от совместного использования модулей - оптимальный
> вариянт,

ага, тока там переписывать дофигища придётся...


> ЗЫ это как это программа и DLL используют разные модули
> и при этом дублирующиеся модули?????

в программе написано uses Unit1; и в Dll тоже самое написано. и если программа вызовет процедуру из этого юнита, меняющую например локальную переменную этого юнита, то Dll об этом не узнает и в её копии юнта эта переменная будет иметь старое значение


tesseract   (2005-08-14 17:02:00) [5]

А зачем тебе этот гемморой? Для решения этой проблемы изобрели COM и ActiveX. И подумая внимательнее :
1. Такое решение не снизит ни объём занимаемой памяти ни размер исполнимого модуля (в целом) а ИМХО даже увеличит и то и другое.
2. Избавится от совместного использования модулей - оптимальный вариянт, избавит от 70% лишнего геммороя при синхронизации и памяти сильно не сожрёт (классы то все в Delphi динамические)

ЗЫ это как это программа и DLL используют разные модули и при этом дублирующиеся модули?????


Наверх

Титульная страница Поиск, карта сайта Написать письмо