Разрабатываю приложение, и делаю так что бы большая часть функций приложения загружалась из библиотек. В общем делаю приложение, которое может загружать плагины. Создал COM Object, который обеспечивает доступ ко всем объектам находящимся на основной форме, для этого делаю ссылки на Handle и Pointer объектов.(Для каждого объекта свой Handle и свой Pointer). В библиотеках, которые делаю, экспартирую функцию LoadPlug_in, которая вызывается при загрузке библиотеки основным приложением.
В библиотеки подключаю таблицу интерфейса основного приложения. После чего вызываю конструктор для интерфейса и зная Pointer MainMenu присваиваиваю его переменной.(см. код ниже) Создаю несколько новых пунктов меню и назначаю OnClick для этих итемов. Всё работает замечательно, но обработчик OnClick после загрузки библиотеки не работает.
Как это исправить? 
Вот например если создать в этой же библиотеки панель (TPanel) на форме и назначить обработчик OnClick, то для панели (а также и кнопку на созданную панель добавлял, которая так же реагировала на OnClick) всё замечательно. Я так понима для панели обработчик событий сохраняется то ли в потоке, то ли другой механизм, а если создать самостоятельную кнопу, то обработчик не сохраняется, как это сделать, может знает кто-то, подскажите. 
Вот мой пример, код не отимизировал, так как хочу сначала разобраться с этим вопросом
 
Библиотеку можно реализовать и в виде COM, но я пока не далёк в этой технологии, месяц как изучаю её, поэтому не знаю как это сделать. И хотел бы посмотреть пример такой реализации.   

Shtorm, объекты Application в Dll и приложении объединял уже? Очередь сообщений крутится в приложении, а Dll ничего об этом не знает. Нужно перво наперво передать объект Application из программы в Dll и там присвоить его, тогда очередь сообщений будет для них общая.

я думаю не стоит "мешать" в кучу компоненты VCL, созданные в dll и в приложении... либо использовать пакеты (bpl) и общий менеджер памяти, либо полностью абстрагированные интерфейсы.
з.ы. а присвоением объекта TApplication из приложения в dll дело не поправишь имхо

Это сообщение отредактировал(а) MetalFan - 26.2.2009, 10:41

MetalFan, конечно остаются проблемы дублирования реализаций классов и присваивание объектов TApplication является своеобразным хаком, но это иногда работает. Я пробовал более изящное решение, загрузку Dll в новом потоке, со своей собственной очередью сообщений. Т.е. изолировать 2 набора VCL. При этом Dll функционирует как отдельное приложение но с общим адресным пространством, однако при винда создает как бы 2 главных окна приложения, и каждое из них помещает свою кнопку на таскбар. Мне кажется что это также не совсем удобно.
  Вариант с bpl тоже весьма неудобен, потому что все классы, которые используются в обоих исполняемых модулях должны подключаться при помощи общих bpl, объем которых весьма велик.
  Путь интерфейсов тоже мало согласуется с VCL, потому что в библиотеке нет компонентов, которые имели бы интерфейсы содержащие большую часть public/published свойств и методов. Фактически такое программирование сводит на нет все преимущества Delphi.  

  Фактически приемлемым результатом могут быть только 2 пути.
1) Отказаться от применения VCL в Dll и от передачи объектов. 
2) Отказаться от взаимодействия VCL в Dll и VCL в приложении или свести это взаимодействие к минимуму (объединив очереди сообщений для работы механизма сообщений + объедение куч).

Нет этого я не делал, как это можно реализовать? Использовать ShareMem? Или что-то другое?
Да и инетересно почему например при создания OnClick вот примерчик (чуть и зменил тот что выше)

Работает как нужно. Думаю понятно, что делаю, создаю панель, на панели основного приложения, на созданной панели добавляю кнопку и назначаю обработчик Btn_Pan.OnClick := BtnDo.Btn_Click; 
Какой тогда механизм использует ТPanel для этих дел и почему работает? 
 А как объединить очереди сообщений? Или это и есть момент с использованием общего менджера памяти?

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


  Все, кажется понял в чем прикол.

Скорее всего пункты меню создаются в Dll примерно таким образом



  Т.е. имеем стандартную схему конфликта 2х различных реализаций VCL или Dll и приложения.

    Для правильного решения такой задачи лучше перенести код CreateMenuItem из Dll в приложение, тогда будет создан правильный экземпляр TMenuItem класса расположенного в приложении. Тот что создается в Dll (TMenuItem) для MainMenu1 из главного приложения является как бы не родным. 

  Короче совет остается тем же не смешивать объекты из Dll и программы. При их смешивании результат будет непредсказуемым.

