Создание интерфейса с помощью различных DLL

← →
Piter © (2005-10-04 22:29) [0]

Хочется рассмотреть плагиновую программу...

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

Например, в программе создается окно (главная форма приложения). Может ли, например, DLL"ка создать на этом окне ToolBar? Нужно ли ей что-то, кроме Handle главного окна?

Я сейчас про VCL не говорю - плагин ничего не знает о том, как сделано главное окно. Для плагина - это просто Windows контрол.

Например, если окно создано любым способом (хоть VCL, хоть вчистую на WinApi) - плагин, имея Handle окна, может на нем "изобразить" ToolBar? А другие элементы, типа панелей, Edit, GroupBox и т.д.?
Есть ли тут какие подводные камни?

← →
Kerk © (2005-10-04 23:21) [1]

ActiveX

← →
Profi © (2005-10-05 00:45) [2]

Piter © (04.10.05 22:29)
Я с этим уже полгода р=парусь. Пытаюсь добиться полной свободы действий в plugin"ах. Даже книжку по com купил. Но пока почти безрезультатно!

← →
GuAV © (2005-10-05 00:53) [3]

> Я здесь подводных камней не вижу,

Align ?

← →
Piter © (2005-10-05 01:03) [4]

Kerk © (04.10.05 23:21) [1]

я, конечно, понимаю, что краткость - сестра таланта, но не в данном случае :(

← →
Piter © (2005-10-05 01:08) [5]

GuAV © (05.10.05 0:53) [3]
Align ?

идею понял, но не до конца. Я просто не знаю как реализован Align... Он чисто VCL ориентированный или он какими-то WinApi методами проверяет - какой контрол на компоненте?

← →
DiamondShark © (2005-10-05 01:14) [6]

> Я здесь подводных камней не вижу

А я вижу. Например, разная RTTI для классов в DLL. Грабельки ещё те.

← →
GuAV © (2005-10-05 01:25) [7]

Piter © (05.10.05 1:08) [5]

> Я просто не знаю как реализован Align...

См. source\vcl\Controls.pas - всё чисто VCL.
Вообще думаю всё делается, если контрол в приложении представлен и в dll представлен разными экземплярами наследников TWinControl с общим HWND.

DiamondShark © (05.10.05 1:14) [6]

> Например, разная RTTI для классов в DLL. Грабельки ещё
> те.

см.

> плагин ничего не знает о том, как сделано главное
> окно.

← →
Piter © (2005-10-05 01:36) [8]

DiamondShark © (05.10.05 1:14) [6]
я вижу. Например, разная RTTI для классов в DLL

ты не понял. Никакой VCL ориентированности. Плагин должен, например, уметь располагать контролы на главной форме, имея только ее Handle, то есть имея о ней информацию только как о Windows элементе...

GuAV © (05.10.05 1:25) [7]
если контрол в приложении представлен и в dll представлен разными экземплярами наследников TWinControl с общим HWND.

да нету VCL!!! Плагин может и на C++ написан быть.

Давайте тогда вот так - чтобы проще представлять.

Допустим, приложение создает главную форму, все написано на Delphi.

Каким образом написать плагин на C++, чтобы он смог реализовать ToolBar на этой форме?

← →
DiamondShark © (2005-10-05 01:38) [9]

> > плагин ничего не знает о том, как сделано главное
> > окно.

А, ну тогда ещё ничего.

Правда, я сталкивался с тем, что VCL-ные окна не очень любят не знать, как сделано главное/родитеское окно.
Или я просто не умею их готовить?

← →
Германн © (2005-10-05 01:42) [10]

2
> Piter © (05.10.05 01:36) [8]
>
> DiamondShark © (05.10.05 1:14) [6]
> я вижу. Например, разная RTTI для классов в DLL
>
> ты не понял. Никакой VCL ориентированности. Плагин должен,
> например, уметь располагать контролы на главной форме,
> имея только ее Handle, то есть имея о ней информацию только
> как о Windows элементе...
>
> GuAV © (05.10.05 1:25) [7]
> если контрол в приложении представлен и в dll представлен
> разными экземплярами наследников TWinControl с общим HWND.
>
>
> да нету VCL!!! Плагин может и на C++ написан быть.
>
> Давайте тогда вот так - чтобы проще представлять.
>
> Допустим, приложение создает главную форму, все написано
> на Delphi.
>
> Каким образом написать плагин на C++, чтобы он смог реализовать
> ToolBar на этой форме?

Тогда объясни, пожалуйста, одновременное наличие термина форма и нету VCL!

← →
GuAV © (2005-10-05 02:04) [11]

Случай со вставкой неизвсетно чего в дельфи-форму на самом деле не такой уж сложный. См. TButton, TMemo, etc... они могли бы ничего не знать о сообщениях соотв контролов и при этом кидались бы на форму точно так же. Чтобы перейти от создания по имени класса к явному вызову функции (думаю, это надо), думаю достаточно наследоваться от TCustomControl и перекрыть все методы создания-пересоздания окна.

Что насчёт вставки VCL неизвестно куда - с этим похуже, согласен с DiamondShark © (05.10.05 1:38) [9]. Можешь например посмотреть winamp sdk для delphi - автор порта на delphi нашел некоторые необъяснимые глюки некоторых VCL контролов...

← →
Piter © (2005-10-05 02:30) [12]

Германн © (05.10.05 1:42) [10]
Тогда объясни, пожалуйста, одновременное наличие термина форма и нету VCL

ооох... где я говорил, о том что VCL не используется?

Я говорил о том, что плагин как бы он не был реализован ничего не знает о других компонентах, как бы те не были реализованы. Знания только на уровне Windows контролов. Если это окно - то имеется ее Handle и все.

Для примера рассмотрим такую ситуацию.

Есть главная форма приложения - реализована с помощью VCL.

Реально ли написать DLL модуль на VC, который будет на этой форме отвечать за реализацию ToolBar?

В теории это возможно. Для связки Windows контролов, по идее, ничего кроме Parent, то есть Handle владельца, знать не надо. Но это в теории.

Хотелось бы узнать о подводных камнях. Как отнесется VCL компонент к тому, что на нем будет размещен WinApi контрол без всякого намека на VCL?

Один моментик уже был указан - это потенциально неправильная работа свойства Align, так как в общем в VCL, имхо, не предусмотрено, что на VCL компонентах могут распологаться НЕ VCL контролы. То есть, с точи зрения ОС - это реально и ей все равно, на каком языке созданы контролы. А вот VCL наверняка не все равно...

← →
ЦУКОР5 (2005-10-05 02:59) [13]

Вот еще одна проблема :
http://delphimaster.net/view/1-1128448523/

← →
Piter © (2005-10-05 03:19) [14]

ЦУКОР5 (05.10.05 2:59) [13]

Даст ис ноу праблем. Даст ис детский лепет :)))

