пример внешней компоненты NativeAPI #776684

Разбираюсь с примером внешней компоненты с использованием NativeAPI с ИТС. В платформе для строк используется двухбайтовый тип WCHAR_T, который под windows объявлен как wchar_t, а под linux - как uint16_t (потому как размер wchar_t в linux и macos равен 4 байтам). В примере компоненты поэтому все строки объявлены как wchar_t* и при передаче в платформу конвертируются в WCHAR_T с помощью convToShortWchar и convFromShortWchar. Также в примере еще непонятно зачем нужный класс WcharWrapper. Хочу определить WCHAR_T как char16_t (добавлен в C++11), чтобы избавиться от различного кода для строк под windows и linux и избавиться от необходимости преобразования строк. Не будет ли каких-либо подводных граблей при замене? Второй вопрос - в примере очень неудобно написано взаимодействие с платформой (например, описание метода компоненты раскидано в куче мест - это enum Methods, g_MethodNames, g_MethodNamesRu, GetNMethods, FindMethod, GetMethodName, GetNParams, GetParamDefValue, HasRetVal, CallAsProc, CallAsFunc). Может есть какая-то обертка над всем этим с более человеческим лицом? .net не предлагать - компонента нужна простейшая, не хочется лишних зависимостей тащить.

Разбираюсь с примером внешней компоненты с использованием NativeAPI с ИТС. В платформе для строк используется двухбайтовый тип WCHAR_T, который под windows объявлен как wchar_t, а под linux - как uint16_t (потому как размер wchar_t в linux и macos равен 4 байтам). В примере компоненты поэтому все строки объявлены как wchar_t* и при передаче в платформу конвертируются в WCHAR_T с помощью convToShortWchar и convFromShortWchar. Также в примере еще непонятно зачем нужный класс WcharWrapper. Хочу определить WCHAR_T как char16_t (добавлен в C++11), чтобы избавиться от различного кода для строк под windows и linux и избавиться от необходимости преобразования строк. Не будет ли каких-либо подводных граблей при замене? Второй вопрос - в примере очень неудобно написано взаимодействие с платформой (например, описание метода компоненты раскидано в куче мест - это enum Methods, g_MethodNames, g_MethodNamesRu, GetNMethods, FindMethod, GetMethodName, GetNParams, GetParamDefValue, HasRetVal, CallAsProc, CallAsFunc). Может есть какая-то обертка над всем этим с более человеческим лицом? .net не предлагать - компонента нужна простейшая, не хочется лишних зависимостей тащить.

Вот как выяснится отпишитесь тут плиз...

Плиз замечания: 1. Используй теги 2. Вот эти простыни кода даже мне знающему c# (отлично) и с++ (средненько практики мало было) ну ничего совершенно не говорят на беглый взгляд. Лучше бы выкинуть начинку внутри, оставив только "заголовки" методов и комментарии "а зачем оно". Даже на примере всего одного метода разобрать. ЗЫ Копипастить код это не всегда ответ который просят.

+ Теги "["+"1C"+"]" и "["+"/"+"1C"+"]" без пробелов и кавычек или срабатывает

Насчёт WCHAR_T через char16_t - называй её как хочешь - сути это не изменит. Чем это тебе поможет избежать преобразования строк, если все внешние библиотеки под линуксом ждут 4ых-байтовый юникод? Если под линуксом штатные wcslen и wcsstr принимают на вход wchar_t, и соответственно ждут четырёхбайтовые символы - как тебе поможет использование псевдонима для двухбайтовых символов? Насчёт сложности работы с методами - в чём сложность? Реализовать банальнейший интерфейс с меньше чем десятком методов? За то время, пока тут сидишь, уже можно было бы сделать.

На днях звонили из кадрового агенства, искали 1эсника со знанием С#. Сказали в издательский дом "Коммерсант" ищут. Вроде Вы тоже недавно искали работу, можете через сайт коммерсанта сбросить свое резюме, как вариант.

А вообще Native API от 1С - какой-то полуобрезок, не позволяющий работать с объектами 1С. Только простые типы данных гонять туда-сюда. Очевидно, не задумывался как средство какого-то расширения, а просто чтобы под линуксом торговое оборудование подключать. Этим круг задач и возможностей и ограничен.

Вы прочитали ?

Большое спасибо! Сброшу.

, положи уже свой код на pastebin или gist. Не насилуй форум своим C#.

Ну я использую через строковую ссылку. И написал здесь Но 1С на это глубоко ...

Интересно, а где ты тут C# то увидел?

Очевидно, архитектуру, подразумевающую манипуляцию объектами одной системы/среды из другой системы, надо оставить где-то в 00х. И использовать сервисный подход.

Ну cpp, какая разница? От тебя чаще .Net'ом разит.

