Есть у меня компонента для 1С. написана на С++ с использованием технологии COM.
Компонента развесистая, в частости, некоторые методы объектов в качестве результата возвращают другие объекты. Типа объектная модель, в полный рост.
Решил реализовать компоненту под native API, т.к. пользователи хотят запускать ее на сервере 1С 8.2.
В документации (http://its.1c.ru/db/metod81?db=metod81#content:3221:1) написано следующее:
"Внимание! Типы VTYPE_INTERFACE, VTYPE_VARIANT не поддерживаются."

Вопрос - как в кмпоненте под Native API возвращать объекты? компонента под СОМ это умеет, что для 7.7, что для 8.x. Неужели Native API не умеет?

Никак.

WTF?

(2)
"Жизнь такова, какова она есть, и больше не какова"
:(
Печально, но так есть.

(3) А есть какие-нибудь паттерны, позвляющие наиболее "красиво" модифицировать соm-интерфейс в native API?

Наверняка, кто-то уже сталкивался с подобной проблемой и как-то решал ее?

(4) нет. ты первый. тебе выпало совершить сей акт высокого программирования.

(4) А что ты возвращаешь в 1С-ку?
Свой объект, или объект 1С?

(6) свой объект

(7) Никак.

p.s. не занимайтесь извращениями - пишите на COM/

(8) Клиенты хотят использовать компоненту в регламентных заданиях :(

(9) Иииии?

Интересно а какой смысл в ВК если в 1С есть события.
Для вычислений можно использовать Модуль или внешнюю обработку в которой сделать метод
Функция Вычислить(Параметры,Команда)
  возврат Вычислить(Команда);
КонецФункции

Модуль можно передать в СОМ и вызывать из него все что угодно
Например
Парам=Модуль.Вычислить("Новый Массив");
Парам.Добаввить(6);
Парам.Добаввить(7);
Рез=Модуль.Вычислить("Параметры[0]+Параметры[1]");

Вернее можно определить в Модуле обработки и передать ЭтотОбъек
и добавить директиву Экспорт

Тьфу наоборот

Функция Вычислить(Команда,Параметры="" Экспорт)
  возврат Вычислить(Команда);
КонецФункции


Парам=Модуль.Вычислить("Новый Массив");
Парам.Добаввить(6);
Парам.Добаввить(7);
Рез=Модуль.Вычислить("Параметры[0]+Параметры[1]",Парам);

(11) А если нужно сделать то, на что 1С не способна? Внешняя обработка тут не поможет.
Что касается COM - то 1С существует не только под Windows.

(14) Человеку нужно передавать объекты. То кто не на Win ССЗС

А в 8 ке ВК на СОM по сути не нужна.

Нужно бы какой-нибудь MPI приладить.

(15) У человека был изначально вопрос насчёт VTYPE_VARIANT и почему его нет. Вот поэтому и нет.
Если надо передавать объекты - ясен день, что Native API тут не годится.

(10) И в 8.2 регламетные задания запускаются на сервере. А в 8.2 на сервере можно использовать только внешние компоненты на технологии native API. Финиш, приплыли.

(17) Это что еще за зверь?

(20) Мысли вслух. IPC

(16) в типовых 8-ках почти все компоненты на COM. Всякое торговое оборудование и т.п.
Как это у них в веб-клиенте работает - щас буду разбираться.

(20)
Message Passing Interface (MPI, интерфейс передачи сообщений) — программный интерфейс (API) для передачи информации, который позволяет обмениваться сообщениями между процессами, выполняющими одну задачу
IPC: Inter Process Communications — методы взаимодействия между процессами

(21) Это, блин, сложно.
Нашу внешнюю компоненту используют сторонние разработчики. Объектная модель, которая реализована через COM, получается понятной и привычной 1с-специалисту. Не хочется терять эту понятность и простоту.

а просто ком не подойдет использовать ?

(19) Зачем на сервере ВК?

(19) мути сразу для SQL

минуя 1с кагбе

(19) У тебя Линукс?

(19) Кто такое сказал?

"Сервер может работать со всеми компонентами. Компонент кэшируется на сеанс работы сервера. "

Глобальный контекст (Global context)
ПодключитьВнешнююКомпоненту (AttachAddIn)
Вариант синтаксиса: По имени и местоположению

Синтаксис:

ПодключитьВнешнююКомпоненту(<Местоположение>, <Имя>, <Тип>)

В веб-клиенте надо писать отдельную, годную компоненту под каждый тип клиента, например, изучив воот это

https://developer.mozilla.org/en-US/docs/Gecko_Plugin_API_Reference/Plug-in_Development_Overview#Writing_Plug-ins

Вердикт: Нахер!

(32) и правда.
Я-то повелся на то, что "ЗагрузитьВнешнююКомпоненту" не работает на сервере.
Щас попробуем.

(34) Я тоже повелся как-то. Это вылилось в 2 месяца переписания компоненты и извращений с XDTO-преобразованиями.

Моя native компонента возвращала XDTO текст, который легким движением ноги превращался в ТЗ, СЗ, Массивы и.т.д.

(33) А в доке к 1С написано, что:
"При работе на сервере «1С:Предприятия» допустимо использовать только компоненты, разработанные по технологии Native API, которые могут быть как отдельными файлами, так и упакованными в специальные ZIP-архивы."

ссылька: http://its.1c.ru/db/v8doc#content:85:1

(35) в итоге - вам удалось запустить com-компоненту на сервере 1С, и использовать там ее?

(29) нет у меня виндоус

(25) судя по результатам поиска на форуме, с этим на сервере 1С тоже разнообразные проблемы связаны.

есть, правда, еще OLE :)

(38) Тогда какой смысл ВК на сервере?
(39) Какие например. Я лет 10 использую простую оболочку IlanguageExtender через ITypeInfo

http://1c.proclub.ru/modules/mydownloads/personal.php?cid=115&lid=2019

Там проблемы только с 64 разрядным библиотеками и правами DCOM касаемыми для EXE.

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

(41) уж с веб сервером можно и без всяких компонент обойтись.

(41) А в чем проблема. Кстати v8: Вопрос по NetObjectToIDispatch
оборачивал сборку .Net к Вэб сервису через эту приблуду и прекрасно читал нечитаемые на 1С сайты.
СОМ лучшее решение. ВК нужны только для асинхронных вызовов. Сейчас 1С поддерживает события, а текущий интерфейс можно передавать как в 13. Ну а так хозяин барин

(42) теоретически - можно. практически - нельзя.
потому что есть существующая инфраструктура, и она удобна.
Пока код выполняется на клиенте - всем все понятно: часть логики вынесена на уровень компоненты, чать логики реализуется в 1С.

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

Тем более, апи сервера реально через одно место написано.

(43) Асинхронные вызовы тоже, кстати, есть.
Как раз сейчас мы их активно впиливаем.

(42) К слову сказать:
был у нас клиент, который использовал как-то древний навижн.
Он взял исходники нашей компоненты, что-то там помутил и адаптировал под свой навижин. И сказал, что ему так проще и прикольнее, чем работать с сервером напрямую через http

(45) И где они на сервере используются?
1C позволяет подключать событие например

msword = Новый COMОбъект("Word.Application");
ДобавитьОбработчик msword.DocumentChange, ПриИзмененииДокумента;

Процедура ПриИзмененииДокумента()
    Сообщить("Документ изменен");
КонецПроцедуры

(47) Это на стороне сервера точно работает?
если да - то это вариант.

(47) Правда ты должен сам следить за вызовом в потоке 1С. В Net удобно использовать SynchronizationContext

(49) как раз обработчики событий мы не используем.
Только прямые вызовы методов компоненты.

(48) Навряд ли. А кого ты собрался оповещать?
Ты можешь вызвать метод как в 13.

(50) Тогда зачем ВК на сервере, если можно спокойно обойтись COM?

(51) не понял.
если не работает на стороне сервера - то как это решит проблему запуска компоненты на стороне сервера?

(52) так сложилось исторически - мы реализовали технологию под названием "внешняя компонента".

По идее - можно сделать просто ком. Если это буждет на сервере работать.

(53) В 47 Это аналог события. Например
Sc.Send(d => EventTo1C.ExternalEvent("ДанныеОтСканера", sp1.PortName, indata), null);

Еще раз. Зачем тебе ВК на сервере, если можно обойтись COM ом

(54) Будет работать если окомпилировать по anyProcessor и зарегистрировать по 32 и 64

56+ вернее по до под чем работает сервер приложений 1С

(55) идея понятна. попробуем

Кстати можно подгружать СОМ и без регистрации
v8: Можно ли использовать библиотеки без COM-сервера?

(59) Только надо CLSID знать объекта.

Но, я думаю, это не проблема, сделав залипуху на реестр и вызвав dllregisterserver.

(59) И если там IDispatch лежит.

(61) В как раз там IDispatch и лежит.
Сначала получаешь фабрику, а затем IDispath

DllGetClassObject(CLSID_XVID, IClassFactory, ClassF);
       ClassF.CreateInstance(nil, IID_IDispatch, res);

(62) Там кроме IDispatch может что угодно лежать, в т.ч. самописное. Я правильно понимаю?

http://delphi-faq.zoxt.net/c56.htm

Может все что угодно, но в большинстве случаев по дефолту нужен IDispatch. Что кстати и вызывает CoGetClassObject

(64) Я это читал.

Можно как-то получить CLSID для "незнакомой" dll, кроме как попыток вызвать dllregisterserver с перехватом реестра?

(66) Если она уже зарегистрирована - то можно просто поискать в реестре InprocServer32 с этой dll.

(67) Именно что без регистрации.

(68) Можно вытащит ITypeInfo

v8: Как из COM объекта во встроенном языке получить описание всех методов и свойств?

(70) Глянем.

(69) Для этого надо сначала зарегистрировать её, создать объект (не у dll же интерфейс запрашивать). А потом уж развлекаться. А тут - (68).

(72) Можно попросить этот интерфейс через GetClassObject, ведь его clsid и интерфейс стандартен и известен.

(73) У GetClassObject первый параметр - как раз CLSID.

http://www.rsdn.ru/article/com/typeinfo.xml#EQKAC

http://www.tdoc.ru/c/programming/programming-theory/com-technology-ref-page5.html

(75), (76) Интересный вариант.

Дилетантский вопрос к
orefkov, H A D G E H O G s,
Rie
А вот работа с ОРС сервером (оборудование, весы, электросчетчики и тд) 1С поддерживает?

http://www.rsdn.ru/forum/com/40868?tree=tree
(78) Через ВК или COM с событиями