Ошибка при работе с типами COMОбъекта #728469

Всем привет. Платформа 8.3.5.1119, при работе с ABBYY FlexiCaptureEngine через COMОбъект возникает ошибка "Типы не совпадают ". API FlexiCaptureEngine предоставляет интерфейс для распознавания текста изображений и экспорта этих данных в нужном формате. В строке document = processor.RecognizeNextDocument; получаем объект типа Document (объект со свойствами и методами распознанного документа). В 1С он преобразуется в COMОбъект, далее этот документ необходимо передать в метод ExportDocumentEx для экспорта. Первый параметр этого метода так же ожидает объект типа Document. Но при вызове метода как указано в примере выше возникает ошибка "Типы не совпадают ". Какие могут быть варианты решения?

?

мдааа слов нету прям из анегдота когда один программер печатает 2 камаза бумаги, а другой их распознает

Нельзя позвонить поставщику и попросить прислать тоже самое но в Excel? Ну или в PDF но которая из текста а не картинкой?

Может

мы как-то попросили, нам отказали. один фиг в pdf таблицы нарисованы поверх текста.

пришлось мутить конвертацию pdf

позвонить и попросить можно, чо ж нельзя-то?.. Правда получить положительный ответ на просьбу вряд ли получится. Такова вот селяви

а может тогда поискать после выбора образа и перед распознанием?

или вообще лучше через создание пакета(batch) пойти

2012 год, какая там версия?

это к чему?

в 11 просто примеры. там в 4 параметре стоит неопределено (null) Скачивай последний SDK который будет поддерживать последние версии

Пробовал, не помогло, еще пробовал создавать пустой документ Тоже не помогло Пробовал Непределно, 0, пустые строки, нули, просто ничего не передавал processor.ExportDocumentEx(document, "C:ТовНаклПроектФлКапч", "exportFileName", ); все глухо, ну и судя по всему ошибка в первом параметре Не то, этот метод загружает определения документа в память и делает настройки конфигурации, для серверных решений. Пробовал, есть разница между работой через батчи и с использованием процессора. Везде свои "+" и "-", мне нужен именно вариант процессора. Батч тоже пробовал, там возникает ошибка при заполнении экспортных параметров в файл, могу описать её, но это трата времени. И вообще во многих местах, где необходимо передать параметры (в методы ком объекта) и, судя по документации, можно передать значение "0" для использования параметров по умолчанию, возникают ошибки и приходится создавать пустые объекты, и их передавать в виде параметров. Именно это я и хочу реализовать. В примере кода инициализация engine  на с++ происходит вызовом InitializeEngine, этот как я понимаю процедура из предварительно загруженной FCEngine.dll (могу ошибаться.) Вообще вот этот кусок мне на 100% не ясен [DllImport("FCEngine.dll", CharSet = CharSet.Unicode), PreserveSig] private static extern int InitializeEngine(string devSN, string reserved1, string reserved2, out IEngine engine); [DllImport("FCEngine.dll", CharSet = CharSet.Unicode), PreserveSig] но в 1с я все равно могу только реализовать все это через COMОбъект, как указано в . , Версия 10. SDK последняя. Неопределено пробовал, и много чего еще, как и писал выше.

Мой вариант такой что 1С конвертирует тип значения document  при его получении document = processor.RecognizeNextDocument; в COMОбъект, а далее при передаче в processor.ExportDocumentEx(document, "C:ТовНаклПроектФлКапч", "exportFileName", 0); переменная document не конвертируется в ожидаемый методом тип FCEngine.IDocument. вот пример из VB Public Engine As FCEngine.IEngine Dim processor As FCEngine.IFlexiCaptureProcessor Dim document As FCEngine.IDocument ... По хорошему 1С здесь надо бы уметь сделать что-то типа Поэтому мой вариант это писать внешнюю комноненту на том же c++, VB, Delphi... на всем что нормально отработает вызовы методов и передачу параметров. А дальше уже используя ВК делать то что необходимо. Но писать эту ВК не хочется. Может есть какой вариант заставить все это цивилизованно работать и без ВК.

Можешь использовать сборки Net

зачем писать ВК когда можно быстро использовать vbs?

Да, тоже этот вариант решил сначала проверить и выяснилось в итоге что проблема была в некорректно написанном определении документа "C:ТоварнаяНакладная.fcdot". Хотя оно отлично отрабатывало в FlexiCapture 10, при использовании в коде тоже не выдавало явных ошибок, указывающих на его проблемы. Но при тестировании данного кода на тестовых данных из поставки sdk все отлично отрабатывает. Тема закрыта.