Проблема следующего характера: Передовая в ДЛЛ данный объект и поимел проблему: при завершении приложения в главной форме не могу фрикнуть (DB.Free) объект DB=TIBDataBase. Вызывается исключение: Ошибка опирации с указателем. Соответственно, если мне не всвобождать DB (я ее создаю сам), то исключение: "приложение ххх.exe обратилось к адрессу хххх" и т.д.
Собственно вопрос: с чем это связано и как с тим бороться? Варианты типа "обработай сам это исключение" не хотелось бы слюшать.

как вариант используй CoInitialize() и CoUnInicialize(), ShareMem прописаны в главной форме и в dll

IntruderLab, Можно будет и попробовать. Я так понимаю, при передачи объекта (указателя) в длл и происходитв вся эта бодяга. В длл у меня форма и работа с базой (таблицы и т.п.). Форма вызывается модально и после высвобождается, но хвост от TIBDataBase остается. Причем, это единственный обект с такой траблой на моей памяти.
Текст в длл:



Соответственно вызов:


Весь фокус еще в том, что если фрикать в процедуре (OnCreate главной формы), где создавалась db (там же и функцию из длл вызывать) то нет проблем совсем.

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

> и в событии OnClose главной формы
> db.free;


Разве это логично ?

Уж если объект создан тобой сразу после конструирования формы (OnCreate), то и уничтожать его, очевидно, следует непосредственно перед разрушением этой формы (OnDestroy).


> DB.Create(self);


А это что еще за фигня ?
Разве DB у тебя объявлен как TComponentClass ?

> Сергей М. ©   (13.03.08 10:37) [5]


Я так понял, вы про это:
"1. В исх.кодах своих exe- и dll-проектов убираешь все касаемое параметра Appl, т.е. передача этого параметра не нужна вообще.

2. Во всех своих проектах устанавливаешь крыжик
Project->Options..->Packages->Build With Run-Time Packages
и после этого полностью ребилдишь эти проекты.

Все !! Больше никаких телодвижений делать не нужно."
Прав?
А про Крейт - дошло :). А про дестрой - пробовал - неканает.

> Прав?


Да.


> про дестрой - пробовал - неканает


Это же не редиска, чтобы "канать")

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

> Сергей М. ©

Но всеравно не совсем въезжаю - я передаю в длл Application а не ее Handle, т.е. длл полностью привязываю к смоему аплу... Т.о., как здесь: "У твоей dll св-во MainForm объекта Application равно nil.
Удивись, почеши репу, сделай выводы)" - не соответствует моему случаю. И с чаилдами у меня проблем никогда небыло... уже давно все в длл спихиваю, ну нравится мне так - легче в отладке больших проектов, а также в абгрейдах (патчах) у клиентов.
Или я что-то не допонимаю? ;)

> Или я что-то не допонимаю?


Именно.

Выполнение указанных в [4] рекомендаций приведет к тому, что у всех взаимодействующих модулей в составе приложения будут едиными (общими) объекты Application и Screen (и еще много чего).

Суть проста - сборка всех взаимодействующих проектов с упомянутой опцией ведет к использованию ими одного и того же экз-ра пакета vclxx.bpl (и, самое главное, пакета rtlxx.bpl), в котором "живут" такие (весьма важные в дан.случае) глобальные объекты как Application и Screen.

Суть понял. Но если, ради интереса, попробовать передавать в DLL помимо Application еще и Screen? Каков будет результат в моем случае? (незнаю почему, точнее не помню, но Screen я довно перестал передавать в ДЛЛ - видимо неувидел в этом нужды... года 3 тому назад было...)

> еще и Screen? Каков будет результат в моем случае?


Screen не имеет к твоей проблеме никакого отношения.

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

> проблема именно в экземплярах (копиях) в памяти процесов


Ну говоря упрощенно - да.

и решение, получается, только одно - исключить размножения экземпляров Application (даже передовая и присваивая Application в ДЛЛ он есть свой). Предлагаемый Вами метод, при создании экземпляра ДЛЛ экзешником не создает отдельный Апл а присваевает ему от ехе, чем исключаются все подобные проблемы. И это единственный выход из данной ситуации. Я все правильно понял? Спасибо вам за помощь. Буду пробовать, в случае неудачи напишу.

> Сергей М. ©

Большое спасибо еще раз, все чудесно заработало без ошибок... пока... дальше посмотрим ;)

> Сергей М. ©

НЕ все протестив дал я предыдущий ответ!
Оно заработало,т.е. там где были траблы (не меняя код) ушли. Убирая в ДЛЛ аппликашион настает кирдык функции (приложение хххх обратилось по адресу 000000 к.... 00000), при попытке фрикаль "DB" (перенЁс в Он Дестрой) таже бадяжка (приложение ххх обратилось по адресу 00000...). И самое прикольное, можно не фрикать и тогда все функции работают (без убирания в длл апла), но там где (в [2] последняя строка) все чудненько работало - перестало напрочь... пока еще я не проверял/выяснял/эксперементировал - но результат не совсем тот, к которому я готовился. тоесть, при убирании в длл апла (Application, т.е его передачу в ДЛЛ) - DLL не понимает крейта формы...

> при убирании в длл апла (Application, т.е его передачу в
> ДЛЛ) - DLL не понимает крейта формы...


Сам понял чего написал - дай другим понять.

> Сам понял чего написал - дай другим понять.
>

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