Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Форма в dll. Пытаюсь разобраться

Страницы: < 1 2 3 4 >
EgorovAlex © (2010-03-29 13:13:00)
Есть такой код библиотеки:

library pDll; uses Windows, SysUtils, Classes, Forms, uDll; {$R *.res} procedure Show(App: TApplication); stdcall; var DllApp: TApplication; begin DllApp := Application; Application := App; with TForm.Create(Application) do try ShowModal; finally Free; end; Application := DllApp; end; exports Show; begin end.

Вызываю так:
procedure TFormTest.btnTestDllClick(Sender: TObject); var hLib: THandle; Show: procedure(App: TApplication); stdcall; begin @Show := nil; hLib := LoadLibrary('pDll.dll'); if (hLib > 0) then try @Show := GetProcAddress(hLib, 'Show'); if (@Show <> nil) then Show(Application); finally FreeLibrary(hLib); end; end;

Первый вызов проходит удачно, а после второго клика на баттоне выскакивает аксесс виолейшн. В чём может быть дело? Форма в dll пустая.

Если процедуру создания формы заменить на:
procedure Show(App: TApplication); stdcall; begin with TForm.Create(App) do try ShowModal; finally Free; end; end;

То форма создаётся нормально много раз, только форма теперь не по центру главной формы создаётся, а в центре экрана, а это не устраивает (у формы стоит Position := poMainFormCenter)

Игорь Шевченко (2010-03-30 19:59:00) [21]
Дмитрий Белькевич (30.03.10 19:42) [40]

> Однако dll hell имеем.

Вы имеете или MS имеет ? Это несколько разные вещи...

Игорь Шевченко (2010-03-30 19:58:00) [22]
evvcom © (30.03.10 19:34) [39]

> Очень старые проекты на очень старых Delphi писаны, не очень
> старые на не очень старых и т.д. :)

Иногда проще перекомпилировать очень старые проекты на не очень старую версию Delphi :)

Дмитрий Белькевич (2010-03-30 19:42:00) [23]

> Зачем? В СОМ есть версионность. Новая версия COM - старые
> интерфейсы без изменений, а новые добавляются. Таким образом
> старые версии проекта будут обращаться к старым интерфейсам,
> а в новой версии проекта используем новые интерфейсы. См.
> как реализованы майкрософтовские офис, IE.

Ну и dll'ки тоже как бы, в нормальных условиях, должны работать нормально. Однако dll hell имеем.

evvcom (2010-03-30 19:34:00) [24]

> если все проекты собираются на одной и той же версии Delphi,
> включая как приложения, так и dll, чем плохи bpl ?

Не все проекты... :)
Очень старые проекты на очень старых Delphi писаны, не очень старые на не очень старых и т.д. :)
Конечно, в любом случае соглашусь, лучше bpl использовать, чем передавать классы в обычные dll.

Leonid Troyanovsky (2010-03-30 19:07:00) [25]

> Leonid Troyanovsky © (30.03.10 17:11) [36]

> TAction еще не успел проверить.

Чего-то меня длл нынче совсем утомили :(

Смотрю на дельфийском хосте и удивляюсь.

Т.е., для чужих хостов нужно, на худой конец,
хоть Application.Handle назначить. Проверять не буду :)

