Задача: необходимо что бы формы приложения находились в DLL, создавались тоже в DLL. Далее, необходимо, что бы: выводился Hint (подсказка), работал Tab (переход по контролам), работали ShortCut (горячие клавиши). С первым и вторым я справился, а вот как быть с горячими клавишами? У кого есть идеи?

Здравствуйте, AlekseyVP, Вы писали:

AVP>Задача: необходимо что бы формы приложения находились в DLL, создавались тоже в DLL. Далее, необходимо, что бы: выводился Hint (подсказка), работал Tab (переход по контролам), работали ShortCut (горячие клавиши). С первым и вторым я справился, а вот как быть с горячими клавишами? У кого есть идеи?

Тебе необходимо чтобы и DLL и Главное приложение было скомпилировано с использованием Runtime Packages (Project Options\Packages\Build with runtime packages)

Только тогда у тебя будет все работать гладко.
Иначе главное приложение будет неадекватно реагировать на формы из DLL.

Здравствуйте, Danchik, Вы писали:

D>Тебе необходимо чтобы и DLL и Главное приложение было скомпилировано с использованием Runtime Packages (Project Options\Packages\Build with runtime packages)

D>Только тогда у тебя будет все работать гладко.
D>Иначе главное приложение будет неадекватно реагировать на формы из DLL.
Избежать этого как-нибудь можно? Дело в том, что формы могут быть COM обьектами, решение пока не принято, думаю это дело вкуса начальника ...

Здравствуйте, Danchik, Вы писали:

D>Здравствуйте, AlekseyVP, Вы писали:

D>Тебе необходимо чтобы и DLL и Главное приложение было скомпилировано с использованием Runtime Packages (Project Options\Packages\Build with runtime packages)

D>Только тогда у тебя будет все работать гладко.
D>Иначе главное приложение будет неадекватно реагировать на формы из DLL.

Runtime Packages — не самое удачное решение для программного продукта, состоящего из одного EXE и одной DLL.

Есть другой путь — клонировать объекты Application и Screen EXE в аналогичные объекты DLL (т.к. эти объекты различны в EXE и DLL) и работать с ними. Метод работает, глюков замечено не было.

Да и на форумах здесь его уже предлагали и обсуждали, вроде как.

Здравствуйте, _spin_, Вы писали:

__>Здравствуйте, Danchik, Вы писали:

D>>Здравствуйте, AlekseyVP, Вы писали:

D>>Тебе необходимо чтобы и DLL и Главное приложение было скомпилировано с использованием Runtime Packages (Project Options\Packages\Build with runtime packages)

D>>Только тогда у тебя будет все работать гладко.
D>>Иначе главное приложение будет неадекватно реагировать на формы из DLL.

__>Runtime Packages — не самое удачное решение для программного продукта, состоящего из одного EXE и одной DLL.

__>Есть другой путь — клонировать объекты Application и Screen EXE в аналогичные объекты DLL (т.к. эти объекты различны в EXE и DLL) и работать с ними. Метод работает, глюков замечено не было.

__>Да и на форумах здесь его уже предлагали и обсуждали, вроде как.

А что мешает создать хотя бы один Run-Time package и запихтуть в него VCL (пробовал) и получить триаду EXE, DLL, BPL — и минигитов нету.
Да и каждая новая DLL не будет конских замеров — VCL код не будет вкомпилирован.

Вот пример сборки для Delphi5:

package ALL_vcl;

{$R *.RES}
{$ALIGN ON}
{$ASSERTIONS ON}
{$BOOLEVAL OFF}
{$DEBUGINFO ON}
{$EXTENDEDSYNTAX ON}
{$IMPORTEDDATA ON}
{$IOCHECKS ON}
{$LOCALSYMBOLS ON}
{$LONGSTRINGS ON}
{$OPENSTRINGS ON}
{$OPTIMIZATION ON}
{$OVERFLOWCHECKS OFF}
{$RANGECHECKS OFF}
{$REFERENCEINFO ON}
{$SAFEDIVIDE OFF}
{$STACKFRAMES OFF}
{$TYPEDADDRESS OFF}
{$VARSTRINGCHECKS ON}
{$WRITEABLECONST ON}
{$DESCRIPTION 'ALL Visual Component Library'}
{$RUNONLY}
{$IMPLICITBUILD OFF}

contains
  AppEvnts,
  Contnrs,
  SysUtils,
  Windows,
  SysConst,
  Classes,
  Consts,
  TypInfo,
  ActiveX,
  Messages,
  StdActns,
  Clipbrd,
  Forms,
  Math,
  Printers,
  WinSpool,
  Graphics,
  Commctrl,
  FlatSB,
  Menus,
  Controls,
  MultiMon,
  Imm,
  ImgList,
  ActnList,
  StdCtrls,
  Masks,
  ToolsAPI,
  DsgnIntf,
  Dialogs,
  ExtCtrls,
  Dlgs,
  CommDlg,
  ShlObj,
  ShellAPI,
  RegStr,
  WinInet,
  UrlMon,
  Registry,
  IniFiles,
  ComCtrls,
  ComStrs,
  RichEdit,
  ToolWin,
  Mtx,
  ComObj,
  ComConst,
  SvcMgr,
  WinSvc,
  SyncObjs,
  ScktComp,
  WinSock,
  Imagehlp,
  CPL,
  StdVCL,
  Proxies,
  FileIntf,
  VirtIntf,
  EditIntf,
  ToolIntf,
  IStreams,
  AxCtrls,
  Exptintf,
  LibHelp,
  ExtDlgs,
  Buttons,
  VCLCom,
  OleServer,
  OleConst,
  OleCtrls,
  OleCtnrs,
  OleDlg,
  Mask,
  Grids,
  AclApi,
  AccCtrl,
  TLHelp32,
  PenWin,
  MMSystem,
  NSApi,
  Mapi,
  LZExpand,
  Isapi2,
  Isapi,
  Ddeml;

end.

Здравствуйте, Danchik, Вы писали:

__>>Здравствуйте, Danchik, Вы писали:

D>А что мешает создать хотя бы один Run-Time package и запихтуть в него VCL (пробовал) и получить триаду EXE, DLL, BPL — и минигитов нету.
D>Да и каждая новая DLL не будет конских замеров — VCL код не будет вкомпилирован.

Можно, выбор способа — дело разработчика. Мне проще было без Run-Time Packages. А по поводу размеров — пакет тоже ведь в память как DLL грузится, место занимает.

Так что выбор способа — дело личное, интимное...

Здравствуйте, AlekseyVP, Вы писали:

AVP> Избежать этого как-нибудь можно? Дело в том, что формы могут быть COM обьектами, решение пока не принято, думаю это дело вкуса начальника ...

Они почитывают этот форум кстати иногда....

Здравствуйте, _spin_, Вы писали:

__>А по поводу размеров — пакет тоже ведь в память как DLL грузится, место занимает.

Безусловно. Вот только пакет грузится в память в единственном экземпляре, а не в двадцати-сорока-восьмидесяти-и более (по количеству включенных в проект DLL).

Помнится, лет пять назад я настойчиво проедал плешь тогдашнему начальству по поводу использования run-time packages, но для того, чтобы их внедрить, потребовался форс-мажор — нужно было срочно отправить заказчику новую версию, и при этом лучшие умы фирмы, включая меня, не могли справиться с ошибкой, возникавшей при логине.

Я тогда пообещал за пол-дня сделать стабильную версию с использованием run-time packages. И сделал, после чего от них уже не уходили. Размер дистрибутива при этом упал с 30 Мб до примерно четырех с половиной.

Здравствуйте, _spin_, Вы писали:

__>Здравствуйте, Danchik, Вы писали:

__>>>Здравствуйте, Danchik, Вы писали:

D>>А что мешает создать хотя бы один Run-Time package и запихтуть в него VCL (пробовал) и получить триаду EXE, DLL, BPL — и минигитов нету.
D>>Да и каждая новая DLL не будет конских замеров — VCL код не будет вкомпилирован.

__>Можно, выбор способа — дело разработчика. Мне проще было без Run-Time Packages. А по поводу размеров — пакет тоже ведь в память как DLL грузится, место занимает.

Один раз и ничего она там не занимает больше положеного. BPL это та же DLL.

__>Так что выбор способа — дело личное, интимное...

Я, кстати, пе понял понятия "клонировать объекты Application и Screen EXE". Не DLL.Application.Handle := EXE.Application.Handle ли?
Слабо верится что это поможет решить проблемы, которые могут возникнуть. Скорее породит новые, которые придется решать и не всегда корректно.

BTW, сам не люблю Runtime-packages. Но когда надо, то не отвертишся.

Здравствуйте, Danchik, Вы писали:

D>Один раз и ничего она там не занимает больше положеного. BPL это та же DLL.

Не совсем так. Пакет (какой-нибудь vcldb.bpl) тянет весь код, в том числе ненужный в конкретном проекте, в то время как в dll линкуется только используемый. Поэтому в принципе можно построить пример, когда пакеты займут в памяти больше. Другой вопрос, что пример будет совершенно нежизненным.

D>Я, кстати, пе понял понятия "клонировать объекты Application и Screen EXE". Не DLL.Application.Handle := EXE.Application.Handle ли?

Учитывая, что DLL.Application весьма вероятно равен nil, это не очень хороший способ Обычно имеется в виду DLL.Application := EXE.Application. Но это не избавляет от проблем, только микширует некоторые, и в результате возникают не очевидные проблемы, а "непонятные и странные".

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, Danchik, Вы писали:

D>>Один раз и ничего она там не занимает больше положеного. BPL это та же DLL.

S>Не совсем так. Пакет (какой-нибудь vcldb.bpl) тянет весь код, в том числе ненужный в конкретном проекте, в то время как в dll линкуется только используемый. Поэтому в принципе можно построить пример, когда пакеты займут в памяти больше. Другой вопрос, что пример будет совершенно нежизненным.

Я это знаю, просто я думаю он не это имел ввиду

D>>Я, кстати, пе понял понятия "клонировать объекты Application и Screen EXE". Не DLL.Application.Handle := EXE.Application.Handle ли?

S>Учитывая, что DLL.Application весьма вероятно равен nil, это не очень хороший способ Обычно имеется в виду DLL.Application := EXE.Application. Но это не избавляет от проблем, только микширует некоторые, и в результате возникают не очевидные проблемы, а "непонятные и странные".

Чесно не знал точно Где то в памяти всплыло что типа этого. Только точно знаю что "даже после "клонинга"" проблемы будут, для этого не надо иметь семь пядей во лбу, нужно просто покопаться в сурцах VCL

Здравствуйте, Softwarer, Вы писали:

S>Здравствуйте, _spin_, Вы писали:

__>>А по поводу размеров — пакет тоже ведь в память как DLL грузится, место занимает.

S>Безусловно. Вот только пакет грузится в память в единственном экземпляре, а не в двадцати-сорока-восьмидесяти-и более (по количеству включенных в проект DLL).

BPL = DLL => Согласен.

S>Я тогда пообещал за пол-дня сделать стабильную версию с использованием run-time packages. И сделал, после чего от них уже не уходили. Размер дистрибутива при этом упал с 30 Мб до примерно четырех с половиной.

Было и так, а было и наоборот. Неделя мучений с "плавающими отказами", после чего переделали без RTPack-ов и всё, успешно сдали проект. Потом копался — косяк был в пакетах: однажды загруженный один из пакетов некорректно работал с собственными внутренними переменными (утечка по 3-5 байт), в итоге — ошибки памяти после 2-3 суток непрерывной работы.

Здравствуйте, Danchik, Вы писали:


D>Один раз и ничего она там не занимает больше положеного. BPL это та же DLL.

Знаю, согласен.

D>Я, кстати, пе понял понятия "клонировать объекты Application и Screen EXE". Не DLL.Application.Handle := EXE.Application.Handle ли?
D>Слабо верится что это поможет решить проблемы, которые могут возникнуть. Скорее породит новые, которые придется решать и не всегда корректно.

Идею брал здесь:
Топик плюс пример

Делал подобное, всё работает уже 5 лет (заказчик не жаловался ).

D>BTW, сам не люблю Runtime-packages. Но когда надо, то не отвертишся.
Есть такое дело.

Здравствуйте, Danchik, Вы писали:

D>Чесно не знал точно Где то в памяти всплыло что типа этого. Только точно знаю что "даже после "клонинга"" проблемы будут, для этого не надо иметь семь пядей во лбу, нужно просто покопаться в сурцах VCL

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

Здравствуйте, _spin_, Вы писали:

__>Было и так, а было и наоборот. Неделя мучений с "плавающими отказами", после чего переделали без RTPack-ов и всё, успешно сдали проект. Потом копался — косяк был в пакетах: однажды загруженный один из пакетов некорректно работал с собственными внутренними переменными (утечка по 3-5 байт), в итоге — ошибки памяти после 2-3 суток непрерывной работы.

Косяк был не в пакетах, а в коде, вкомпилированном в пакеты — это чуть разные вещи. Да, для заметания ошибки под ковер годится любое шаманство — но судя по описанию, с тем же успехом проблема могла возникать и без пакетов, после 2-3 суток непрерывной работы DLL. Я, однако, предлагаю не путать "временные решения для частных задач" с "правильным подходом".

Еще вопрос — как правильно решать такие вещи. Полагаю, MemCheck, BoundsChecker или подобный продукт спас бы и от недели мучений, и от кривой технологии

Здравствуйте, _spin_, Вы писали:

__>Здравствуйте, Danchik, Вы писали:

D>>Чесно не знал точно Где то в памяти всплыло что типа этого. Только точно знаю что "даже после "клонинга"" проблемы будут, для этого не надо иметь семь пядей во лбу, нужно просто покопаться в сурцах VCL

__>Проблему можно найти, можно создать самому, можно свыше получить. Но их решать надо по мере поступления.

Тут есть еще один критерий: затраты на поиск проблемы. Хотя бы одно то что класс TApplication из DLL совсем не то что из EXE (DLL.TApplication is not EXE.TApplication) заставляет задуматься. Это еще хорошо что таблица виртуальных методов идентичная...

Вообще то пример показаный в Королевстве Delphi — настоящий подводный камень. Это еще хорошо что Delphi вторая. Согласен, лет пять назад VCL могла поддаваться на такие истязания, но где гарантии что все будет работать без сучка и задоринки на версиях повыше?

Здравствуйте, Softwarer, Вы писали:

S>Косяк был не в пакетах, а в коде, вкомпилированном в пакеты — это чуть разные вещи. Да, для заметания ошибки под ковер годится любое шаманство — но судя по описанию, с тем же успехом проблема могла возникать и без пакетов, после 2-3 суток непрерывной работы DLL. Я, однако, предлагаю не путать "временные решения для частных задач" с "правильным подходом".


В статье <b>"Редкая профессия" (настоятельно рекомендую прочитать :) )</b> есть отличный критерий оценки софта: "летает или не летает"

Мои "частные решения" "летают" на серверах без отключения и перезагрузки устойчиво и долго (пока личный рекорд — 4 года).

Оценку теории выставляет практика. (Королёв)

S>Еще вопрос — как правильно решать такие вещи. Полагаю, MemCheck, BoundsChecker или подобный продукт спас бы и от недели мучений, и от кривой технологии

Код пакетов я не менял, стандартные они. BoundsChecker показал утечку в пакете. Как его лечить? Искать утечку в стандартных исходниках Delphi и перекомпилить? Море пота и крови... Особенно если искать в активиксовских и комовских пакетах.

Я не знаю как такое править.

Есть предложения?

Здравствуйте, _spin_, Вы писали:

__>Здравствуйте, Softwarer, Вы писали:

S>>Косяк был не в пакетах, а в коде, вкомпилированном в пакеты — это чуть разные вещи. Да, для заметания ошибки под ковер годится любое шаманство — но судя по описанию, с тем же успехом проблема могла возникать и без пакетов, после 2-3 суток непрерывной работы DLL. Я, однако, предлагаю не путать "временные решения для частных задач" с "правильным подходом".


__>В статье <b>"Редкая профессия" (настоятельно рекомендую прочитать :) )</b> есть отличный критерий оценки софта: "летает или не летает"

__>Мои "частные решения" "летают" на серверах без отключения и перезагрузки устойчиво и долго (пока личный рекорд — 4 года).

Гы, сервер, это совсем не полноценное GUI приложение (напрашивается поговорка о сравнениях). Тут могут просто полететь контролы (юзверь может наClickать беду) .

__>Оценку теории выставляет практика. (Королёв)

S>>Еще вопрос — как правильно решать такие вещи. Полагаю, MemCheck, BoundsChecker или подобный продукт спас бы и от недели мучений, и от кривой технологии

__>Код пакетов я не менял, стандартные они. BoundsChecker показал утечку в пакете. Как его лечить? Искать утечку в стандартных исходниках Delphi и перекомпилить? Море пота и крови... Особенно если искать в активиксовских и комовских пакетах.

__>Я не знаю как такое править.

__>Есть предложения?

Вот мною и предлагалось создать свои Run-Time пакеты. Собрать по категориям то что нужно в соответствующих своих пакетах.
И если надо то подправить лики стандартной VCL.

Здравствуйте, Danchik, Вы писали:

D>Вообще то пример показаный в Королевстве Delphi — настоящий подводный камень. Это еще хорошо что Delphi вторая. Согласен, лет пять назад VCL могла поддаваться на такие истязания, но где гарантии что все будет работать без сучка и задоринки на версиях повыше?

Гарантий нет. Необходима проверка практикой. Только вот пока почему-то борланд не торопится переписывать полностью все свои библиотеки от версии к версии. Да, есть изменения, есть существенные и критические, но касаются они больше расширения функциональности, а не основ построения VCL.

У меня всё вроде как работает на D7 и на D2k5.

ИМХО, В применении таких методов главное — не увлекаться и не переборщить, всему есть предел (и гибкости VCL тоже). Есть конкретная проблема — есть конкретное решение.

Прочитайте здесь. Очень поучительная статья для любого программиста (особенно места про "Буран" и ремонт сруба).
Я прочитал и задумался.

Здравствуйте, Danchik, Вы писали:

D>Гы, сервер, это совсем не полноценное GUI приложение (напрашивается поговорка о сравнениях). Тут могут просто полететь контролы (юзверь может наClickать беду) .

Защиту от дурака (читай — юзверя ) ещё никто не отменял. GUI полноценное когда юзверь настраивает/перенастраивает/пере-пере-...настраивает службы(удалённо или локально). Плюс мониторит (удалённо или локально) статистику работы служб. Это уже полноценный GUI, который юзер не выключает и не перезапускает иногда месяцами.

D>Вот мною и предлагалось создать свои Run-Time пакеты. Собрать по категориям то что нужно в соответствующих своих пакетах.
D>И если надо то подправить лики стандартной VCL.

Свои — ок. Править стандартное... Копаться и учить — да, править — никому не советую без экстренной необходимости.