TMemo в DLL

← →
Novik (2006-11-28 10:38) [0]

Как мне сделать DLL, при вызове,в которой срабатывала бы функция создающая (к примеру) Memo на основной форме приложения (Как написать DLL и как вызывать я разобрался)

В эту функция однозначно что-то надо передавать: хендл формы или указатель на неё. Так вот что именно надо передавать и как это потом использовать не знаю .... поделитесь советом плз ... люди добрые! :)

← →
Сергей М. © (2006-11-28 10:47) [1]

> поделитесь советом

Поделиться-то не сложно ..

Но объясни для начала, в чем необходимость и/или видимая тобой "прелесть" реализации такой задачи ?

← →
Novik (2006-11-28 10:54) [2]

надоело перекомпилировать основной проект. хочу сделать добавление всяких формочек, кнопочек с помощью автоматически подключаемых DLL

← →
Novik (2006-11-28 11:33) [3]

← →
Сергей М. © (2006-11-28 11:40) [4]

про ShareMem читал ?

← →
Novik (2006-11-28 11:59) [5]

неа ... точнее, слышал, но оно то тут каким макаром ??? использовать единое адресное пространство ?

← →
Сергей М. © (2006-11-28 12:11) [6]

> оно то тут каким макаром ?

Хост-приложение и DLL должны использовать единый экз-р менеджера памяти.
А это достигается либо использованием ShareMem во всех взвимодействующих модулях либо сборкой каждого из этих модулей с рантайм-пакетами, что не всегда удобно.

← →
Novik (2006-11-28 15:26) [7]

Спасибо, пошел читать!

← →
Novik (2006-11-29 09:33) [8]

Ну вот, прочитал, сделал и появляются новые вопросы ...
в некоторых случаях программа при выполнении выдает вот такое добро:
"cannot assign a TFont to a TFont". Как мне с этим бороться ???? Эта ошибка выдается когда я в dll при создании memo указал родителя форму, которая передается по указателю ... если убрать memo.parent то ошибки нет, но и memo на форме не видно, даже если принудительно указать свойство visible в тру. Так же, я проверял meo наличие как токовой перебирая components формы - она создается! Но почему её не видно и почему она выдает такую ошибку ?

← →
Сергей М. © (2006-11-29 09:36) [9]

> сделал

Сначала рассказывай, как сделал - ShareMem ? Build with Run-Time Packages ?

← →
Novik (2006-11-29 09:39) [10]

в секции uses первым указал ShareMem как в приложении так и в dll. на счет "Build with Run-Time Packages" - ничего в настройках не трогал и компилиться по умолчанию (как оно есть в настройках)

← →
Сергей М. © (2006-11-29 09:43) [11]

Пробуй иначе - убери ShareMem и установи опцию BwRTP в св-вах обоих проектов ...

← →
Novik (2006-11-29 09:46) [12]

Во! так работает! но а как же быть если, например, человек пишет DLL не на дельфи а, например, на каком-нить "нетривиальном" С++

← →
Novik (2006-11-29 09:48) [13]

как же быть с универсальностью DLL? т.е. какие требования к компиляции DLL на других ЯП возникают ??? Тем более как я смогу запустить данную программу на машине без предустановленных библиотек (VCL) ??? ругнется же при запуске ....

← →
Сергей М. © (2006-11-29 09:49) [14]

> а как же быть если, например, человек пишет DLL не на дельфи
> а, например, на каком-нить "нетривиальном" С++

А откуда в "нетривиальном" С++ возьмутся TMemo, TForm, TApplication и иже с ними ?
Это же Делфи-классы ...

← →
Novik (2006-11-29 09:53) [15]

то что это дельфи классы - понятно, но можно же компилить так, что все библиотеки, в которых описаны эти классы "приаттачивались" к основному проекту! В этом и есть вся прелесть, к примеру, однин модуль написан на Delphi, а другой на С++. Зачастую это даже удобно, т.к. некоторые вещи вообще могут отсутствовать в дельфи и присутствовать в других ЯП.

← →
Сергей М. © (2006-11-29 09:53) [16]

> как же быть с универсальностью DLL?

С "универсальностью"-то как раз все в порядке.

Но ведь ты ведешь речь об "основной форме приложения" как о форме именно Делфи-приложения ! И задуманное тобой тут же теряет смысл, когда хост-приложение не является Делфи-приложением или BCB-приложением ..

← →
Сергей М. © (2006-11-29 09:56) [17]

> библиотеки, в которых описаны эти классы

Что С++-программа будет делать с Делфи-классом ?
Это же совершенно разные среды программирования ...

← →
Novik (2006-11-29 09:57) [18]

тогда как мне реализовать хост приложение??? допустим, что даже сделаем какой-то стандарт для подключения независимых DLL так, как это реализовано, например, с RunDLL.exe. Ведь можно определить что функция вызова должны быть такой-то, параметры должны быть такими и т.д. Для меня самое главное взаимодействие данных DLL между собой и хост приложением.

← →
Novik (2006-11-29 09:59) [19]

