Привет, трудоголики.

Засунул я фрейм в DLL.
Подключаю её динамически и кладу фрейм на панель.
Проблема в том, что при обходе элементов табом, элементы фрейма не получают фокуса.
TDBGrid, например, вообще фокуса не имеет и ввести в него что-либо невозможно.
TEdit фокус емеет, но при нажатии Tab, фокус переходит к элементу, который находится вне фрейма.

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

KBH>Привет, трудоголики.

KBH>Засунул я фрейм в DLL.
KBH>Подключаю её динамически и кладу фрейм на панель.
KBH>Проблема в том, что при обходе элементов табом, элементы фрейма не получают фокуса.
KBH>TDBGrid, например, вообще фокуса не имеет и ввести в него что-либо невозможно.
KBH>TEdit фокус емеет, но при нажатии Tab, фокус переходит к элементу, который находится вне фрейма.
Может, все-таки поместить его в package, а не в DLL? Это сделает твою жизнь намного приятнее.

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

KBH>Привет, трудоголики.

KBH>Засунул я фрейм в DLL.
KBH>Подключаю её динамически и кладу фрейм на панель.
KBH>Проблема в том, что при обходе элементов табом, элементы фрейма не получают фокуса.
KBH>TDBGrid, например, вообще фокуса не имеет и ввести в него что-либо невозможно.
KBH>TEdit фокус емеет, но при нажатии Tab, фокус переходит к элементу, который находится вне фрейма.

Во-первых, ты синхронизировал объекты Application EXE и DLL, и, самое главное, вызываешь вовремя Application.Idle в dll? Ведь так в dll не запущен цикл обработки сообщений.

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

S>Может, все-таки поместить его в package, а не в DLL? Это сделает твою жизнь намного приятнее.

Справился. Отлично работает в DLL.

А чем пакеты лучше DLL?

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

KBH>А чем пакеты лучше DLL?
Тем, что в них гарантируется использование единственной копии кода и глобальных данных. Скажем так, объект Forms.Application в главном приложении и в пакете — один и тот же. А в DLL он будет свой (поскольку в ней своя копия модуля Forms). И еще много всяких вещей. Типпа того, что оператор is не будет работать, если применять его в DLL к объектам, созданным главным приложением, и наоборот. Из-за того, что у них разные копии классов. А в пакете — все в порядке.

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

...
Типпа того, что оператор is не будет работать, если применять его в DLL к объектам, созданным главным приложением, и наоборот. Из-за того, что у них разные копии классов. А в пакете — все в порядке.

Напомни пожалуйста, что означает оператор is. Давно не программировал в Delphi.

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

KBH>Напомни пожалуйста, что означает оператор is. Давно не программировал в Delphi.
Ну, F1 в таких случаях помогает.
Так вот, оператор
AnObject is AClass
проверяет, является ли класс объекта AnObject потомком класса AClass. Возвращает true если так. Типичное применение — в обработчиках событий:

if Sender is TLabel then TLabel(Sender).Caption:= 'Vow';

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

S>Ну, F1 в таких случаях помогает.

Я пользуюсь Builder'ом.

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

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

S>Так вот, оператор
S>AnObject is AClass
S>проверяет, является ли класс объекта AnObject потомком класса AClass. Возвращает true если так. S>

S>if Sender is TLabel then TLabel(Sender).Caption:= 'Vow';
S>

Опять-таки F1 помогает:

if Sender.InheritsFrom(TLabel) then TLabel(Sender).Caption := 'Vow';

При использовании динамической линковки с bpg(это я про Билдер) никаких проблем не возникает...

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

M>При использовании динамической линковки с bpg(это я про Билдер) никаких проблем не возникает...
Т.е в DLL корректно опознается класс объекта, созданного в главном приложении?

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

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

M>>При использовании динамической линковки с bpg(это я про Билдер) никаких проблем не возникает...
S>Т.е в DLL корректно опознается класс объекта, созданного в главном приложении?

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

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

