Галактика в вопросах и ответах

Создала свой объектный интерфейс, в который покидала всякие разные функции, используемые в разных присоединенных формах. Постепенно его пополняю. И происходит странная вещь - понадобилась новая функция, дописала ее, и вдруг перестают работать некоторые другие формы, использующие функции из этого интерфейса

Исправляется простой перекомпиляцией...
Может, кто подскажет, в чем собака порылась?

Ага, я про это говорил, еще когда они только ввели возможность использования объектных интерфейсов в формах с помощью .DECLARE
Малейшее изменение интерфейса ведет к полной неработоспособности всего ранее написанного. Блин, ну надо же было так криво сделать

Этим бы писателям почитать про DLL или COM модель - вот там появление нового метода не затрагивает работу со старыми методами.
Так что получается, by design

Я на самом деле компилю через проекты, а не из компилятора форм... Значит, надо перекомпилировать сразу все ресурсы. Так и будем делать.

при изменении исходника объектного интерфейса соответственно меняется и VIH
поэтому нужна перекомпиляция не только самого объектника, но и всех исходников куда этот VIH цепляется.
Это же описано в документации! Читайте внимательно

Азы com-технологии, подобие которой мы наблюдаем в Атлантисе, гласят о том, что однажды опубликованный com-интерфейс (ojb-интерфейс в Атлантисе) НЕ МОЖЕТ МЕНЯТЬСЯ!!! Единственный способ "расширения" функциональности - это порождение новых com-интерфейсов, возможно, с помощью наследования (доступно в А5.1).
Соблюдая это простое правило, Вы обезопасите себя и потребителей ,Вашего функционала от массы проблем при его развитии.

Исключением из правила можно считать случай, когда obj-интерфейс используется только для внутренних нужд. Тогда просто следует помнить о необходимости пересборки всех исходников, использующих описание этого obj-интерфейса.

Screw писал(а):Азы com-технологии, подобие которой мы наблюдаем в Атлантисе, гласят о том, что однажды опубликованный com-интерфейс (ojb-интерфейс в Атлантисе) НЕ МОЖЕТ МЕНЯТЬСЯ!!!

Что же вы забыли привести здесь другой аспект COM технологии, а именно независимость клиента от сервера, которая обеспечивается интерфейсами. Изменение интерфейса (имеется в виду добавление новых методов) НЕ ПРИВОДИТ К НЕОБХОДИМОСТИ ПЕРЕКОМПИЛЯЦИИ КЛИЕНТА!!! Действительно, обычно не меняют компонент, а вводят новую версию, но для клиента использование нового компонента абсолютно прозрачно, т.к. обращение производится по независимому от версии ProgID. Т.е., если я использую в программе объект Excel, то независимо от того, какая версия Excel установлена на компьютере, программа будет работать штатно без всяких перекомпиляций. Почему же мы должны перекомпилировать свои подправленные присоединенные формы всякий раз, когда вы измените интерфейс (а вы их меняете, это факт)?

Любезный оппонент, упомянутая Вами независимость клиента от сервера как раз и достигается выполнением сформулированного мною правила. Сие есть следствие. Изменение однажды опубликованного интерфейса НЕДОПУСТИМО ни под каким соусом.

Новая версия компонента содержит измененные реализации некоторых методов com-интерфейса да еще, возможно, реализации методов неких новых com-интерсейсов, либо методов интерфейсов, унаследованных от базового (базовых). В таких условиях клиенты, использующие функциональность, заявленную при помощи старых com-интерфейсов, не перекомпилируются и продолжают прекрасно работать. Пересобирается, само собой, только реализация и клиенты, требующие новую функциональность.

На справедливое утверждение о том, что наши разработчики, несмотря на глубокие познания в области современных технологий программирования, позволяют себе изменять объектные интерфейсы, могу ответить следующее: разъяснительная работа ведется. Есть даже специально разработаная технологическая инструкция "Модификация общеиспользуемого функционала". Приведу выдержку из нее. Речь идет о вопросах сопровождения объектов.
---

Допустим, объявлен объектный интерфейс ObjInterface1 и описан реализующий его vip-интерфейс VipInterface1:

Код: Выделить всё

objinterface ObjInterface1
  procedure Method1;
  procedure Method2;
  ...
end;
...

vipinterface VipInterface1 implements ObjInterface1;
...

interface VipInterface1;
  ...
  public procedure Method1;
  {
    ...
  }

  public procedure Method2;
  {
    ...
  }
  ...
end;

Когда возникает необходимость добавить новые методы/свойства, объявляется новый объектный интерфейс ObjInterface2, декларируется, что VipInterface1 реализует, кроме ObjInterface1, еще и ObjInterface2, и в VipInterface1 добавляются реализации этих самых новых методов/свойств.

Код: Выделить всё

objinterface ObjInterface1
  procedure Method1;
  procedure Method2;
  ...
end;

objinterface ObjInterface2
  procedure Method3;
  ...
end;
...

vipinterface VipInterface1 implements ObjInterface1, ObjInterface2;
...

interface VipInterface1;
  ...
  public procedure Method1;
  {
    ...
  }

  public procedure Method2;
  {
    ...
  }

  public procedure Method3;
  {
    ...
  }
  ...
end;