>>Что С++-программа будет делать с Делфи-классом ?
>>Это же совершенно разные среды программирования ...

согласен, но ведь можно реализовать дельфи класс внутри DLL (описать его и т.д.) а основному приложению пофиг - она вызывает функцию, к примеру, InitDLL передает ей что-то, та сама всё делает и передает одратно что-то (это что-то я собирался реализовывать через указатели)

← →
Anatoly Podgoretsky © (2006-11-29 10:02) [20]

> Novik (29.11.2006 09:46:12) [12]

А очень просто, не использовать ничего кроме Pure C для передачи данных туда и обратно, а если еще и для Фортрана, то вообще ничего кроме указателей.

← →
Anatoly Podgoretsky © (2006-11-29 10:03) [21]

> Novik (29.11.2006 09:48:13) [13]

Для запуска программы никаких предустановленных библиотек (VCL) не требуется
Требования простые чистый Си

← →
Anatoly Podgoretsky © (2006-11-29 10:04) [22]

> Novik (29.11.2006 09:53:15) [15]

Можно, только зачем для этого ДЛЛ
Чтобы потрахаться?

← →
Anatoly Podgoretsky © (2006-11-29 10:04) [23]

> Сергей М. (29.11.2006 09:56:17) [17]

Что другая программа будет делать с С++ классом?

← →
Anatoly Podgoretsky © (2006-11-29 10:06) [24]

> Novik (29.11.2006 09:59:19) [19]

Указатели на что, не говори загадками.
Но вижу у тебя большое желание походить по граблям, тем более не понимая, что это грабли.
Барабан на шею, палочки в руки и вперед.

← →
Сергей М. © (2006-11-29 10:07) [25]

> тогда как мне реализовать хост приложение?

Вот так как ты его сейчас реализовал, так и реализуй - ведь работает же ! А лучшее, как известно, - враг хорошего)..

> Для меня самое главное взаимодействие данных DLL между собой
> и хост приложением

До тех пор, пока речь идет об одинаковых средах разработки взаимодействующих модулей, нет никаких проблем в достижении этой цели. И ты в этом убедился.

представь себе, что твоя "стандартная" DLL-функция объявлена так:

function CreateMemo(ParentForm: TForm): Boolean;

Что сишное хост-приложение будет делать с этой ф-цией ? Оно же понятия не имеет, что такое TForm ! Равно как не имеет понятия о Делфи-классах вообще !

← →
Novik (2006-11-29 10:08) [26]

просто сколько я не делал приложения, всегда приходилось вносить в него коррективы (по надобности, со временем). надоело мне постоянно перекомпилировать всё это добро, вот я и решил организовать работу программы за счет подключаемых модулей. Удобно: надобность в одной функции программы отпала - удали ДЛЛ, надо что-то новое, напиши ДЛЛ и кинь в папку

← →
Сергей М. © (2006-11-29 10:10) [27]

> передает ей что-то

В твоем случае - это "что-то" должно быть указателем на объект класса TForm.
Но никто кроме Делфи и ВСВ об этом классе ничего не знает.

← →
Novik (2006-11-29 10:11) [28]

так, если объединить все разговоры выше, к чему мы можем придти ???? как начинать "стройку", какой фундамент "ложить"???

> Novik (29.11.2006 10:08:26) [26]

Надоело, решил потрахаться, заодно пусть и пользователи помучаются.
А удалить exe религия не позволяет?

> Novik (29.11.06 10:11) [28]

> к чему мы можем придти ?

К тому что конкретно поставленная тобой задача реализуема лишь при разработке взаимодействующих модулей не иначе как в Делфи/ВСВ. Ты в этом убедился.

Как только вместо Делфи (или ВСВ) начинает фигурировать любая иная среда, решение задачи теряет всякий смысл, не говоря уже о ее решаемости в том или ином хотя бы ограниченном виде

← →
Novik (2006-11-29 10:15) [31]

>> А удалить exe религия не позволяет?

это как ?

> Novik (29.11.2006 10:15:31) [31]

> это как

А это точно также как с длл, OldDll=NewDll, OldExe=NewExe
Но никакого DLL ада

> это как ?

Shift+delete.

А если в dll реализовывать не компоненты, а скажем модули целиком. Потом передовать в длл значения для обработки, обрабатывать уже на форме из длл, и возвращать обратно в основную программу. Это как подключаемые модули в фотошопе.

← →
Novik (2006-11-29 11:43) [34]

спасибо. получил исчерпывающие ответ ....

еще один путь к универсальности - передавать в DLL не указатели на классы, а хэндлы окон, HWND
Тогда дельфовое приложение может сделать CreateParented, ну а сишное, к примеру просто CreateWindow

← →
Novik (2006-11-29 11:56) [36]

ну есть у меня такая идея - передавать хендл. но чем CreateParented отличается от простого Create ?

> передавать в DLL не указатели на классы, а хэндлы окон

Здесь ждет засада : хост-приложение вправе передать хэндл "чужого" окна или же своего, но созданного в ином код.потоке, нежели поток в котором вызвана dll-функция, призванная создать окно

TMemo в DLL Найти похожие ветки