Когда уже 1С дойдет до идее модульности в своей платформе назад, от которой отказались с переходом 1С77>1C8 ? Чтобы было ядро, подсистема метаданных, подсистема хранения/бд и т.д. А всяческие разные реализации очередных rest/json были в отдельных модулях которые могут обновляться независимо от основной системы если они ей соответствуют. Т.е. система пакетов/dll где части могут быть разных версий, но при обновлении из ядра берутся и качаются последние нужные остальные версии.

+ Это позволит реализовать автообновление даже самой платформы, если ядро не трогается. Т.е. версия 8.3 а далее до 8.4 идет автообновление модулей.

+ Если задокументировать и разрешить делать "свои модуля" будет просто супер )) Но как то кажется что это фантастика... ((

Это ложный путь. Ты утыкаешься dllhell разруливать, если двум решениям потребуются разные версии компонент.

Поверь разница огромная. А я еще и крестиком вязать умею и JavaScript применяю и TypeScript. А вот на мисте давно уже тегами нужно обзавестись или применить markdown

нахрена?

_вязать_ крестиком даже Матроскин не умел...

То есть, COM объекты можно использовать, а вот их аналог в Native ВК ни ни? В чем проблема?

Есть уже отработанные пути разрешения dllhell и это совсем не то. Сейчас ничуть не лучше когда все эти dll банально слиты в одну огромную и с кучей "типа совместимостей". Один фиг глюки/баги все время и конфа не так как нужно на вот этой вроде бы подходящей платформе пашет. Тут можно было бы пофиксить для конфы нужный ей "набор dll" или даже основной набор и для отдельных модулей/внешних обработок свои добавочные. Да внутренности придется переписывать чтобы никаких круговых взаимовызовов между DLL/модулями не было. Каждый модуль может общаться только с ядром и с подчиненными (зависящими от него) модулями.

Блин, уважаю Серджинио1, ни хрена не понимаю конечно в его вызовах Виндовс АПИ, но все равно прятно, что среди нас есть такой грамотный и толковый программист. ))

Например чтобы однажды не проснуться и не узнать что все по 1С спрашивают тут

Спасибо скромно? Только там нет вызовов Виндовс АПИ. Это кроссплатформенный код.

30+ Да помню прекрасный форум Кубань был

Да ладно, неважно. ты молодец. Шаришь. А я уже давно тока в коде 1с разбираюсь и ни  в чем больше  ) И то счас учитывая их БСП походу придется переквалифицироваться в управдомы. ))

27+ Можно сделать простой вариант. Из ВК можно возвращать аналог ВК. За подсчетом ссылок следит 1С и вызывает Done при обнулении сылок, а передавать объекты можно только на вызов метода. ВК внутри не держит ссылок. Этого более чем достаточно, аналог процедурного подхода.

Ну ты дашь посмотреть на ? Меня тоже тема ВК интересует. Юзай Gist и Pastebin, правда.

+ По сути миста сейчас это некий аналог оперативной бесплатной поддержки. И место поболтать/пообщаться а также узнать/обсудить новости. А если по теме ну так сделать 2 стандартных ВК (win|lin) в виде шаблона и к ним шаблон единой ВК, куда пишем код. Далее запускается сборщик который из единой по правилам делает 2 нужных раздельных компоненты и компилирует даже...

так Там ссылка на проект.

+ Это по сути Haxe в который кое кто ударился не будем показывать посты ))

Какой хороший форум. Очень жаль, что там еще нет, пора бы уже, пора... =)

На том форуме не был, но форум по 1с без Serginio1, это плохой, некачественный, форум :-)

Хорошо не поленился и создал на пасте бин Хорошо. Скоро уйду. Спасибо! Останусь.

автор, ничо не выдумывай. в примере 1с с юникодом всё правильно сделано, а обертку можешь сам сделать, ума много не надо. главное чтобы компилировалось в VC и в gcc

Очевидно, что "наружные" процессы должны обращаться к сервисам, а компоненты, предназначенные для расширения самого API - обращаться к API. Да и в случае с ВК потребителем как-раз таки является сторона 1С - пользователь создаёт объект ВК и вызывает его методы. Но через NativeAPI передать он может только примитивные типы, никаких объектов передать нельзя. Ни в одну сторону, ни в другую.

Лучше рейтинг юзеров сделать. В этой радуге смысла ноль.

Сколько их таких было! Если что, Миста — не форум "про 1С".

Какой смысл в передаче, например, какого-нибудь List<> в 1С?

нахрена?