Для обращения к новым методам в коде, использующем экземпляры интерфейсов типа VipInterface1, применяется преобразование типов:

Код: Выделить всё

var V1: VipInterface1;
...
V1.Method1;
V1.Method2;
...
ObjInterface2(V1).Method3;
...

То же справедливо и в случае, когда вместо переменных типа VipInterface1 использовались инициализируемые ссылкой на VipInterface1 переменные типа ObjInterface1:

Код: Выделить всё

var O1: ObjInterface1;
LoadVipRef(O1, 'VipInterface1');
...
O1.Method1;
O1.Method2;
...
ObjInterface2(O1).Method3;
...

Исходники - тот, в котором находится описание VipInterface1 и те, в которые добавлены вызовы методов ObjInterface2 - компилируются.
---

Изложение ведется с оглядкой на Атлантис 3.03. В А5.10 добавляется возможность наследования объектных интерфейсов (что не может не радовать).

Screw писал(а):Любезный оппонент, упомянутая Вами независимость клиента от сервера как раз и достигается выполнением сформулированного мною правила. Сие есть следствие. Изменение однажды опубликованного интерфейса НЕДОПУСТИМО ни под каким соусом.

Новая версия компонента содержит измененные реализации некоторых методов com-интерфейса да еще, возможно, реализации методов неких новых com-интерсейсов, либо методов интерфейсов, унаследованных от базового (базовых). В таких условиях клиенты, использующие функциональность, заявленную при помощи старых com-интерфейсов, не перекомпилируются и продолжают прекрасно работать. Пересобирается, само собой, только реализация и клиенты, требующие новую функциональность.

Теория, это конечно хорошо, но вы попробуйте в VS внести новый метод в декларацию интерфейса (обязательно в конец!!!), пересоберите компонент и запустите приложение, которое раньше использовало этот компонент. Все прекрасно будет работать, потому-что в виртуальную таблицу ссылок новый метод будет добавлен в конец (методы добавляются в порядке объявления). А вызов методов в COM происходит по смещению в этой таблице. Фактически, новый метод не будет виден старому приложению, но его функциональность сохраниться. Почему у вас то так не работает?
И, наконец, есть же еще Dispatch интерфейсы. Если уж вы решили так навернуть Атлантис, почему бы не дать возможность в присоединенных формах использовать позднее связывание. Это вообще бы избавило от необходимости чего-то там декларировать. Да и проблема с нерадивыми разработчиками, меняющими интерфейсы как им угодно, значительно уменьшилась бы.

На справедливое утверждение о том, что наши разработчики, несмотря на глубокие познания в области современных технологий программирования, позволяют себе изменять объектные интерфейсы, могу ответить следующее: разъяснительная работа ведется.

А вот это не может не радовать

Правила сей забавный факт не отменяет. Существование двух разных интерфейсов с одинаковым GUID-ами есть событие недопустимое или по меньшей мере крайне неприятное.
Кроме того, клиент, использующий "новую" версию старого интерфейса однозначно загнется, если попытается работать со старой реализацией сервера. И очень трудно будет понять в чем дело, ведь и старая, и новая реализации поддерживают интерфейс c данным IID-ом.
А при соблюдении правила такого не произошло бы. По той простой причине, что старая реализация честно призналась бы в том, что новый интерфейс поддерживать она не научена, а правильно написанный клиент при этом добросовестно сообщил бы пользователю о том, что сервер, мол, устарел, и его пора заменить. Или что-то в том же духе.
Кстати, насколько мне известно, при некотором стечении обстоятельств, можно и в vip добиться работоспособности "обновленной" версии интерфейса без полной пересборки кода клиентов. Смею полагать, Атлантис просто сортирует методы по именам. Так что, всё будет зависеть от того, как вы назовете новые процедуры и функции. Но зачем вам это нужно, если страховку от геморроя можно получить более простым способом?
Что касается Dispatch-интерфейсов, то я, признаться, до сих пор ни разу не столкнулся с необходимостью их применения. Может быть, будь я не разработчиком, а пользователем, обстоятельства сложились бы иначе Ж:о)

Screw писал(а):Что касается Dispatch-интерфейсов, то я, признаться, до сих пор ни разу не столкнулся с необходимостью их применения. Может быть, будь я не разработчиком, а пользователем, обстоятельства сложились бы иначе Ж:о)

Еще бы, вам то проще обычные интерфейсы использовать - #include .vih и все дела

(да и побыстрей такие интерфейсы).
А вот простым смертным проще было бы использовать позднее связывание - создал объект и сразу начал его использовать. А то пока сделаешь запрос в суппорт по поводу получения декларации, пока они разродятся, а потом еще оказывается, что по прошествию времени он не работает (хотя с этим и борются).
Ну да ладно, думаю тему пора закрывать.

Поскольку "партнёро-ориентированные" решения мы стали разрабатывать сравнительно недавно, можно считать трудности с поставкой заголовочных файлов и нестабильность описаний obj-интерфейсов временной трудностью. Кроме того, со временем у партнёра отпадёт всякая необходимость в заголовках, т.к. при помощи "Консоли управления" Саппорта (А5.10) можно исследовать любой ресурс вдоль и поперек. Кто видел - поймет, кто не видел - рассказывать бесполезно, это надо видеть Ж:о)

Галактика в вопросах и ответах

Загадка природы

Загадка природы