Передача методу COM-сервера объекта(TClientDataSet) в параметре

← →
А. Н. Оним (2002-07-31 16:55) [0]

В DLL да ещё и на одной машине такие фокусы как передача экземпляров класса всегда будет проходить, так как и сервер и клиент живут в одном адрессном пространстве и всё что нужно сделать, так это обратиться к одному участку памяти. Правда я не гарантирую, что это будет работать, если клиент и сервер будут скомплированы на разных версиях Delphi. Но пока это прекрасно получается и переданная тобой ссылка на экземпляр класса DataSet (как указатель на область памяти) будет иметь смысл для сервера.
Как только клиент и сервер живут в разных адрессных пространствах - всё летит кувырком и указатель на область памяти клиента для сервера теряет всякий смысл. DataSet не является COM объектом, поэтому его передача в вызове метода не приведёт к процессу маршлалинга (создания прокси клиентского экземпляра кокласса на сервере) и его передача как в случае InProc взаимодействия невозможна.
Не очень всё-таки понимаю, что за задача решается, но могу предложить следующий общий подход: реализовать в серверном коклассе методы обмена информацией между клиентом и сервером. Когда на клиенте происходят изменения, то клиент посылает обновлённые значения на сервер и наоборот, сервер посылает изменённые значения в качестве CallBack"ов клиенту через клиентский Sink объект. Для Callback"ов Посмотри интерфейсы IConnectionPointContainer, IConnectionPoint. Если ты пишешь в Delphi, то вопрос обратных вызовов рассматривается, например, во II томе Стива Тейксера (Delphi 5 руководство разработчика) со страницы 245.
Нельзя ли поподробней рассказать о решаемой задаче?

← →
А. Н. Оним (2002-07-31 17:16) [1]

Можно попробовать так:
1. --Клиент--
Клиент содержит COM объект-обёртку, что реализует пару интерфейсов. Например, IDataSet и IPersonal.
* IDataSet содержит примерно те же методы, что и TDataSet
* IPersonal позволяет назначить объекту управляемый им DataSet.
Клиент создаёт экземпляр такого кокласса, и через IPersonal передаёт ему экземпляр DataSet"а. Так как и DataSet и COM объект в одном процессе (InProc) - это пройдёт. Предполагается, что клиентский COM объект реализует IDataSet перенаправлением вызовов метода этого интерефейса на назначенный ему через IPersonal экземпляр DataSet.
2. --Сервер--
Сервер выставляет ConnectionPoint, позволяющий принимать такие обёртки.
3. --Клиент--
Клиент посылает серверу такую обёртку (например, через IConnectionPoint сервера).
4. --Сервер--
На Сервер есть класс, который является наследником DataSet, но перенаправляет вся вызовы своих методов (делегирует вызовы) на объект обёртку, а ещё конкретней на его интерфейс IDataSet, полученный от клиента.

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

← →
Robin © (2002-07-31 17:56) [2]

А. Н. Оним (31.07.02 17:16) >

Спасибо за мысль.
Пойду вчитаюсь во II-й том Стива Тейксера.
Бо пока не очень все понятно: как реализовать
IDataSet (т.е. в моем случае IClientDataSet) и в чем идея IPersonal?

Если можно, немножко разъясните.

← →
DiamondShark © (2002-07-31 18:10) [3]

А что, TRemoteDatamodule, TDatasetProvider уже отменили?

← →
А. Н. Оним (2002-07-31 18:19) [4]

Полагаю, что DiamondShark прав и есть более простые решения этой проблемы (но сам я, признаться, подолгу не работал ни с DataSet"ами, ни с RemoteDataModul"ями) и COM кажется притянутым здесь за уши.
Назначение IPersonal очень простое. Передать экземпляру CoClass ссылку на DataSet. Это можно сделать тысячью способов и обойтись без этого COM-интерфейса, но у меня просто правило такое - доступ к СOM объекту (даже внутри его сервера) только через его COM интерфейсы. Не нравится - не надо.

2 А. Н. Оним (31.07.02 18:19)

Спасибо за разъяснения.
Немножко тут продвинулся передавая в COM не ClientDataSet, а
ClientDataSet.Data. Но в COM-объекте тогда получается "подвисший" ClientDataSet, т.е. без Providerа.

2 DiamondShark © (31.07.02 18:10)

Но чего то не догоняю: ведь TRemoteDatamodule - тоже COM-объект.
То есть приходим к DCOMConnection. Или я не прав?
Можно пожалуйста поподробнее.

Насколько понял, нужен просто MIDAS server в dll, так будет проще всего. Я вижу два варианта
1. Создать ActiveX library а в ней RemoteDataModule, а подключиться действительно можно через TDCOMConnection - что мешает? Просто не указывать имя хоста, и будет подгрузка
2. Тоже самое, но для подключения вызывать CreateOleObject/CreateCOMObject и др., с прямым преобразованием к IAppServer (Delphi 5?), и вручную работать с данными через методы этого интерфейса
3. Реализовать собственный T...Connection по аналогии с TDCOMConnection, это просто, там буквально два или три метода

2 А. Н. Оним а то, что если используешь COM, то передавать только интерфейсы - поддерживаю полностью

Передача методу COM-сервера объекта(TClientDataSet) в параметре Найти похожие ветки