← →
Мексиканец © (2005-10-05 04:34) [15]

Вообще то трудоемко будет. Не используй вообще VCL, только API. Как пример создается главное окно которое после создания вызывает функцию из длл, допустим ее название CreateWindowControl. Данная функция получает в качестве параметров хендл окна. Далее создаются контролы. После этого главное окно вызывает функцию UpdateControl которая рассчитывает размер и размещение контролов и посылает им сообщение об изменение размеров и положения. Далее вызывается ShowWindow()для созданных контролов. Далее в главном окне отслеживаешь, сообщения изменение размера главной формы и в случае возникновения такового вызываешь функцию UpdateControl. Плюсы в том, что прога будет оч.маленькая. Сообщения от контролов можешь обрабатывать как в длл так и в самой проге, как пожелаешь.
PS:В качестве формы для размещения контролов может быть обычная VCL форма.

← →
Мексиканец © (2005-10-05 04:43) [16]

В общем, не знаю, актуально ли это для твоей задачи, но таким образом создается поддержка плугинов.

← →
Piter © (2005-10-05 09:56) [17]

Мексиканец © (05.10.05 4:43) [16]
В общем, не знаю, актуально ли это для твоей задачи, но таким образом создается поддержка плугинов

кем создается? :)

Про Align я понял... Есть еще какие грабли?

