Контролы в DLL - проблемы

← →
Pavel Lechenko © (2002-11-28 17:30) [0]

Привет!
Передо мной стоит задача: есть приложение и куча DLL, в которых лежат описания контролов. Надо чтобы это приложение использовало не VCL-ные контролы, а мои. Вроде как API я разработал, контролы создаются, удаляются, ведется подсчет ссылок и т.д. На данный момент это пишется на Delphi, но в будущем планируется писать эти DLL-ки и на др. языках (VC++ например). Соответственно родителей я могу указывать только с помощью хэндлов.
Все вроде неплохо работает, но вот беда - по тАбу не переходит между ними.
Вот сижу и думаю - переписывать половину VCL или нет.

Мож кто уже сталктивался с такой проблемой? Или может я не по тому пути пошел?

Заранее спасибо!

← →
asmith (2002-11-28 18:58) [1]

Единственный выход при неизменности архитектуры - собрать апликацию и DLL-и с пакетами времени выполнения (как минимум нужны vcl, rtl). Замеченая тобою проблема - лишь одна из многих, которые возникают при внедрении окон, созданных в DLL, в хост-апликацию.

← →
Fantasist © (2002-11-29 07:03) [2]

> собрать апликацию и DLL-и с пакетами времени выполнения
> (как минимум нужны vcl, rtl).

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

Надо регестрировать собственное сообщение и через него передавать ордерный хендл

← →
Pavel Lechenko © (2002-11-29 11:10) [3]

2 asmith: какие еще потенциальные грабли меня ждут?

← →
Pavel Lechenko © (2002-11-29 11:15) [4]

А вообще какие еще есть пути решения такой проблемы?
Если говорить об ActiveX, тогда тут-же возникает вопрос - как его отобразить на форме.

Вообще есть еще одна мысль - покопаться в KOL и ACL, но это, опять-же, переписывание большей половины VCL, чего делать не шибко охота.

← →
asmith (2002-11-29 16:07) [5]

>Да, очень интересный подход, если не собираешься использовать >VCL-ные контролы. Что-то я сомневаюсь, что от этого фокус по >табам прыгать будет
Это не фантазии, а реально работающий код, причем с VCL-ными контролами.

← →
Fantasist © (2002-11-29 19:19) [6]

> Это не фантазии, а реально работающий код, причем с VCL-ными
> контролами

Вот именно, а надо НЕ VCL-ные контроламы.

> Если говорить об ActiveX, тогда тут-же возникает вопрос
>

Непонял, а как эта проблема решается через ActiveX?

Тут не совсем понятно, как устроено взаимодействие у вас, поэтому трудно предположить варианты, но:

1. Создавать собственный список на родителе. Самое очевидное вроде - если родитель знает какие контрлы(окна) в него вставляют, он может переключать фокус между ними.
2. Вариант похитрее - для каждого контрола определить поле, в котором будет содержаться handle следующего окна по табодеру. Как инициализировать это поле, тоже зависит от способа взаимодействия. Если родитель не принемает в этом участие, но мы знаем handle родителя, то можно найти все чайлд окна родителя, и при помощи савоего сообщения опросить их на номер табодера, и выбрать для себя предшесвенника и сообщим ему об этом(через то же сообщение).

← →
asmith (2002-11-29 20:02) [7]

>2 asmith: какие еще потенциальные грабли меня ждут?
Например, такие - если ходишь Tab-ами по "родным" контролам главного окна - у него активный заголовок, а если перескочишь во внедренный контрол мышкой (а по-другому пока и нельзя), заголовок основного окна становится неактивным, как при отображении модального диалога.
По поводу всяких искусственных приемов обхода этого дела. Я с этого как раз и начал. И даже кое-чего добился. Т. е. можно поддерживать 2 независимых цикла табодера в главном окне и его внедренной части и перескакивать по Tab вперед и по Shift-Tab назад. Но нужно, чтобы можно было бы кликнуть мышкой в любой контрол, а продолжить движение клавишами. Тут успехов у меня было мало. Также не получилось решить вопрос с неактивным заголовком. Самое неприятное, что в аналогичном проекте, собранном на D4 этих проблем не было. Видимо в Борланде переписали обработку CM_DIALOGKEY в модуке Forms.pas.
Так что ИМНО runtime pachages - наиболее дешевое решение.

← →
Pavel Lechenko © (2002-12-02 09:50) [8]

Дык в том-то и дело, что нельзя с runtime packages - я не должен быть привязан к какой-то определенной среде разработки, тем более какой-то определенной версии. Необходимо быть полностью независимым от языка программирования.
Повторю еще раз задачу - надо написать приложение, которое должно использовать не VCL-ные контролы, а "свои". То есть должна быть своя библиотека контролов, которая может в дальнейшем развиваться без привязки к среде разработки.
Во как!

← →
Pavel Lechenko © (2002-12-02 12:41) [9]

Еще раз уточню.

ДЛЛ имеет следующий API:
InitPluginObject:TPluginInfo;
CreatePluginObject:TPluginInstance;
UnloadPluginObject;

TPluginInfo = class
PluginName: PChar;
PluginDescr: PChar;
Props: TList;
Methods: TList;
Events: TList;
end;

TEventCallbackProc = procedure CallMethod(ID: integer; Params: VarArray);

TPluginInstance = class
private
Fecp: TEventCallbackProc;
function GetPropValue: Variant;
procedure SetPropValue(val: Variant);
public
property PropValue: Variant read GetPropValue write SetPropValue;
procedure CallMethod(ID: integer; Params: VarArray)
property EventCallbackProc: TEventCallbackProc read Fecp write Fecp;
end;

и т.д.

Приложение имеется встроенный интерпретатор своего языка. Допустим, скрипт следующий:

Var MyForm, MyCtrl;
Form = TMyForm.CreateNew;
Form.ParentHandle = ApplicationHandle;
MyCtrl = TMyControl.CreateNew;
MyCtrl.ParentHandle = MyForm.Handle;
...

ApplicationHandle - предопределенная интерпретатором константа, равная Application.Handle основного приложения.
TMyForm и TMyControl - это как-раз те самые контролы, лежащие в ДЛЛ-ках.
Думаю, догадаться, что этот скрипт делает и как, не очень сложно.
Как-бы еще это правильно сделать?

← →
asmith (2002-12-02 13:41) [10]

Судя по TMyForm, TMyControl твои контролы все равно VCL-ные, ведь ты их порождаешь от какого-либо класса VCL. Или я ошибаюсь и твои контролы создаются как окна по CreateWindow/CreateWindowEx?

Интересная логика...
Кто сказал, что я их порождаю от какого-то VCL-ного класса? Как раз наоборот. Может использоваться и MFC, и VCL, и ACL, и KOL, и даже WinAPI. Я не должен зависеть от того, на каком языке и каким образом написаны эти контролы.
Все, что я могу - это сделать некий контейнер для контрола (а это мысль - надо попробовать).

← →
asmith (2002-12-02 15:42) [12]

Ну так и не будет никаких переходов по тАбу - в методах обработки сообщений модулей Forms и Controls часто запращивается информация о типах, используется ссылка на родительскую форму и пр. Твои контролы вряд ли правильно будут себя вести в этом смысле. Так что "переписывать половину VCL" возможно прийдется.

> Pavel Lechenko © (02.12.02 15:06)

Так я же предложил способ выстраиваня очереди табов с помощью сообщений. Чем не подходит?

А вот интересно, как на чистом WinAPI делается табуляция?

SetFocus () :-))))

Контролы в DLL - проблемы Найти похожие ветки