DLL и переменная Application

← →
oomneeq (2002-04-30 18:39) [0]

В статьях и примерах по использованию форм в DLL говорится о необходимости передачи в DLL Application.Handle из главного приложения перед вызовом c последующим присвоением этого хэндла
dll-ному Application-у

1-----------------
Опасно ли передавать не .Handle а весь Application?
т.е
В длл записать не
Application.Handle:=ExternalHandle;
а
Application:=ExternalApp;

Где ExternalHandle и ExternalApp - параметры передаваемые из главного приложения.
Есть ли вообще разница между этими двумя способами.

2---------------
Что вообще полезного делает DLL-ный Application
Формами не владеет, цикла обработки сообщ. не организует...
Нужен ли он кому то?

← →
Vovchik (2002-04-30 18:42) [1]

Application:=ExternalApp - так нельзя и разница очень большая.

А присвоение Application.Handle:=ExternalHandle; нужно именно если в DLL есть свои формы. Если этого не сделать, то на таскбаре будет отдельная кнопка для формы из DLL.

← →
oomneeq (2002-04-30 19:10) [2]

>Vovchik © (30.04.02 18:42)
>Application:=ExternalApp - так нельзя и разница очень большая.

Хм, лаконично, однака... :)
A не будет ли любезен Vovchik ткнуть меня в ссылку какую умную,
Ну или хотя бы конспективно изложить, почему нельзя.
Чем чревато?

Я сейчас разбираюсь с проектом, в котором именно так и сделано.
Работает. Но как и в любом разрабатывемом проекте случается
Shit, т.е. AV.
Круг подозреваемых велик. Хочется сузить.
Вопрос вобщем то потому и возник.

← →
SP (2002-04-30 19:18) [3]

Я использую присвоение переменной Application уже долгое время. Все работает отлично, пробывал не присваивать работает все точно также. А насчет дополнительной кнопки в панеле задач, так exe и dll надо компилировать с использованием пакетов. И только так, это говорит сам Borland.

← →
Vovchik (2002-04-30 19:58) [4]

>так exe и dll надо компилировать с использованием пакетов. И >только так, это говорит сам Borland

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

А разница в общем такая. Допустим, у нас есть два разных объекта, но схожих по своему назначению. Т.е., у нас есть два указателя. Теперь, если бы первому указателю присваиваем второй, то первый просто теряется, т.е. память выделенная для него остаётся, но никак фактически не используется (если, конечно, компилятор видя строку типа Application:=EXEApplication не заменят её на присвоение хэндлов, что очень возможно). А при присвоении хэндлов объект Application производит некторые действия и при этом продолжает использоваться фактически.
Это всё касается работы с указателями вообще и с объектами в частности. И это настолько тривиально, что я поэтому первый раз и не хотел это всё набирать.

В дельфийном хелпе ясно написано:

When writing a DLL that uses VCL forms, assign the window handle of the host EXE’s main window to the DLL’s Application.Handle property. This makes the DLL’s form part of the host application.

Именно, если вы юзаете VCL в DLL. А если нет - то можно и не присваивать.

← →
oomneeq (2002-04-30 20:54) [5]

2Vovchik

Cпасибо, то что ты разъяснил, по поводу обЪектов-указателей - это понятно и тривиально, факт. Но вопрос мой касался конкретного объекта - экземпляра Application, того, что живет в Dll. Т е меня интересуют конкретные последствия его подмены, и возможно, потери(невосстановления) ссылки на него
Насколько этот объект нужен в самой Dll?
Tолько лишь чтоб принять внешний хэндл для правильного показа форм, как пишут в примерах?
Ведь в тех же примерах этот хэндл полсле создания форм нагло обнуляют - типа - не нужен больше.
Вот можно и подумать, что приравняв Application-ы, хуже не сделаешь, наоборот - даешь Dll-ке полноценный Application, с правильным хэндлом, со всеми делами.
Чем ценен Dll-ке его родной Application?
Ведь если действительно нужен, значит, что-то будет не так, если его перезаписать другим, приложеньевским.
А вот что же?
Короче хочется аргументов против, потому как таки работает же - значит не очень-то и нужен!
Повторяю речь не идет об общем правиле корректных действий с объектными ссылками, вопрос касается конкретного экземпляр,который в достаточной степени специфичен.

← →
Vovchik (2002-04-30 22:13) [6]

> Повторяю речь не идет об общем правиле корректных действий с
> объектными ссылками, вопрос касается конкретного
> экземпляр,который в достаточной степени специфичен.

Возможно, в данном случае ничего плохого не будет. Но это не значит, что можно пренебрегать "правилами хорошего тона".

В данном случае нужно просто поисследовать подробнее что именно происходит при таком присвоении.

← →
Cobalt (2002-05-01 10:54) [7]

"Размышления на заданную тему"

Итак, имеем ДВА МОДУЛЯ:
1)ЕХЕ-ник
2)ДЛЛ-ка

В каждом из них имеется свой экземпляр TApplication.
При замене этого экземпляра в ДЛЛ-ке экземпляром из ЕХЕ-ника происходит просто подмена одного экземпляра другим, все вызовы будут идти также. Просто предыдущий объект будет потерян(память, выделенная под него). Абыдна, да?
Соответственно, будет утеряно такое св-во, как TApplication.ExeName, и, насколько я разобрался в Form.pas, всё.

При замене хэндла вы будете иметь ДВА экземпляра TApplication, ДЛЛ-льный будет хукать только свою(и) форму(ы), ЕХЕ-ный - свои. При этом при работе ОДНОВРЕМЕННО с ДВУМЯ ФОРМАМИ управлять событиями(сообщениями) будет ЕХЕ-ный, а ДЛЛ-ная форма будет использовать св-ва ДЛЛ-ного TApplication(ведь так скомпилино)(при том, что он не будет обрабатывать сообщения(события)).
То есть, если вы в главной проге как-то меняете св-ва TApplication, то это вам выйдет боком (ДЛЛ-льная TApplication-то об этом не знает ;)))
Т.е. (ИМХО) Application:=ExternalApp - правильнее, чем Application.Handle:=ExternalHandle;;)
Но ещё правильнее - делать с run-time bpl.

DLL и переменная Application Найти похожие ветки