← →
Игорь Шевченко © (2005-10-05 10:00) [18]

Грабли обычно одни - либо не используешь VCL и тогда размер кода несколько возрастает, либо используешь VCL и наслаждаешься всеми перечисленными проблемами.

← →
Piter © (2005-10-05 17:55) [19]

Игорь Шевченко © (05.10.05 10:00) [18]

Отказаться от VCL сложно :(

Например, реализовать аналог TWebBrowser... это уже тянет на отдельную программу имхо...

← →
Piter © (2005-10-05 18:06) [20]

Игорь Шевченко © (05.10.05 10:00) [18]
либо используешь VCL и наслаждаешься всеми перечисленными проблемами.

а какими проблемами? Фактически, перечислены только одни - это Align... а еще?

← →
Суслик © (2005-10-05 18:23) [21]

почему бы не юзать bpl и знать про vcl.

← →
Суслик © (2005-10-05 18:28) [22]

может еще проблемы с клипингом быть.
Я в последнее время много смотрел кода controls.pas у них по поводу клипинга много чего сделано. Если не ошибаюсь они часто оперируют controls для расчета клипинга. А твоего контрола в controls нет.

А вообще - проведи опыт. Нам расскажешь.

← →
Piter © (2005-10-05 19:00) [23]

Суслик © (05.10.05 18:23) [21]
почему бы не юзать bpl и знать про vcl.

потому что плагины то кто хочет может писать и на каком хочет языке.

Суслик © (05.10.05 18:28) [22]
у них по поводу клипинга много чего сделано

что такое клипинг?

← →
DiamondShark © (2005-10-05 19:07) [24]

Тогда лучше делать интерфейс к плагинам таким образом, чтобы плагины вообще не занимались созданием каких-либо оконных вещей, а только поставляли данные для их создания.

В качестве первого приближения можно посмотреть как сделаны shell extensions или MMC snapins.

← →
Profi © (2005-10-05 19:11) [25]

Когда я парился с этой проблемой, то дошел то того, что:

1. Создать какой-либо control на форме не проблема.
2. Проблема обработать событие от него (например, нажатие кнопки).
3. Чтобы plugin мог делать все, что хочет, надо ему разрешить это делать (описать все возможные способы ручками)

Надеюсь, что на счет третьего пункта я ошибаюсь!

← →
Kerk © (2005-10-05 19:19) [26]

Piter © (05.10.05 1:03) [4]
я, конечно, понимаю, что краткость - сестра таланта, но не в данном случае :(

Имею ввиду почему не использовать ActiveX? Зачем изобретать велосипед?

DiamondShark © (05.10.05 19:07) [24]

не очень гибкий подход. Элементарный пример - вдруг кто захочет сделать красивый Toolbar вместо стандартного?

Я тоже хотел сначала сделать что-то типа прокладки API к стандартным VCL контролам - плагины только управляют компонентами... но все таки это ограничивает фантазию...

Profi © (05.10.05 19:11) [25]
Проблема обработать событие от него (например, нажатие кнопки).

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

Kerk © (05.10.05 19:19) [26]

ActiveX все таки разработана для межпроцессорного взаимодействия. Не хочется городить такой огород внутри одного процесса.

> ActiveX все таки разработана для межпроцессорного взаимодействия.
> Не хочется городить такой огород внутри одного процесса.
>

Это чересчур смелое заявление

Игорь Шевченко © (05.10.05 20:54) [28]
Это чересчур смелое заявление

Хм, я был в этом практически уверен.

То есть, вы хотите сказать, что ActiveX задумывался и как средство взаимодействия контролов в ОДНОМ ПРОЦЕССЕ? То есть, этот контрол будет использован только одним процессом, одной конкретной программой и при этом он глобально регистрируется в системе?

Как-то непродуманно - не находите?

Profi © (05.10.05 21:05) [29]
Тебе придется описать обробутку события в интерфейсе

не понял мысли. Что ты называешь интерфейсом?

Piter © (05.10.05 21:48) [30]
Интерфейс - связь между программистом и компилятором. Ты реализуешь методы, которые тебе нужны и описываешь их в интерфейсе, а компилятор создает структуры позволяющие обращатся к этим методом из любого приложения поддерживающего этот же интерфейс.
Опять же, ты реалезуешь. Если ты что-то не реализуешь, то и plugin не сможет сделать этого.

Piter © (05.10.05 21:48) [30]

> Хм, я был в этом практически уверен.

А ты Елманову, Трепалина и брата их во христе Тенцера почитай, уверенности будет куда как больше.

> То есть, этот контрол будет использован только одним процессом,
> одной конкретной программой и при этом он глобально регистрируется
> в системе?

Вот, например, контролы Edit и ComboBox используюся конкретными программами, глобально зарегистрированы в системе, но назвать взаимодействие с ними межпроцессным, язык не повернется ни у кого.

ActiveX задумывался как средство повторного использования кода, в первую очередь.

Игорь Шевченко © (06.10.05 0:06) [32]

все понятно, просто не так выразился.
Я и имел в виду, что так сказать написанный код будет использоваться в других процессах. Причем, потенциально во многих процессах (ну да, опять криво, но возможно вы поняли).

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

Piter © (06.10.05 00:30) [33]

ActiveX определяет интерфейс, согласно которому с ним должно взаимодействовать. Как он реализован, на каком языке, взаимодействующему абсолютно все равно, главное, чтобы заявленный контракт (интерфейс) выполнялся. Это и имелось в виду, когда тебе предложили использовать ActiveX, насколько я вообще понял твою задачу.

Впрочем, если ты ее (задачу) опишеь несколько подробнее, с возможными ограничениями на взаимодействие с плагинами, весьма вероятно, что может отыскаться более оптимальный способ. А может и не отыскаться.

> [33] Piter © (06.10.05 00:30)
> У меня же случай, когда реализованный в плагине контрол
> будет использоваться всего одной программой - моей. И поэтому
> ActiveX, глобальная регистрация тут, думаю, не лучший выход.
У меня в системе куча плагинов, отчетов, "драйверов" сопряжения с внешними устройствами реализована в виде COM-объектов, которые используются только одной программой, но (потенциально) могут использоваться и другими. Плюсы - любой на любом языке расширяет мою систему под свои специфические нужды, а некоторое "захламление" HKEY_LOCAL_MACHINE\SOFTWARE\Classes вряд ли можно считать минусом.

С уважением.

Если не предполагается использование других языков - то стоит посмотреть в сторону bpl.

У меня такой вопрос, сделать форму в DLL не проблема, не проблема даже при первом запуске этой формы создать объекты в БД, т.к. в основном пишу задачи работы с БД, вопрос стоит ли так делать? Т.е. например как дело обстоит на практике.
Пишу exe, простенький. Одна MDI форма. Отдаю клиенту. Это программа минимум. Далее, что надо пользователю, он запрашивает, я ему даю dll, он ее пишет в дирректорию с программой, программа при запуске находит dll, проверяет, подходит ли эта dll к этой програме, если подходит, создает меню в гл. MDI форме, и если юзер кликает на это меню, выводится форма из dll. Если форма выводится в первый раз, создаю объекты для нее.. например программа сдачи экзамена (тест на права категории а-б-с) это минимум, то кидаем dll статистики, появляется ещё одна фишка в программе, как статистика. КИдаем dll распред. системы, программа превращается в сервер, на который можно загрузить данные с других систем для анализа и т.п.

(Помоему так же и в 1С, например в Trade.dll - часть 1С.Торговли, Salary.dll - часть 1С.Зарплаты)

Интересно, это самый универсальный вариант, как делать "универсальные" приложения, или есть какой то другой вариант? Например формы в dll хранить совсем не обязательно? А хранить только описание объектов, габариты, обработчики... Опять как разрабатывать форму, для того что бы потом сконвертить в dll...

Одни вопросы, работы с этими dll лом..

И тоже, минус такой есть, если хранишь форму в DLL, в каждой DLL есть стандартный набор USES: Windows, Messages... и поэтому размер DLL всегда от 500кб...

Создание интерфейса с помощью различных DLL Найти похожие ветки