Подводим итоги. Ниже описан порядок

Подводим итоги. Ниже описан порядок разработки пользовательского приложения, им-портирующего функции из динамически подключаемой библиотеки функций:

С помощью DllWizard генерируем включаемые модули
В проект включаем сгенерированный модуль Example_Load.cpp
"Бросаем" на главную форму компоненту TAskDll и в её свойстве DllName указы-ваем имя DLL-ки (см.Рисунок 3)

В модуль главной формы и во все модули, в которых предполагается использовать импортируемые из DLL функции, включаем заголовочный файл Example_Extern.h
Пишем пользовательский код и компилируем проект. Всё! Скриншот работы тес-тового приложения приведён на Рисунок 4

Рисунок 4

9 октября 2001 г
Специально для
Скачать архив: (92 K)

Примечания

(1) — кстати, компиляция приложения и dll с пакетом vcl50 полностью снимает проблему дочерних окон и использование менеджера памяти BORLNDMM.DLL (подключение ShareMem) становится не только не нужным, но и опасным .
(2) — как ни странно, но и от Microsoft бывает что-нибудь хорошее…
(3) — когда одно приложение управляет другим или позволяет себе "уведомлять"другое приложение о своих событиях
(4) — когда приложения выполняются на разных компьютерах в локальной сети (или internet) и взаимодействуют друг с другом.
(5) — подробнее о VMT будет рассказано далее.
(6) — если произойдет "сдвиг" VMT, последствия могут быть непредсказуемыми -но фактический вызов будет неверным.
(7) — когда один пакет ссылается на другой, а тот, в свою очередь, на третий, а тот …
(8) — только выполняют при загрузке дополнительную работу
(9) — кстати, использование TActionList довольно хорошая практика
(10) — New/Package
(11) — объектно-ориентированное программирование
(12) — так называемый GUID - глобальный уникальный идентификатор
(13) — я всегда испытываю некоторый скепсис, когда слышу про то, что чего-то "нам надолго хватит". В памяти еще остались ощущения от программирования под 16 разрядные среды (DOS и Windows) с 64k барьером и 640k общей памяти (которой, по тогдашнему мнению Microsoft, должно было хватить надолго). Но, как мне кажется, возможностей GUID, по крайней мере, на наш век хватит. Тем более в пределах одного приложения.
(14) — функция QueryInterface более подробно обсуждается далее
(15) — кстати, возникновение такой ситуации свидетельствует о плохом проектировании программы и следует пересмотреть всю идеологию системы в целом.
(16) — в виду отсутствия в Delphi механизма множественного наследования, агрегация (то есть включение одного объекта в другой с транспортацией его свойств и методов в объект-контейнер) довольно часто применяется в Delphi.
(17) — в частности, при переводе компонента в элемент ActiveX
(18) — вместе с _AddRef и _Release она реализует интерфейс IUnknown, являющийся базовым интерфейсом для всех остальных интерфейсов (как TObject является базовым классом для всех классов Delphi). Для любителей порассуждать о том, какой язык лучше вот информация к размышлению: для реализации механизма интерфейсов (да и, пожалуй, полностью всего COM) в C++ (причем в классической реализации по Страуструпу) не нужно ничего, кроме быстрых и умелых рук. Тогда как в Delphi Object Pascal потребовалось для его поддержки пришлось вносить изменения в сам язык.
(19) — допустим, IUnknown
(20) — включая получение интерфейса IUnknown.
(21) — но следует более тщательней подходить к реализации пакета базовых классов. То есть нужно постараться предусмотреть все, что только можно, ибо после запуска проекта в самостоятельное плавание малейшее изменение в этом пакете может потребовать перекомпиляцию, причем как основного приложения, так и всех без исключения plugin's
(22) — правда, особого смысла я в этом не вижу
(23) — а вот это может оказаться полезным (одна интеграция с MS Office'ом стоит многого)
(24) — Библиотека поддержки COM в Delphi это использует на полную катушку
(25) — пока не будет проинициализировано внутренне поле FVCLComObject TComponent. А это случится только при создании на основе TComponent ActiveX объекта.
(26) — если вы не хотите все испортить :)

Содержание раздела