tsdima, согласен формы для Dll нужны. Да и решение предлагалось очень давно тов. -=Dima=- пример в DllForm.rar. Помниться еще было бурное обсуждение.

Осталось выяснить: а решение ли это

да и выяснять не надо: не было это решением и не будет.


единственный способ сделать это - подключить VCL. Что за этим последует думаю говорить уже не стоит.

Поэтому верным решением будет создание некоторого интерфейса. Возможно даже написание спец библиотеки визульных компонент, который при создание получает Handle реального элемента управления и далее адресует все запросы именно ему.

Обоснуй.


А чё, нельзя перекрыть TControl.CreateWindow и сначала fHandle присвоить? Он-же protected.

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

tsdima, с нотификациями чего делать будешь
В случае даже подключения VCL запросто прилетят проблемы из-за разных версий компилятора для парента и чайлда.

Не скажу что в принципе не решаемо, но уж точно не радиолюбительскими методами.
Притулил детальку - ура, вроде работает

Вот вот. А если этого мало покажется, можно еще микшировать формы VCL с формами KOL и тогда жизнь скучной не покажется.

Ребяты, вы чего? Какая связь? На уровне окон единственное, что может сделать среда - это послать сообщение окнам-детишкам панели, что её размеры поменялись, и то, только если это встраиваемая в среду док-панель.

Вот вам пример, сделан вообще не на Delphi, а на VC++, закиньте в каталог HiAsm, запустите HiAsm и вставьте вот это
и будет вам щастье

P.S. Аттач ниже

чего-то не вижу такового

Но вопрос ДАЖЕ не в этом.
Нет сомнения, что можно сделать библиотеку, которая не использует "нестандартные" указатели.
Так же, как нельзя создать объект в dll-ке, а уничтожить в головной (что Dilma давно и безуспешно пытается делать используя Jpeg.dll)
Но можно так делать, если при создании/уничтожения используется winApi (применительно к Jpeg.dll надо просто принимать из нее "голый" HBitmap, который уничтожается через deleteobject - и всего делов)

На KOL-овском форуме, кстати, давно мусолят тему плагинов.
например http://www.delphimaster.ru/cgi-bin/forum.pl?id=1177917769&n=10
Но именно "мусолят". Как-то с продуктивными идеями там не очень

Вопрос там не в том - можно ли сделать в принципе, а как это успешно притулить к TControl, который попытается отыскать applet-а, найти PControl у parent-а, будет ждать по-глупости, что этот parent пришлет нотификации через CN_XXX-сообщения.
Ну и т.п..
Кстати говоря, какой-нибудь "прогресбар" в панели "статусбара" - тот же "плагинчик"

Вообще-то я думаю, что тут и в KOL (именно про него говорю, а не в теории) возможно универсальное решение:
Надо создать некий TControlEx, который детишками неотличим от TControl, но заточен под parent-а именно в виде виндячего хэндла.
Он с parent-ом общается по виндячим правилам (как в случае формы, так и "панели"), с детишками - по KOL-овским
Он является applet-ом для кода dll-ки...

Ну, собственно, такое может быть только началом для размышлений

В СОМ-е сплошь и рядом: нужно лишь иметь интерфейс, понятный всем, и виртуальный Release в нём.


Тому, кто придумал это окно нулевого размера - нужно засунуть нескажу что, нескажу куда.


А если детишка попросит parent-а parent-а?

[size=-2]------ Добавлено в 23:26

Действительно, я и забыл, что у всех в настройках Русский выбран
Чтобы щастье увидеть, надо English включить, там окно по заголовку ищется

Не ври.
В COM-е и конструктор и деструктор находятся в одном месте. Всегда.
И "виртуальный" - это cpp-шное слово, не COM-овское.
Вроде


Вопрос не в размере, а в том, что есть некий внутренний интерфейс, АБСОЛЮТНО не заточенный под инородцев.


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


Щаз.
У меня других проблем нет, конечно
Пока у меня HiAsm не видит ни точек, ни иконки этой dll-ки

аналогично

Это неинтересно - исходники давай

Да пжалста:
code_1376.txt

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

PS: на всякий случай напомню, что в мире VisualStudio такой проблемы никогда не было т.к. там давным давно придумали делать формы через CreateDialog с интерфейсом из ресурсов, которые полностью управлялись через WinAPI и поэтому стабильно работали при создание из любых мест в рамках одного приложения.
И никогда мы не сделаем инжектирование в виртуальные пространства(VCL и KOL) со своими правилами той малой кровью, которой тут предлагается.