Таким образом, лучше например предусмотреть в приложение создание объектов, и вызывать эту функцию в dll например с координатами обьекта. Ну это для обычных Butoon а для меню тоже написать свою функцию. И например что бы эта функция возвращала Handle или Pointer созданного объекта, после чего назначить ему обработчик.

Да, действительно, если создавать объекты внутри приложения вызывая для этого функцию и возвращая Pointer созданного объекта, всё работает без проблем. Спасибо 
Alexeis, первоначально я хотел создавать так объекты, но думал пускай об этом заботятся те, кто пишет под мою прогу дополнения. Прийдётся упростить немного жизнь им   Ещё раз спасибо за помощь 
Alexeis, и MetalFan. 
Приведу примерчик свой, что б если у кого возникла такая проблема мог разобраться

Код основого приложения:



Код интерфейса (так как я работаю через интерфейсы и СОМ является надстройкой над моей прогой) получаем следующее:


Ну и код библиотечки(думаю всем известно как загружать библиотеки и вызывать экспортируемую функцию)


Но один вопрос я так и не понял, почему же при создании панели TPanel и назначение ей обработчика OnClick (эта кухня вся в библиотеки происходит) всё работает нормально и не приводит к конфликтам?

  Обработчик лучше передать сразу в функцию создания. Единственное, что можно делать с полученный указателем, так это хранить его, для того чтобы потом уничтожить кнопку, если предусмотрена досрочная выгрузка плагина, если же нет, то объект прекрасно уничтожит объект (тот чей указатель передан в конструктор). Тогда и хранить ничего не нада. Можно хранить дескриптор. Он нужен в случае если захочется проделать некоторые операции при помощи WinApi функций, но это тоже весьма сомнительные операции. VCL компоненты не всегда адекватно реагируют на прямое изменение параметров api функциями. 
  Трудно назвать это удобной работой. 

  Для нормальной работы плагина придется либо передать здоровенную запись с внушительным количеством указателей на все необходимые внутренние функции или написать несколько объектов посредников и передавать плагину их интерфейсы. Это аналогично технологии COM. 


  Можно возвращать только указатели COM объектов (а не простых VCL). В этом и состоит неудобство VCL при программировании плагинов Dll.

Кстати если вопрос размера остро не стоит, может действительно задуматься о bpl? Для большого проекта 10-15Мб пакетов не такая уж внушительная цифра

Добавлено через 7 минут и 36 секунд

  При такой работе вероятность успеха 50/50. В случае с панелькой внутренние механизмы не были затронуты по этому и сработало.

  Приведенный пример также использует недокументированные возможности, потому нет гарантии что он будет работать. Где-то в разделе уже проскакивал еще один "хакерский" прием позволяющий стыковать Dll и Exe на VCL, там еще лучше были учтены внутренние механизмы работы. Но все это не переносимо, особенно если dll и exe будет писаться на разных версиях Delphi.

Я так понимаю, что бы подружить Dll и exe лучше использовать bpl. 
 вопрос размера не ставился. Только я с bpl никогда не работал и не знаю что это, Alexeis, можешь подсказать с чего начать или где почитать об этом?

У меня стояла изначально задача подружить  VCL с СОМ, решит ли этот вопрос использование bpl?   

  При использовании bpl необходимость в COM вообще отпадает. bpl представляет собой набор модулей. Эти модули можно использовать как в приложении так и в плагине, главное то что реализации классов VCL расположены в них. Т.е. и Dll и плагин будут создавать полностью совместимые объекты.
  Фактически bpl представляет собой Dll, с которой Delphi умеет правильно работать. Она экспортирует не только функции но и сами VCL классы.
  Кстати у нас на форуме есть хороший пример такой работы см. http://forum.vingrad.ru/forum/act-ST/f-84/t-157316.html

Спасибо Alexeis, я поговорю ещё с парнишкой который хотел реализовать всё с использованием COM, но думаю прийдётся всё ж возится с СОМ. Просто дело в том, что он хочет создавать плагины на разных языках и bpl я так понимаю это вещь чисто под делфу.

  Но и VCL считай тоже только под Delphi. Если нужны другие языки тогда нужно все взаимодействия делать только по средствам COM и функций.

Так и прийдётся делать,

Вот ещё момент

Самый простой пример этого можно?   , или как передавать указатель, и какой тип данных необходимо выбрать?
Это например вот так 

Shtorm, все верно Pointer это указатель, хотя насколько я помню, при работе с COM, COM объект создается функцией, а передается даже не указатель на COM объект, а один из его интерфейсов. Но можно и указатель. Если указатель, то механизм примерно такой.
  При установке прога регистрирует свой СОМ объект, а плагин будет делать примерно так


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