Что бы его заполнить и передать обратно в ВК. На примере Вэб сервиса неподдерживаемого 1С. Там куча классов и клуча методов. Нужно создавать объекты и передавать их в методы. Например пример с HttpClient нужно создавать объектя для использования прокси, сжатия трафика, куков итд. Кроме того проще заполнять 1С совский массив внутр ВК, нежели снаружи. Итд Кстати ты критиковал мои разработки за не кроссплатформенность. Я специально для тебя сделал кроссплатфоменное использование классов .Net. А ты молчишь.

Нахрена? все равно внутри "объекты 1С" передавать низзя или выйдет обычный ole|com... Если программист 1С не умеет сериализовать ручками то ему нафик не нуна ВК писать.

Что кроссплатформенно сделал это супер!!! Теперь только кому то осталось найти кучу времени и сил чтобы эти разработки причесать/допилить и выложить в удобоваримом виде с понятными короткими но полными инструкциями. И найти/оформить понятно несколько примеров из тех "много кода" ))

Ну что бы определенное суждение об авторе уже иметь, а не через полчаса общения с ним.

Программист должен программировать, а не заниматься вручную сериализацией, как многие занимаются при использовании неподдерживаемыми 1С вэб сервисами через HTTPСоединение. Если бы это было кому то нужно. Посмотри даже на примере ТСД там где на Java или C# легко и главное интерфейс под  аппарат используют RDP и считают это оптимальным. А потому, что есть 1С ник, а в других языках никто не разбирается. Опять же я один. Думал может 1С это заитересуют, но ..... никому это не нужно. Но все таки доделаю до конца. Прикручу события, методы расширения, методы с дефолтными параметрами. И плюну на все. Буду искать, что то другое для души.

В 1С есть встроенная сериализация со времен 1С77, а в 1С8 ее даже несколько видов. Потому и не нужно что редко кто понимает "зачем оно?" ему надо. 1С если и заинтересует то сами реализуют своими силами нескольких топовых спецов написавших ТЗ и массы рядовых кодеров.

к 1С-ник хочет нагуглить простое решение чтобы оно заработало из коробки. А нагуглив ВК и нагуглив код на C#/.Net он нифига не сможет без изучения и "перевода в другую систему"

Есть куча примеров которые я написал. Многим тоже пишу код. Проблема даже не в этом, а в боязни использовать. Вот недавний пример. 1С может опаздывать, ломать. А тот же HTTPClient и мощнее и никогда проблем с поддержкой протоколов не было. Но люди боятся, так как это не 1С или известный COM. Но даже например Кирпич. Он может, но не будет. Ему проще ВК писать, чем DLL на C# или вообще код на 1С ипользующий классы .Net. Да и 1С может использовать легко причем кроссплатформенно. Куча основных библиотек это 60 мегабайт и куча компонент можно использовать.

Люди любят "удобство", которого перейдя по любой приведенной ссылке нет и в помине. как и я написал уже удобный для себя способ использования/вызова кода на C# или Java. У меня еще есть десериализатор объектов 1С и обратный сериализатор на C# и на Java и все становится очень удобно.

И в чем там неудобство Кирпич будет использовать либо COM как и ты. Либо писать свои ВК. Правда Кирпич еще использует Динамическую компиляцию. У меня есть все. И не надо писать никаких сериализаторов. Используй объекты. Для примера работа с Вэб сервисами через Объекты .Net удобнее чем с родными и кстати мало чем отличаются по сути. Есть типы, объекты пространство имен. Но  ...

57+ Кстати Кирпич признался, что если бы 1С от себя прелагалабы применение .Net классов в 1С, то он их бы использовал.

Ну напиши уже свой 1С на .Net ...

Зачем? Я написал компоненту которая расширяет возможности 1С. Еще раз даже родные компоненты для работы с Вэб, файлами и прочие малофункциональны и не поддерживают всех возможностей. Зачем писать, что то свое если можно использовать стандартные библиотеки? И не надо писать прослойки между C++ и 1С.

Вернее не нужно писать отдельно прослойки между библиотеками на C++ и 1С. Есть уже одна готовая между 1С и библиотеками .Net кроссплатформенная! Каждый раз создавая прослойку есть большая вероятность ошибки. Проще довести до ума одну. Это дает 1. Использовать бОльший функционал 2. И соответственно, так как 1 прослойка то её проще совершенствовать, тестировать и соответственно меньше ошибок. 3. Быстрее использовать нововведения в Вэб и прочих направлениях. 4. Более простое расширение с помощью пользовательских классов .Net. Это же относится и к Java. Просто я написал на .Net

61+ Что касается перегрузки методов и чувствительность к регистру, то ткаие классы можно помечать специальным атрибутом и обрабатывать соответствующим способом. Это даже проще.

Тут все общаются на тему создания внешних компонент native api, но у меня вопрос немного другой. Можно ли через native api подключиться из одной ИБ к другой и соответственно иметь com-подобный доступ к объектам подключенной базы? Или как можно реализовать COM/OLE-подобный доступ, если система не виндовс?