M>А почему он должен некорректно опознаваться? Если ты можешь привести пример ошибочного определения — я мог бы тебе сказать конкретно...
А потому, что опознание идет путем сравнения указателей на VMT. В DLL будет своя копия класса TLabel, а в главном приложении — своя. Все. Указатели на VMT не совпадают.
Вообще, этому вопросу на DelphiKingdom, да и в этом форуме уже посвятили довольно много внимания.

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

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

M>>А почему он должен некорректно опознаваться? Если ты можешь привести пример ошибочного определения — я мог бы тебе сказать конкретно...
S>А потому, что опознание идет путем сравнения указателей на VMT. В DLL будет своя копия класса TLabel, а в главном приложении — своя. Все. Указатели на VMT не совпадают.
S>Вообще, этому вопросу на DelphiKingdom, да и в этом форуме уже посвятили довольно много внимания.


При динамической линковке package'й все работает и is и InheritsFrom. Без проблем.

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

S>Т.е в DLL корректно опознается класс объекта, созданного в главном приложении?

А почему он не должен опознаваться? К какому типу указатель приведешь такого типа и будет объект.

Здравствуйте, KBH, Вы писали:
KBH>А почему он не должен опознаваться? К какому типу указатель приведешь такого типа и будет объект.
Это заблуждение.
От того, что ты откастишь TTimer к TLabel, он не станет TLabel'ом. Увы.

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

M>При динамической линковке package'й все работает и is и InheritsFrom. Без проблем.
Ну да, есть и такой способ. Но только дело в том, что как только ты написал DLL таким образом, ты вынужден в хост-приложении тоже использовать runtime packages. Иначе у тебя VCLXX.bpl статически слинкуется с екзешником, а lkk заимпортирует его же динамически. И опять все классы будут в двойном экземпляре.
При этом если package requires чего-то там, то он это получит, неважно, статически или динамически слинкован этот VCL с приложением. И получит ровно один экземпляр.

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


S>Ну да, есть и такой способ. Но только дело в том, что как только ты написал DLL таким образом, ты вынужден в хост-приложении тоже использовать runtime packages. Иначе у тебя VCLXX.bpl статически слинкуется с екзешником, а lkk заимпортирует его же динамически. И опять все классы будут в двойном экземпляре.

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

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

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

M>>При динамической линковке package'й все работает и is и InheritsFrom. Без проблем.
S>Ну да, есть и такой способ. Но только дело в том, что как только ты написал DLL таким образом, ты S>вынужден в хост-приложении тоже использовать runtime packages.

А что мешает сделать так? В конце концов — длл и пишут для придания приложению модульности и универсальности.


S>Иначе у тебя VCLXX.bpl статически слинкуется с екзешником, а lkk заимпортирует его же динамически. S>И опять все классы будут в двойном экземпляре.


S>При этом если package requires чего-то там, то он это получит, неважно, статически или динамически S>слинкован этот VCL с приложением. И получит ровно один экземпляр.

Безусловно получит, ты прав. Но — что опять таки мешает более тщательно отнестись к подбору package's, линкуемых в проект? В конце концов динамическая и статическая линковки — всего лишь 2 способа сборки проекта, выбор одного из которых зависит только от разработчика и его конечной цели — хочет ли он получить один — но большой запускаемый файл или один маленький, но с набором библиотек, которые можно менять без пересборки всего проекта.

Удачи.

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

M>Безусловно получит, ты прав. Но — что опять таки мешает более тщательно отнестись к подбору package's, линкуемых в проект? В конце концов динамическая и статическая линковки — всего лишь 2 способа сборки проекта, выбор одного из которых зависит только от разработчика и его конечной цели — хочет ли он получить один — но большой запускаемый файл или один маленький, но с набором библиотек, которые можно менять без пересборки всего проекта.

M>Удачи.
Я просто не могу понять, что мешает использовать Package вместо DLL. При котором не надо тщательно относиться к подбору и т.п. Ребята из борланд провели некривую работу для того, чтобы обеспечить разработчикам легкую жизнь. Единственная причина для написания именно DLL — это интеграция с non-VCL приложениями.

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

S>Это заблуждение.
S>От того, что ты откастишь TTimer к TLabel, он не станет TLabel'ом. Увы.

Скажи, а зачем мне приводить TTimer к TLabel?