Поясню (извините госпада, могу и литературным языком выражаться, если непонятно русскими словами английское когда написано.. :) ):

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

В DLL было:


В DLL стало:


Подчеркнутое и есть в написаном в [17] "апл".
Вызов в ЕХЕ соответственно тоже исправлен. Т.о. я убрал упоминания в DLL об Application, как рекомендовано в [6]. После чего вызов функции из DLL стал невозможен.
Но если не убирать передачу Application в DLL (xxx(Aplication,DB);), то фукция вызывается безпроблем.
Также в событии OnDestroy высвобождение объекта TIBDataBase - DB.Free вызывает Exeption.
Сразу поправлю написаное в [2]: Читать не DB.Create(self) а DB:= TIBDataBase.Create(Self).
Надеюсь пояснил всё? Сразу оговорюсь: пока еще я не выяснял, что я сделал не так, т.к. вчера был уже поздний час, и большая усталость. :)
Если подталкнете в нужном направлении - буду очень признателен!

Извините, в DLL Стало

> Maxick ©   (14.03.08 08:57) [21]
>
> в DLL Стало


Показывай еще как "стало" в ехе - прототип, строка вызова ..

В ехе:


Естественно я сейчас не копирую с исходников а по памяти и выкидывая имена и всякий ненужный в данном случае код.

Значит проблема в потрохах самой ф-ции xxx

потраха примерно выглядят так:

> DataBase:= nil;//пробовал и без этого но просто DataBase.
> Free делать нельзя!
> DataBase.Free //верхнее пояснение и сюда же


Убирай нафих и то и другое.

да это я ради эксперемента ставил, но никаких изменений не увидел. А вот ести оставить DataBase.Free то заново придется в exe с DB колупаться (DataBaseName, Open и т.п.). По этому не использую. Вот только и с этими строками и без них вчера пробовал - разницы нуль.

> и с этими строками и без них вчера пробовал - разницы нуль


Ну тогда продолжай "колупаться", если "разницы нуль")

вот здесь не соглашусь, если выполнить DataBase.Free то придется "колупаться", а если DataBase:= Nil то (покрайней мере проверял до выполнения рекомендаций [4]) в exe компонент DB остается нетронутым (не высвобожденым, с conection = true;).
Ну это ладно, уберу эти строки. Но я не думаю что в этом проблема,т.к. я использую подобным образом далеко не одну DLL, и эти строки только в одной, а не работают все (которые с формами и используют TIBDataBase) функции из DLLок.

> Но я не думаю что в этом проблема

точнее НЕ в этом :)

> Maxick ©   (14.03.08 12:40) [29]


> если выполнить DataBase.Free то


.. то нефих делать это повторно, как это делаешь ты в своем ехе (смотри свои страдания с "фриканьем")

Убийство единожды убиенного карается AV-исключением, что ты и имел "удовольствие" прочувтсвовать)

> Сергей М. ©   (14.03.08 12:48) [31]

Я понимаю, что речь идет о

> db.free; //Здесь программа обращается по адрессу 0000...
>
> freeLibrary(hdll);
> Applikation.Terminate;
> exit;
> end; //if else
> freelibrary(hdll);
> end;
> ...
> procedure ...OnDestroy(Sender...);
> ...
> db.Free;


?
Ведь в тексте не просто так я дописал:
> db.free; //Здесь программа обращается по адрессу 0000...
и это еще долеко до OnDestroy.
Когда я писал тот фрагмент сразу подумал, что так и поймете о том, что два раза пытаюсь выполнить Free, но я вас огарчу, в тексте идет:

if DB<>nil then DB.Free

Может и не совсем коректно, но до тута программа всеравно не добирается...

> два раза пытаюсь выполнить Free


А так оно и есть на самом деле)

И dll тут вообще ни причем - теми же гряблями ты получишь по тому же лбу, где бы ни находилась ф-ция xxx.


> но я вас огарчу, в тексте идет: if DB<>nil


Я не вижу подобной проверки в твоем тексте.

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

Да и нафих, спрашивается, уничтожать в dll этот объект, если dll не вправе распоряжаться его жизнью, хотя бы по причине того, что объект этот был передан в dll из создавшего его exe во временное пользование ?

А если так хочится приложить в dll свои шаловливые ручки к уничтожению объекта, то и создавать его изволь в той же dll !

> Сергей М. ©

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

> У меня появилась мысль, что я сделал не так... через пару
> часов проверю, а то может зря почем раздую проблему..

У меня тоже. Ты ж передаешь компоненту в библиотеку. uses ShareMem в dpr-файлах приложения и библиотеки написать не забыл?

> DrPass ©   (14.03.08 15:37) [35]


За каким лешим ему ШароМем, если он последовал (якобы) рекомендации в [4] ?

> За каким лешим ему ШароМем, если он последовал (якобы) рекомендации
> в [4] ?

Ну здрасьте. Он же передает TIBDatabase, не так ли? Не знаю, что там за рекомендации в [4], перечитывать весь тот тред неохота, но передача компоненты параметром в DLL - это уже фактически означает необходимость использования "межмодульного" менеджера памяти.

> передача компоненты параметром в DLL - это уже фактически
> означает необходимость использования "межмодульного" менеджера
> памяти


Вовсе не обязательно.
Все зависит от конкретной ситуации.
Но если общий менеджер таки необходим, то BwRTP как раз и организует его (и много чего еще кроме оного)

Нашел я свою ошибку. Дело было вовсе не в DB.Free. У меня в некоторых DLL были не модальные вызовы форм, так вот для этого у меня были initdll и donedll. В InitDll было Form1:= TForm1.Create(Application), а в DoneDll: Form1.Free. Вот  DoneDll и вызывало ошибку: "..обратилась по адресу 0000...". Убрав DoneDll все стало работать.