![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
TIBataBase и DLL [D7, WinXP]
Maxick © (2008-03-13 08:55:00)Проблема следующего характера: Передовая в ДЛЛ данный объект и поимел проблему: при завершении приложения в главной форме не могу фрикнуть (DB.Free) объект DB=TIBDataBase. Вызывается исключение: Ошибка опирации с указателем. Соответственно, если мне не всвобождать DB (я ее создаю сам), то исключение: "приложение ххх.exe обратилось к адрессу хххх" и т.д.
Собственно вопрос: с чем это связано и как с тим бороться? Варианты типа "обработай сам это исключение" не хотелось бы слюшать.
Maxick (2008-03-14 12:29:00) [21]да это я ради эксперемента ставил, но никаких изменений не увидел. А вот ести оставить DataBase.Free то заново придется в exe с DB колупаться (DataBaseName, Open и т.п.). По этому не использую. Вот только и с этими строками и без них вчера пробовал - разницы нуль.
Сергей М. (2008-03-14 12:19:00) [22]
> DataBase:= nil;//пробовал и без этого но просто DataBase.
> Free делать нельзя!
> DataBase.Free //верхнее пояснение и сюда же
Убирай нафих и то и другое.
Maxick (2008-03-14 12:16:00) [23]потраха примерно выглядят так:
function xxx(db: TIBDataBase): boolean; stdcall;
begin
DataBase:= db;
fmForm:= TfmForm.Create(Application);
fmForm.ShowModal;
Result:= var1;//результат принимает значение зависимое от события на форме перед закрытием ее
fmForm.Free;
//В самой форме
tbTable:= TIBTable.Create(Self);
whith tbTable do
//Здесь я присваиваю ей Базу данных, транзакцию, датасет, имя таблицы
...
//операции с таблицей, в частности работа с блоб полями через потоки (TStream), и их высвобождение
...
tbTable.Free;
trTransaction.Free;
DataBase:= nil;//пробовал и без этого но просто DataBase.Free делать нельзя!
DataBase.Free //верхнее пояснение и сюда же
Сергей М. (2008-03-14 11:52:00) [24]Значит проблема в потрохах самой ф-ции xxx
Maxick (2008-03-14 11:44:00) [25]В ехе:
...OnCreate(Sender...);
...
db:= TIBDataBase.Create(Self);
...
end; //end OnCreate
...
Procedure....
type
TFunc = function(db:TIBDataBase):boolean;stdcall;
var
xxx: TFunc;
hdll: THandle;
begin
...
hdll:=LoadLibrary('zzz.dll');
@xxx:= GetProcessAddress(hdll,'xxx');
if xxx(DB)
then ...
else begin
db.free; //Здесь программа обращается по адрессу 0000...
freeLibrary(hdll);
Applikation.Terminate;
exit;
end; //if else
freelibrary(hdll);
end;
...
procedure ...OnDestroy(Sender...);
...
db.Free;
Естественно я сейчас не копирую с исходников а по памяти и выкидывая имена и всякий ненужный в данном случае код.
Сергей М. (2008-03-14 10:30:00) [26]
> Maxick © (14.03.08 08:57) [21]
>
> в DLL Стало
Показывай еще как "стало" в ехе - прототип, строка вызова ..
Maxick (2008-03-14 08:57:00) [27]Извините, в DLL Стало
function xxx(DB: TIBDataBase): boolean; stdcall;
Maxick (2008-03-14 08:56:00) [28]Поясню (извините госпада, могу и литературным языком выражаться, если непонятно русскими словами английское когда написано.. :) ):
> > при убирании в длл апла (Application, т.е его передачу
> в
> > ДЛЛ) - DLL не понимает крейта формы...
>
>
> Сам понял чего написал - дай другим понять
В DLL было:
function xxx( apl:TApplication;DB: TIBDataBase): boolean; stdcall;
В DLL стало:
function xxx(apl:TApplication; DB: TIBDataBase): boolean; stdcall;
Подчеркнутое и есть в написаном в [17] "апл".
Вызов в ЕХЕ соответственно тоже исправлен. Т.о. я убрал упоминания в DLL об Application, как рекомендовано в [6]. После чего вызов функции из DLL стал невозможен.
Но если не убирать передачу Application в DLL (xxx(Aplication,DB);), то фукция вызывается безпроблем.
Также в событии OnDestroy высвобождение объекта TIBDataBase - DB.Free вызывает Exeption.
Сразу поправлю написаное в [2]: Читать не DB.Create(self) а DB:= TIBDataBase.Create(Self).
Надеюсь пояснил всё? Сразу оговорюсь: пока еще я не выяснял, что я сделал не так, т.к. вчера был уже поздний час, и большая усталость. :)
Если подталкнете в нужном направлении - буду очень признателен!
Германн (2008-03-14 00:40:00) [29]
> Сам понял чего написал - дай другим понять.
>
При таком французском ("аппликашион настает кирдык", "при попытке фрикаль "DB"", "таже бадяжка", "можно не фрикать", "без убирания в длл апла") лучше не надо. Не дай бог мозги расплавятся при попытке понять.
Игорь Шевченко (2008-03-13 23:29:00) [30]
> при убирании в длл апла (Application, т.е его передачу в
> ДЛЛ) - DLL не понимает крейта формы...
Сам понял чего написал - дай другим понять.
Maxick (2008-03-13 19:45:00) [31]
> Сергей М. ©
НЕ все протестив дал я предыдущий ответ!
Оно заработало,т.е. там где были траблы (не меняя код) ушли. Убирая в ДЛЛ аппликашион настает кирдык функции (приложение хххх обратилось по адресу 000000 к.... 00000), при попытке фрикаль "DB" (перенЁс в Он Дестрой) таже бадяжка (приложение ххх обратилось по адресу 00000...). И самое прикольное, можно не фрикать и тогда все функции работают (без убирания в длл апла), но там где (в [2] последняя строка) все чудненько работало - перестало напрочь... пока еще я не проверял/выяснял/эксперементировал - но результат не совсем тот, к которому я готовился. тоесть, при убирании в длл апла (Application, т.е его передачу в ДЛЛ) - DLL не понимает крейта формы...
Maxick (2008-03-13 19:04:00) [32]
> Сергей М. ©
Большое спасибо еще раз, все чудесно заработало без ошибок... пока... дальше посмотрим ;)
Maxick (2008-03-13 13:26:00) [33]и решение, получается, только одно - исключить размножения экземпляров Application (даже передовая и присваивая Application в ДЛЛ он есть свой). Предлагаемый Вами метод, при создании экземпляра ДЛЛ экзешником не создает отдельный Апл а присваевает ему от ехе, чем исключаются все подобные проблемы. И это единственный выход из данной ситуации. Я все правильно понял? Спасибо вам за помощь. Буду пробовать, в случае неудачи напишу.
Сергей М. (2008-03-13 13:05:00) [34]
> проблема именно в экземплярах (копиях) в памяти процесов
Ну говоря упрощенно - да.
Maxick (2008-03-13 12:36:00) [35]Значит получается проблема именно в экземплярах (копиях) в памяти процесов. Извините за мою докапываемость, но я хочу понять именно причину. Т.о. смогу не допускать подобных ситуаций в своих прогах. Да и поняв причину - метод решения проблемы становится очевидным.
Сергей М. (2008-03-13 12:24:00) [36]
> еще и Screen? Каков будет результат в моем случае?
Screen не имеет к твоей проблеме никакого отношения.
Maxick (2008-03-13 12:16:00) [37]Суть понял. Но если, ради интереса, попробовать передавать в DLL помимо Application еще и Screen? Каков будет результат в моем случае? (незнаю почему, точнее не помню, но Screen я довно перестал передавать в ДЛЛ - видимо неувидел в этом нужды... года 3 тому назад было...)
Сергей М. (2008-03-13 11:33:00) [38]
> Или я что-то не допонимаю?
Именно.
Выполнение указанных в [4] рекомендаций приведет к тому, что у всех взаимодействующих модулей в составе приложения будут едиными (общими) объекты Application и Screen (и еще много чего).
Суть проста - сборка всех взаимодействующих проектов с упомянутой опцией ведет к использованию ими одного и того же экз-ра пакета vclxx.bpl (и, самое главное, пакета rtlxx.bpl), в котором "живут" такие (весьма важные в дан.случае) глобальные объекты как Application и Screen.
Maxick (2008-03-13 11:17:00) [39]
> Сергей М. ©
Но всеравно не совсем въезжаю - я передаю в длл Application а не ее Handle, т.е. длл полностью привязываю к смоему аплу... Т.о., как здесь: "У твоей dll св-во MainForm объекта Application равно nil.
Удивись, почеши репу, сделай выводы)" - не соответствует моему случаю. И с чаилдами у меня проблем никогда небыло... уже давно все в длл спихиваю, ну нравится мне так - легче в отладке больших проектов, а также в абгрейдах (патчах) у клиентов.
Или я что-то не допонимаю? ;)
Maxick (2008-03-13 11:09:00) [40]Ладно, сейчас исходников рядом нет (нахожусь в другом месте, долеко от того компа, где все это делается), попробую - отпишусь.