Подскажие пожалуйста, чего-то я видимо недопонимаю...

Есть проект 3х звенка на DataSnap. Сервер представляет собой набор объектов TRemoteDataModule, клиент коннектится к главному, с помощью TSharedConnection имеет доступ к остальным remotedataмодулям. Тут все вполне стандартно и понятно TSharedConnection обращается к свойству главного модуля, оный модуль отдает интерфейс созданного объекта.

Так вот, про взаимодействие объектов внутри сервера - в главном модуле лежит компонент-подключение к БД, в остальных - dataset'ы доступа к данным. В дизайн-тайме в cвойства Database DataSet'ов очень замечательно проставляется компонент, находящийся в главном модуле.
Т.е.




Внимание вопрос: как это происходит? Ведь MainRDM - это интерфейс, как он может фигурировать в DFM? К тому же нет у него свойства Database.

Спрашиваю для того, чтобы понять, как можно подобное присвоение сделать в коде в run-time.

> MainRDM: IMainRDM


Эту переменную ты создал "ручками" ?

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

> Эту переменную ты создал "ручками" ?


нет, автоматом в _TLB файле.

> d_oleg ©   (13.07.07 11:08) [2]
> нет, автоматом в _TLB файле.


Хм..

Только что в Д7 я создал средствами эксперта "чистый" RDM, при этом эксперт кроме юнита с RDM-классом создал соответствующий TLB-юнит.

В упор не вижу ни там ни там никаких переменных интерфейсного типа.

Да и какое непосредственное отношение TLB-юнит имеет к DFM ? Imho, никакого.

Так что, думается, эта интерфейсная переменная, фигурирующая у тебя - чистая отсебячина)

> Хм..

Так, стормозил... :(

Никакая это не переменная, MainRDM = IMainRDM, т.е. описание Co-класса


> Да и какое непосредственное отношение TLB-юнит имеет к DFM ?
Согласен, никакого. Просто не пойму, на что ссылается DFM строчкой
> MainRDM.Database

> не пойму, на что ссылается DFM строчкой
> MainRDM.Database


Как это на что ? Разумеется на объект-компонент с именем (т.е. св-вом Name) "MainRDM".

B св-во Database у этого объекта имеется, потому как оно у тебя published по умолчанию

> св-во Database у этого объекта имеется


Точнее не св-во, а поле соотв.типа.
Коль ты не указал спецификатор области видимости для этого идентификатора, он автоматически становится published с соответствующими последствиями, кои ты и наблюдаешь.

> Как это на что ? Разумеется на объект-компонент с именем
> (т.е. св-вом Name) "MainRDM".

Так откуда он берется-то? Вот в чем вопрос. Ведь на этапе проектирования мы имеем всего лишь тип TMainRDM, но ни одного одъекта этого типа.

> B св-во Database у этого объекта имеется, потому как оно
> у тебя published по умолчанию
> ....

Тут-то все понятно.

> d_oleg ©   (13.07.07 13:50) [7]



> ни одного одъекта этого типа


Как это "ни одного" ?

А что, по-твоему, есть то на что ты кинул тот самый компонент Database ?

> А что, по-твоему, есть то на что ты кинул тот самый компонент
> Database ?

И где "оно" описано?

2 d_oleg ©   (13.07.07 15:26) [10]
> А что, по-твоему, есть то на что ты кинул тот самый компонент
> Database ?

И где "оно" описано?

Ты че, прикалывашься? В дфмке естесно того модуля где у тя TMainRDM описано. Ну ет для дизайнера. А для раантайма у тя сам модуль есть. Ну ты сослася на него в юзес - усе, тип то компилеру известен, чеб ему не видеть?

Тип виден, но не виден непосредственно объект типа, не описан он. Еще раз: не описан ни один объект данного типа. Что мне мешает создать таких объектов с десяток - какой из них будет использован?

> d_oleg ©   (14.07.07 15:34) [12]


Ты вообще справку на тему "Using multiple remote data modules" читал ?

> Ты вообще справку на тему "Using multiple remote data modules"
> читал ?

И что там по теме, кроме общих слов? Единственное похожее:


> You may also want to extend the interface for each child
> data module, exposing the parent data module's interface,
>  or the interfaces of the other child data modules. This
> lets the various data modules in your application server
> communicate more freely with each other.
>


Но во-первых тут говорится про You may also want..., а я говорю про ситуацию "по умолчанию", безо всяких дополинтельных телодвижений со стороны разработчика, а во-вторых, тут ничего не написано на тему, как это сделать. Банально добавить проперть и установить ее в момент создания? Да, это можно, но повторюсь: по умолчанию нет никаких дополнительных свойств, мне интересен именно этот подход.

> мне интересен именно этот подход


В твоей задаче это изначально неверный подход.


> безо всяких дополинтельных телодвижений со стороны разработчика


Это подход батонокидателя, а не "разработчика", тем более - разработчика, использующего не самые тривиальные в использовании технологии и инструменты, поддерживаемые Делфи.

> Это подход батонокидателя, а не "разработчика"

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

> d_oleg ©   (16.07.07 13:05) [16]
>
>


Слушай, я не знаю что уж ты там наворотил, но Инспектор объектов не позволит выбрать компоненты из другого RDM, подобно описанному тобой случаю.

Только что я провел "чистый" эксперимент:

1. Средствами эксперта создал заготовку проекта AX-библиотеки
2. Средствами эксперта создал в составе проекта пару RDM
3. На один RDM бросил ADOConnection, на другой ADOTable

В Инспекторе объектов открываю список для выбора значения свойства ADOTable.Connection - он девственено чист ! Что собссно и ожидалось)

> Сергей М.

в uses-то написал модуль с другим RDM?

> в uses-то написал модуль с другим RDM?


Нет, не написал.

Ну хорошо, я указал оной, вижу в списке имя.

И что ?

Где, спрашивается, в ран-тайм будет осуществляться поиск этого самого компонента с именем "MainRDM", если его Owner = nil ?

Ты просто получишь исключение - и всех делов.