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



А теперь суть проблемы. Если закрыть форму, и выгрузить dll, всё будет хорошо. Но если выгружать dll не закрывая KOL форму, то вылетает ошибка и программа вырубается :( Пробовал перед выгрузкой использовать метод MyForm.Form.Close но всё равно ошибка остаётся. Пожалуйста подскажите как быть.

Никак. Проблема давно висит, и пожалуй решить (если возникнет желание) может только автор. Долго копался, но проблема, насколько понял, в том что нужно создавать новый Applet, т.е. еще один обработчик событий. Не выходит создать полностью адекватную форму из Dll. Если закрыть основное приложение до закрытия формы из Dll, то Applet из Dll остается жить своей жизнью, а в результате приложение остается висеть в памяти.

Перечитал еще раз [1] немного не в тему ответил, но ноги все равно от туда растут...

Владимир Кладов, вся надежда только на вас :-[ проясните ситуацию.

Владимир Кладов, вся надежда только на вас :-[ проясните ситуацию.

Так есть решение проблемы или нет? Скажите плз.

You could use my interceptors to trap unloadlibrary:
http://thaddy.co.uk/koldetours.zip

But that technique is not recommended (although it works!)

Я проблемы не вижу. Выгружать dll, не завершив работу с её функциями, абсолютно неверно. Это не только KOL касается. Сам недавно напарывался: если неожиданно выгрузить либу (кажется, это была opengl), то программа падает с большим грохотом при попытке обратиться к ее функциям. И это понятно: по тем адресам больше нет исполняемого кода. Вообще ничего нет. А адрес функции остался.

Давно что-то не использовал формы из dll, поэтому хочу спросить на будущее: это относится к динамически загружаемым dll или к статическим тоже? Давно как-то делал приложение, в котором статически вызывалась ф-ция с формой. Так вот все нормально открывалось и закрывалось. Но если хотя бы один раз открыть-закрыть форму из dll - основное приложение падало при закрытии себя с ошибкой 216. Вроде все делал как в примере.

Кстати эта ошибка 216 лезла раньше изо всех щелей.

Столкнулся с полностью идентичной проблемой. Использую KOL+MCK для написания плагина для RnQ (хост приложение). Вызываю окно плагина (не модально) точно так же, как в демке:



Использую вот такой код для вызова окна моего плагина:



Проблема в том, что если отключать плагин при открытой форме, то вылетает ошибка и хост приложение "умирает". А если сначала "вручную" закрыть форму и только потом отключать плагин, то всё норм. Логично, что так и должно быть и перед отключением нужно закрывать форму, но...
Перед отключением генерируется событие, что сейчас плагин будет отключен. Тут я проверяю, открыта ли форма плагина и если открыта, то закрываю её:



Как и положено, если форма закрыта, то выводится соотв. сообщение и плагин благополучно отключается. А если форма открыта, то выводится другое сообщение, но после выполнения SettingsForm.Form.Close; вылетает ошибка и хост приложение вылетает.

Ещё раз хочу акцентировать внимание на том, что если ручками закрыть форму, то никаких проблем нет. Владимир Кладов, пожалуйста помогите, ошибка точно где то со стороны Апплета.

Удалено модератором

Я как помогу, я же с плагинами не работаю. Вот я пример у себя (с полгода как или больше) положил. Там есть проблема? (А ведь там даже есть вариант с вызывальщиком на C).

PAS_VERSION - пробовали? Отлаживать, что вылетает - пробовали? Можно ведь включить пошаговую отладку со стороны DLL.

Отлаживать dll не получается. Прописываю хост приложение, включаю все необходимые опции проекта, указываю необходимые пути для исходников и тд. При запуске пошаговой отладки, через несколько секунд вылетает окошко с ошибкой "External exception EEFFACE" после чего дэльфи можно выключить только убив сам процес дэльфи.

Попробуйте другую версию Delphi. И это серьёзный совет. То, что не идёт на D7, вполне может сработать на D6, например. Кстати, включили поддержку debug dcu + информации для TurboDebuger'а (в закладке Linker)? Помогает.

Ещё одни вариант: отладка  под MS VC++. Тяжеловато лазить по дизасм-коду, но если очень хочется, то можно.

И последний вариант - логи.

Пишу под Delphi 6.

> Кстати, включили поддержку debug dcu + информации для TurboDebuger'а
> (в закладке Linker)? Помогает.

Да, конечно это включаю, но результата нет :( Мне вот что интересно, ведь если ручками закрывать форму, то всё норм. Там кнопка с полностью идентичным кодом SettingsForm.Form.Close; А вот если просто вызывать этот метод, то вылетает хост-приложение. Я уже даже попробовал извратиться и программно нажать на кнопку закрытия формы, но результат тот же :(

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

саму dll я не выгружаю (не могу т.к. хост-приложение не моё) я только реагирую на событие перед выгрузкой dll, и dll выгружается только после того, как закончится обработка данного события. Сделаю небольшую демку на VLC и посмотрю, какая будет реакция в подобной же ситуации, потом сообщу. Но всё же, мне кажется, что проблема с Апплетом.

Владимир Кладов, я проверил, с VLC таких проблем нет, никакие ошибки не вылетают т.е. код в стеке норм весь выполняется и только потом уже происходит выгрузка библиотеки. Вот основной код моей демки на VLC:



Всё прекрасно работает, а вот подобный код в KOL (чуть выше я уже писал код) приводит к ошибке и вылету хост-приложения. Владимир, пожалуйста обратите на это внимание.

Тогда я не понимаю вот это ваше утверждение (жирным - я выделил):

А теперь суть проблемы. Если закрыть форму, и выгрузить dll, всё будет хорошо. Но если выгружать dll не закрывая KOL форму, то
вылетает ошибка и программа вырубается :( Пробовал перед выгрузкой использовать метод MyForm.Form.Close но всё равно ошибка
остаётся. Пожалуйста подскажите как быть.

Я думаю, что надо сделать всё правильно. И как минимум дождаться завершения цикла обработки сообщений (условие AppletTerminated = true).

Под "выгружать dll не закрывая KOL форму" я имел ввиду, что если из хост-приложения отключать плагин (в плагин посылается сообщение, что он сейчас будет отключен. В результате чего выполняется процедура OnFinalize, в которой я проверяю, открыта или нет форма и если нужно, то закрываю форму. dll'ка не выгружается, пока весь код процедуры OnFinalize не будет выполнен), то в случае с VCL никаких проблем нет, а с KOL происходит ошибка. Попробую поэксперементировать с AppletTerminated.

А разница-то какая, закрываете вы форму или нет. Результат тот же - в стеке адрес возврата на цикл обработки сообщений Run. В общем, вы просто не пытаетесь представить себе, что происходит, кто кого и когда вызывает. Смотрите:

Главный цикл обработки сообщений в хост-приложении что-то взывал после чего загрузилась dll, сработал Run(Applet), и

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

Если такой обработчик выгрузит DLL, пусть даже вы и закроете форму, управление всё равно вернётся на код, который есть только  DLL. А раз DLL выгружена, то по этим адресам уже никакого кода нет.

И ожидание AppletTermunated в OnFinalize ничего не даст, возвращаться надо всё равно в код из DLL.

Возможное решение: Не дать выгружать DLL из хоста (например, ещё раз вызвать LoadLibrary). Пи желании выгрузиться самим можно после Run( Applet ), вызвав FreeLibrary дважды (Дважды - потому что и еслиLoadLibrary вызвана дважды). Но второй раз - только через асм, т.к. возвращаться из FreeLibrary можно будет только в хост-приложение. Обычная команда CALL неприменима, нужно в стек загнать правильный адрес возврата, и сделать Jmp. Без асм-вставки тут не обойтись.

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

Понятно. Правда в асме я не силён и вставок сделать не смогу. Да к тому же интересно, как можно из самой же библиотеки заставить программу выгрузить эту же библиотеку? Попутно возник вопрос, а как можно вообще безболезненно завершить этот цикл обработки Run(Applet) ?

Есть вариант и без асма. Запустить в потоке, пусть там крутится обработчик сообщений вместе с апплетом И тогда сразу вернётся. Надо только учесть при взаимодействии с хост-приложением, если такое есть. Ну и поток правильно завершать.

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

Хорошо, сразу после сдачи сессии попробую работу с потоками, потом отпишусь :)

P.S.
Самым минимум знания асма конечно же есть (как то даже проигрываени песенки "кузнечик" писал на чистом асме)

Владимир Кладов, так ничего и не получается :( Пожалуйста, помогите справиться с этой ситуацией. Только из-за этого бага не выпускаю плагин в паблик.

Не могу сейчас, нет Delphi под рукой. (Смешно даже).

Вообще, я так понимаю, проблема корректного завершения потока? Думаю, надо послать потоку WM_QUIT, затем сделать thread.Wait;, после чего ему можено говорить Free, и возвращаться в хост-программу.

Владимир, смотрите как я делаю:




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

Ладно посмотрю, но мне сейчас срочно надо по магазинам с семьёй - искать новогодние прибамбасы для сына типа костюма, для ёлки типа гирлянды...

Сразу: я сказал, каак правильно поток завершать. Так у вас как минимум лик ресурсов может случиться. TerminateThread - это "последний выстрел", в том числе на API если поток делается. Поток должен сам себя закончить, это единственный правильный способ.

Владимир, заменил строчку TerminateThread(HThread,0); на HThread := 0; (поток и так норм зам закрывается, в конце процедурки написано же ExitThread(0); ) В общем вроде бы сейчас всё нормально, глюков и вылетов пока не заметил. Но правильный ли подход?

Всё же оказалось не так всё гладко, как хотелось бы. Теперь после обработки события ОнДаблКлик в ListView, который находится на форме (которая вызывается в потоке) происходит ошибка, хост приложение валится или ругается на нехватку ресурсов. Возвращаю всё как было (без потоков), работает на ура :(

а что вы делаете в ondblclick?

Вызываю процедуру из плагинного апи хост приложения (вызов окна с некоторой информацией). Там ошибок точно нет.

Вот обработчик по дабл клику:



А вот сама процедура из апи хост приложения:



P.S.
В ListView находится один столбец с данными вида: Name(string)/Uin(integer)

Как я и подумал: вы пытаетесь напрямую вызывать callback в хостовом приложении. Но из другого потока этого делать не следует - последствия непредсказуемы. Вариант с потоком подойдёт только для случая, когда между формой в dll и хостовым приложением нет прямых call'ов до самого закрытия формы.

Тогда нужно искать другой выход, не через потоки. т.к. я просто не могу обойтись без call'ов. Остаётся только самый первый вариант, при котором всё отлично работает, но необходимо ручками закрывать окно. Пришли к тому, с чего начали :) Владимир, у вас есть ещё какие-нибудь предложения?

А я уже предлагал. Асм-вставкой сделать, помните?

Помню, но к сожалению мне это не по силам :(