Боже мой, чего меня туда заносит :(

--
Regards, LVT.

Игорь Шевченко (2010-03-30 17:38:00) [26]
evvcom © (30.03.10 17:00) [35]

> А вот насчет bpl - имхо, лучше уж нормально написанная dll,
> чем bpl, привязанная к версии Delphi, под которой реализована
> и скомпилена.

если все проекты собираются на одной и той же версии Delphi, включая как приложения, так и dll, чем плохи bpl ?
По моему скромному опыту версия Delphi меняется не часто.

Leonid Troyanovsky (2010-03-30 17:11:00) [27]

> Leonid Troyanovsky © (30.03.10 16:56) [34]

> работать хинты, акшины и, возможно, контекстные меню.

Погнал, sorry.
TAction еще не успел проверить.

--
Regards, LVT.

evvcom (2010-03-30 17:00:00) [28]

> С COM'ом тоже бывают проблемы.

Да проблемы можно построить на ровном месте. Для этого большого ума не надо.

> Например, когда разные версии COM серверов (но с одинаковыми
> юидами) должны лежать в разных версиях проекта.

Зачем? В СОМ есть версионность. Новая версия COM - старые интерфейсы без изменений, а новые добавляются. Таким образом старые версии проекта будут обращаться к старым интерфейсам, а в новой версии проекта используем новые интерфейсы. См. как реализованы майкрософтовские офис, IE.

> Начинается COM hell. ... У нас такие проблемы со сторонней COM дллкой - со StarBurn'ером.

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

А вот насчет bpl - имхо, лучше уж нормально написанная dll, чем bpl, привязанная к версии Delphi, под которой реализована и скомпилена.

> Создавал/показывал форму так:

А код такой ф топку, если используется не с рантайм пакетами. Рано или поздно, не понимая того, что в exe и dll код идентичный, но РАЗНЫЙ, ты получишь граблями.

Leonid Troyanovsky (2010-03-30 16:56:00) [29]

> Дмитрий Белькевич (30.03.10 12:40) [30]

> По теме. Форму в ддлке как-то делал, нормально работала.

Мне влом компилировать, но, ЕМНИП, на форме не будут
работать хинты, акшины и, возможно, контекстные меню.
Думаю, что это еще не все неприятности.
Да и модальная форма это еще цветы.

--
Regards, LVT.

Дмитрий Белькевич (2010-03-30 16:46:00) [30]
C десятью гигами дллок в дотнетной папке Подгорецкого.

Дмитрий Белькевич (2010-03-30 16:44:00) [31]

> Ты тоже поклонник камасутры

Ну, не больший, чем Майкрософт ;)

Игорь Шевченко (2010-03-30 14:28:00) [32]
Дмитрий Белькевич (30.03.10 12:40) [30]

> Ну а то, что дублируется код в экшениках - то, думаю, несколько
> мегабайт лишнего кода в современных условиях - это мизер.
>

Ты тоже поклонник камасутры

Дмитрий Белькевич (2010-03-30 12:40:00) [33]
Не люблю dll, и, без особенной надобности, не пользую (особенная надобность возникает только из-за сторонних неделфийских библиотек). Лучше менять всё сразу, чем надеяться, что всё успешно заменилось, и юзеры (или инсталлеры/апдейтеры) не наделали каши из разных версий дллок и экзешников.

> что где-то у кого-то кривые руки, смысла нету.

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

У меня, например, как-то раз были проблемы из-за какого-то кривого апдейта винды (XP) - мультимедийные дллки винды не могли создать несжатый avi файл и записать в него несколько несжатых кадров. К счастью, нашел готовый код, создающий несжатые avi (вернее переписал из mjpeg'а), выбросил все обращения к мультимедиа апи - проблема больше ни разу не возникала.

> Лучше уж COM, bpl, где хоть какие-то правила есть.

С COM'ом тоже бывают проблемы. Например, когда разные версии COM серверов (но с одинаковыми юидами) должны лежать в разных версиях проекта. Начинается COM hell - т.к. единомоментно может быть зарегистрирован только один из нескольких серверов (одна из нескольких дллок, содержащая сервер). У нас такие проблемы со сторонней COM дллкой - со StarBurn'ером.

> а то, что дублируется код, да и фиг с ним, он же -re only.

А коду не обязательно дублироваться (имеется в виду сырцам, не экзешнику). Никто не мешает располагаемый в дллках код поместить в отдельные юниты и добавлять их в uses там, где они нужны. Ну а то, что дублируется код в экшениках - то, думаю, несколько мегабайт лишнего кода в современных условиях - это мизер. Дотнетные приложения могут таскать с собой почти 250 метров 'счастья' и как-то мало кто этим грузится.

По теме. Форму в ддлке как-то делал, нормально работала. Вместе с неделфийским экзешником.

Создавал/показывал форму так:

procedure CreateForm(InstanceClass: TComponentClass; var Reference); var Instance: TComponent; begin Instance := TComponent(InstanceClass.NewInstance); TComponent(Reference) := Instance; try Instance.Create(nil); except TComponent(Reference) := nil; raise; end; end;

Обращение к форме:

CreateForm(TForm1, Form1); with Form1 do begin ... ... ... ... ShowModal; ... ... ... Release; end;

Секция uses:

uses Windows, SysUtils, Classes;

Сама форма - отдельный юнит, как обычно. Не знаю, насколько это верно, но нормально работало, на нескольких сотнях инсталляций.

Германн (2010-03-30 02:12:00) [34]
Позиция LVT мне гораздо больше по душе, чем позиция ИШ.
Но последнего я тоже понимаю после фразы
> Более того, я с трудом представляю обновления нашей системы
> :)
>