Закину сюда, чтоб ветку не плодить

<BLOCKQUOTE>После двух лет с момента прошлого выпуска компания Microsoft объявила о начале альфа-тестирования новой версии Skype для Linux. Новый Skype примечателен полной переработкой с переходом на использование web-технологий для интерфейса и протокола WebRTC для организации канала связи. Новый клиент Skype построен с использованием платформы electron, т.е. по сути является упакованной в самодостаточное приложение надстройкой над Chromium и Node.js, в которой выполняется расширенный web-клиент.</BLOCKQUOTE>

Здесь несколько вариантов web,Http сервисы, ODATA или прямой доступ

Сюда-то зачем?

там в полной версии новости, если бы я ссылку вставил, обсуждалось в комментах использование NODE.js

И каким боком это к ВК и 1С?

Все эти "доступы" не дают доступа напрямую к объектной модели, как в com/ole. Значит, никак?

Пока 1С не сделает аналог COM

Для чего нужен этот "аналог COM" ?

То есть не надо писать ВК. Можно просто писать определенные классы на .Net или Java и использовать их в 1С. Например сейчас на Линуксе из-за отсутствия COM в основном используют Вэб или HTTP сервисы. Но это отдельный процесс и скорость низкая из-за маршалинга (сериализации десериализации) и задержками между процессами. ВК это тоже аналог COM только кастрированный.

Лучше сюда ссылку давай тут хотя бы слегка причесано, интересно сколько времени убил )) OLE/COM это тоже отдельный процесс и низкая скорость, но т.к. изначально программисты вынужденно пишут свой код чтобы оно поддерживалось из коробки то тормоза не так заметны. И 1С потихоньку идет к этому например .

+ И попытка уже была не от 1С.

Это еще вопрос, что лучше - терпеть накладные расходы на сериализацию-десериализацию данных через новомодные методы веб-доступа, или же прямой доступ к com-серверу в общем адресном пространстве. Конечно, com сам по себе тоже весьма убог, потеря точности при неявном преобразовании чисел 1с в плавучку чего стоит. Было бы неплохо, если бы 1с изобрела очередной велосипед "native com", лишенный всех недостатков виндового и в то же время чтобы он был кроссплатформенным.. Но наверное это дико сложно.

2 Недели на реализацию. Но много дал опыт комовской реализации. Оле/Com есть как внутрипроцессорный (v83.comconnector ) и внешний сервер (v83.Application) Там разница нехилая.

Прямой доступ в общем адресном пространстве это когда на одной машине. Но сейчас это уже глупость так как комп/прога без сети/инета уже ничто. Т.е. механизма нужна сетевая когда клиент и сервер разделены сеткой вот и выходят самыми удобными "новомодные методы веб-доступа".

COM поддерживает Decimal. Это не дико сложно. Уже есть в 73.

Дык спрашивал не про время кодинга, а про время чтобы оформить статейку ))

Да день.

А 1с об этом знает? С какой версии?

В любой. Только вот для нормального использования нужно либо интегрировать в 1С либо допиливать ВК для возврата объектов (аналогов ВК)и передачи объектов в параметрах. В статье этот аспект подробно описан.

Речь не о ВК, а о связи 1с с 1с.

Посмотри

Какие-то непонятные костыли на каком-то сишарпе.. При чем тут вообще 1с?

Не обижайте художника! Он так видит!

Ты спрашивал про ком под Линукс. В 1С это не реализовано, но через 79 и 83 это можно реализовать. Тема то про ВК.

гм ту про oscript.io напомнили, вот бы туда еще обычную net|mono добавить по твоему методу

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

Так это же как раз твоя фишка по использованию мощностей .Net из языка 1С. Тама есть язык 1С, а мощностей не наблюдается все порезано. Вот сделал бы чтобы все как в 1C с твоим изобретением было ))

Ему не надо 1С, ему надо, чтобы народ на c# писал, как же ты не поймешь =) Просто написать ВК на том же с# и использовать ее - скучно. Поэтому надо заипаться связкой с 1С через ъТип и прочую невразумительную поипень, да еще и еще заипать других ссылками на stackoverflow с чистым с#.. А потом удивляться, почему это никого не штырит =)

Они там как раз .Net внутри используют. А потому, что Native ВК нет возможности передать объект или передать объект в параметрах. Но это все равно значительно проще чем писать ВК.

Я тебя впервый раз слышу, а уж тем более не занимался с тобой сексом.

Посмотри исходники

Удобная позиция, чо.

Я никого не заставляю использовать мои продукты. Я только показываю пути решения, если на 1С их решить нельзя. А у того кто задает вопрос есть выбор.

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