:)

Leonid Troyanovsky (2010-03-29 20:50:00) [35]

> Игорь Шевченко © (29.03.10 20:42) [27]

> использовать можно с большими оговорками, если о DLL вообще,
> то все сказанное мной выше остается верным без изменений
> :)

И я от своего не отступлюсь :)

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

--
Regards, LVT.

Игорь Шевченко (2010-03-29 20:42:00) [36]
Leonid Troyanovsky © (29.03.10 20:32) [26]

> Dll, все равно, не то. Ну, если только подписывать, а это,
>
> в конечном счете, один проект - одна библиотека.

> Лучше уж COM, bpl, где хоть какие-то правила есть

Я сильно извиняюсь, потерял нить дискуссии - мы конкретно о Delphiйских DLL говорим или о DLL вообще ?

Если конкретно о Delphi-йских, то их без run-time пакетов использовать можно с большими оговорками, если о DLL вообще, то все сказанное мной выше остается верным без изменений :)

Leonid Troyanovsky (2010-03-29 20:32:00) [37]

> Игорь Шевченко © (29.03.10 20:13) [25]

> > А в чем удобства-то? LoadLibrary vs uses?

> ну да, в нем самом. Возможно изменить часть без изменения
> целого. Я себе с трудом представляю обновления Windows,
> если бы они происходили по принципу "один исходный модуль
> компилируется во всех, его использующих приложениях".

Dll, все равно, не то. Ну, если только подписывать, а это,
в конечном счете, один проект - одна библиотека.
Лучше уж COM, bpl, где хоть какие-то правила есть.

Наконец, пусть отдельные экзешники: сервисы, серверы и т.д.,
но не dll, а то, что дублируется код, да и фиг с ним, он же -re only.

> Более того, я с трудом представляю обновления нашей системы
> :)

Я тоже :)

--
Regards, LVT.

Игорь Шевченко (2010-03-29 20:13:00) [38]
Leonid Troyanovsky © (29.03.10 19:55) [24]

> А в чем удобства-то? LoadLibrary vs uses?

ну да, в нем самом. Возможно изменить часть без изменения целого. Я себе с трудом представляю обновления Windows, если бы они происходили по принципу "один исходный модуль компилируется во всех, его использующих приложениях".

Более того, я с трудом представляю обновления нашей системы :)

Leonid Troyanovsky (2010-03-29 19:55:00) [39]

> Игорь Шевченко © (29.03.10 19:40) [23]

> Не понимаю, зачем без них обходиться. Удобный механизм,

А в чем удобства-то? LoadLibrary vs uses? Минус объекты, плюс
непредсказуемое время существования.

> А потом появляются два приложения, скомпилированные с разными
> версиями этого юнита

Если я скажу, что негоже своей команде пользовать чужые исходние,
то я, всего лишь, снова повторю совет by T.Tentser, чего бы мне не
хотелось, бо у мну нет его опыта на этот счет.
А представить, что команда не может уследить за своими исходниками,
но, тем не менее, легко справляется с поступлением на систему заказчика
к.л. библиотек из гондураса, мне как-то сложно :)

> Обычно дело сводится к набору общих библиотек и набору вполне
> конкретных приложений, использующих для своих целей эти
> библиотеки.

Набор на набор, декартово произведение :)

--
Regards, LVT.

Игорь Шевченко (2010-03-29 19:40:00) [40]
Leonid Troyanovsky © (29.03.10 19:30) [22]

> Не используйте dll там, где без них можно обойтись.

Не понимаю, зачем без них обходиться. Удобный механизм, лишаться его из-за того, что где-то у кого-то кривые руки, смысла нету.

> Повторное использование кода легко реализовать обычными
> средствами
> дельфи. Скажем, включил себе в проект юнит и пользуй.

А потом появляются два приложения, скомпилированные с разными версиями этого юнита и начинается промеж них камасутра с картинками.

> Все равно, рано или поздно, дело сведется к использованию
> для конкретного проекта конкретной библиотеки.

Обычно дело сводится к набору общих библиотек и набору вполне конкретных приложений, использующих для своих целей эти библиотеки.
Собственно, первый раз я с подобным использованием столкнулся еще на железной машине, с тех пор считаю, что страшилка DLLHell просто раздута :)

Страницы: < 1 2 3 4 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »