1с зависает при подключении внешней компоненты
Интересный вопрос: почему новая технология Native API уступает старой технологии COM отсутствием доступа к методам глобального контекста (AppDispatch)? Ведь все новое должно быть лучше старого.
AppDispatch - это доступ к более сотни функций 1С. Я, например, в 8.1 перевожу произвольный макет в byte[] используя вызов Base64String и обратный System.Convert.FromBase64String.
ну это, мягко говоря, не правда Native API сделали для того чтобы компоненты можно было писать такие компоненты, которые могут работать везде где работает код 1С, на обычном клиенте, на сервере, web-браузере. Соответственно и в среде разных ОС Windows и Linux, т.к. сервера и браузеры могут работать на Linux. В Linux нет COM, соответственно Native компоненты COM не используют. Соответственно нет COM - нет и AppDispatch. Все просто у них. :)
В веб-клиенте я надеюсь увидить пространство имен JScript Web.GeneralContext. Меня это устроит - в нем представлены все методы глобального контекста.
А может Вам заняться написанием NetBridge для навижн? Все условия: 1. работает только на винде 2. родная поддержка .нет 3. родной СОМ 3. никаких "гипотетических пользователей линукс"
Почему я выразился "гипотетические пользователи Linux". 1С - традиционно Windows-приложение. Если клиент, то традиционно Windows, если СУБД, то традиционно MSSQL. Сколько у вас на памяти чистых Linux-клиентов? У меня ни одного. Даже на западе (в Италии), где преобладает Linux, мы собирали статистику. В средней компании 2 сервера: Windows и Linux, а клиенты все Windows. На кого нацелены все Linux-фичи 1C?
struct _tVariant почемы ты решил что определение этой структуры имеет какое-то отношение к COM? Потому что она имеет похожее название и назначение со структурой VARIANT применяющейся в COM? И то что объект Native ВК определяется с помощью нескольких интерфейсов тоже к СОМ отношения не имеет. Это всего лишь технология COM ТОЖЕ использует интерфейсы. В COM все интерфейсы должны быть унаследованы от IUnknown, в Native ВК интерфейсов это не так. Да там применяются интерфейсы как элементы языка С++, но COM тут непричем.
Насамом деле, то что в Linux нет COM (или аналогичного общего универсального механизма) это не фишка его - это его беда. Например одно из ярких проявлений этой беды: если сервер 1С на linux, то регламентными заданиями, которые работают на сервере, нельзя организовать обмен данными между базами традиционными средствами: ComConnetor-а нету.. И нет никакого аналогичного средства доступа к данным базы.
Да потому что в клиенте 8.2 осталась поддержка COM-интерфейсов ВК, совместимых с 7.7. Вы думаете, что в 1С было реализовано 2 принципиально разных механизма работы с ВК? Я сомневаюсь. В подтверждение моих слов Internet Explorer, который не вписывается в технологию Native API - это так называемый "финт ушами" через COM. Нигде не сказано в документации о интерфейсе IAddInServiceEx для MSIE.
>>Вы думаете, что в 1С было реализовано 2 принципиально разных механизма работы с ВК? Я сомневаюсь. Тут нечего сомневаться это написано в документации.
IAddInServiceEx - это бомба Native API, которая не описана в документации - это интерфейс работы ВК на IE, описанный в примере AddInIE->AddInIE.idl как
Самое интересное - этот интерфейс действующий, достаточно загнать IE-dll в CAB, подписать и вызвать ВК через ПодключитьВнешнююКомпоненту("","". ) из IE.
На счет IE и механизма загрузки компоненты в веб-клиентах вцелом - незнаю не смотрел не щупал.. Но механизм мне видится мне таким: сами браузеры никогда в жизни не будут цеплять простые dll полученные с web-сервера это не безопасно вообще-то, но там можно применить проверку каких-либо удостоверений. Для загрузки компонент например в IE может использоваться некий AtiveX получаемый с web-сервера под isapi расширением от 1С, как бы загрузчик Native компонент, он будет удостовереный сертификатом (его авторы - 1C), поэтому встанет по тихому, без вопросов. А вот грузить саму Native компоненту уже будет он, и предоставлять интерфейс объекта будет он. IAddInServiceEx - кстати не его ли интерфейс? по имени весьма подходит.
Ну вот чо, именно так у них и сделано. А он и не дожен быть описан к документации. Это часть реализации веб-клиента. Причем возможно что именно такая реализация для IE. Для хрома или оперы под которые работают под linux будет другая. Для эпполовского safary, например, может быть когда нить напишут третью.
В 8.2 COM компоненты кстати тоже нельзя загрузить на сервере как и в 8.1. Странные они.. COM компоненты нельзя, но зато запросто можно просто COM объекты, удивительно!
угу, вот снизойдет на 1С божья благодать, сделают они как-нибудь доступ к родным объектам 1С из компоненты - вот тогда попрет у всех. :)
Да он сам себе сделает, я честно говоря не верю что dll с /clr просто так вот не грузится.. надо искать причину.
О спец-библиотеке для IE от 1С речи пока не идет. Хотя, полностью согласен, так было бы грамотнее всего сделать и такое решение гармонично бы вписалось в подход Native API. Не нужно было бы напрягать разработчиков частными подходами. Сейчас для IE с сервера получают .cab-файл, который устанавливается средствами Windows с регистрацией всех библиотек, если нужно. Далее идет создание объекта с именем в файле MANIFEST.xml через Web.AddIn.Adaptor=new ActiveXObject(
блин. вот смотрю и думаю. А как предполагается борьба с различными версиями .Нет у пользователя? ведь если ВК попадет к юзеру из макетов, то далеко не факт, что у него уже точно стоит .Нет4. Ответ есть на этот вопрос?
Раз уж сюда зашел продублирую Странно, что натив код может обнаружить сейв код как нативный. Видно я давно Рихтера не читал, но даже загрузка сейв кода происходит через СОМ ком обертку. Во первых непонятно зачем использовать NativeAPI там где можно работать через ком напрямую? ПодключитьВнешнююКомпоненту(<Местоположение>, , ) NativeAPI это прежде всего для Линукса.Местоположение>
Суффикс = "";
Попытка
ВК = Новый ("AddIn.ирОбщая.AddIn");
Суффикс = "СломанОбщийКэш";
ВК.PID();
Исключение
Это64битныйПроцесс = ирКэш.Это64битныйПроцессЛкс();
ИмяМакета = "ВК";
Если Это64битныйПроцесс Тогда
ИмяМакета = ИмяМакета + "64";
Иначе
ИмяМакета = ИмяМакета + "32";
КонецЕсли;
Если ирКэш.ЛиПортативныйРежимЛкс() Тогда
ДвоичныеДанные = ирПортативный.ПолучитьМакет(ИмяМакета);
Иначе
ДвоичныеДанные = Обработки.ирПортативный.ПолучитьМакет(ИмяМакета);
КонецЕсли;
АдресКомпоненты = ПолучитьИмяВременногоФайла("dll");
ДвоичныеДанные.Записать(АдресКомпоненты);
//АдресКомпоненты = "D:\VC\Native_Comp_RDT\binWin32\AddInNative.dll"; // Для отладки
Если Суффикс = "СломанОбщийКэш" Тогда
// https://www.hostedredmine.com/issues/889213
// Отказываемся от кэширования для всех сеансов. Так каждый сеанс будет хранить в кэше свой экземпляр компоненты
Суффикс = ИдентификаторИзПредставленияЛкс(Новый УникальныйИдентификатор);
КонецЕсли;
Результат = ПодключитьВнешнююКомпоненту(АдресКомпоненты, "ирОбщая" + Суффикс, ТипВнешнейКомпоненты.Native);
Если Не Результат Тогда
ВызватьИсключение "Не удалось подключить внешнюю компоненту Общая";
КонецЕсли;
ВК = Новый ("AddIn.ирОбщая" + Суффикс + ".AddIn");
//ВК.PID();
КонецПопытки;
Возврат ВК;
Про инициализацию:
подозреваю, что если вернуть компоненту к исходному состоянию шаблона (с пустыми реализациями методов), то ситуация у пользователя не повторится.
Научите правильно писать внешнюю компоненту или доказать, что я не виноват.
Принцип такой: всё что ты создаешь и удаляешь сам, на это память выделяй сам и без менеджера памяти 1с.
Вся память, которая будет выделена в значениях 1С tVariant (строки и двоичные данные) для передачи в 1с, должна быть выделена менеджером памяти 1С. Ибо удалять эти значения будет 1с, а не ты.
Если ты создашь строку tVariant, выделишь под нее память не менеджером 1с и вернешь эту tVariant в 1с, то 1с когда нибудь е попытается удалить, а памяти, из которой сделана твоя tVariant уже не будет и будет глюк.
Но у тебя просто виснет. Может дело и не в памяти. А что ВК вообще делает?
(4) Ну собрано уже много диагностической информации. Вроде уже и сама тех. поддержка 1С перестала давить на тему кривой реализации ВК.
Общие признаки зависаний такие:
1. ОС Windows 7 x64. На Win10 не виснет.
2. Нет зависимости от файлового или клиент-серверого режима. Виснет в обоих вариантах.
3. На 8.3.17 не зависает. На 8.3.18 и на 8.3.19 зависает.
CritSec ntdll!LdrpLoaderLock+0 at 00000000774b80d8
CritSec +57e6488 at 00000000057e6488
*** WARNING: Unable to verify checksum for v8_BE9A_8.dll
CritSec v8_BE9A_8!GetClassNames+1c3b0 at 000007fecce5d4e0
Scanned 16879 critical sections
(4) > что ВК вообще делает?
Виснет просто на создании ВК, т.е. до "делает" дело обычно даже не доходит.
Зачастую у программистов возникают проблемы с подключением внешних компонент (например, драйверов торгового оборудования), когда пользователи работают с 1С, подключаясь к серверу через терминал.
Это связано с некоторыми особенностями работы функции глобального контекста ПодключитьВнешнююКомпоненту().
Зачастую у программистов возникают проблемы с подключением внешних компонент (например, драйверов торгового оборудования), когда пользователи работают с 1С, подключаясь к серверу через терминал.
При этом пользователи видят, например, картинку представленную в анонсе статьи.
В то время как при работе с локальных компьютеров никаких проблем с подключением внешних компонент нет.
С чем это связано? Это связано с тем, что, когда пользователи работают через сервер терминалов, они имеют меньше прав, чем при работе на локальном компьютере.
В этом легко убедиться, если зайти на сервер терминалов под учетной записью с административными правами.
Причина такой разницы заключается в том, что 1С не может зарегистрировать внешнюю компоненту в реестре, когда пользователь работает в терминале под обычными правами, т.к. у обычного пользователя нет прав на запись в ветку системного реестра HKEY_CLASSES_ROOT.
В публикациях на тему подключения внешних компонент в терминале предлагаются самые разные методы решения этой проблемы.
1. Запустить первый раз 1С под административными правами.
Этот вариант далеко не всегда срабатывает. Ниже объясню, почему.
2. Дать обычным пользователям терминала права на запись в ветку системного реестра HKEY_CLASSES_ROOT.
Недостаточно "продвинутым" пользователям лучше этого не делать, иначе могут быть проблемы.
3. С помощью различных "примочек" регистрировать ВК от имени пользователя с полными правами.
Тоже не есть хорошо.
Так как же все таки лучше выйти из этой ситуации?
Я предлагаю свой вариант решения этой проблемы. По моему мнению - простой и красивый, не предлагавшийся на инфостарте ранее.
Дело оказалось в том, что в типовых конфигурациях 1С (например "Управление Торговлей") используется такой синтаксис метода глобального контекста ПодключитьВнешнююКомпоненту():
ОбъектДрайвера = Новый ("AddIn.АТОЛСканер.Scaner45");
Как видим, ВК драйвера подключается из макета "ДрайверАТОЛСканерШтрихкода" справочника "ПодключаемоеОборудование".
Что же при этом происходит?
1С сохраняет компоненту во временной папке пользователя, например "C:\Documents and Settings\User\Local Settings\Temp\1032\v8_4_12.tmp"
и пытается зарегистрировать ее в ветке реестра HKEY_CLASSES_ROOT именно по этому пути.
На терминале у обычных пользователей нет прав на изменение этой ветки реестра, поэтому компонента у них не подключается.
Теперь о том, как выйти из этой ситуации.
Метод глобального контекста ПодключитьВнешнююКомпоненту() имеет несколько вариантов синтаксиса. Вот этим мы и воспользуемся.
Итак, по шагам:
1. Регистрируем внешнюю компоненту утилитой regsvr32.exe на сервере терминалов в папке C:\WINDOWS\SYSTEM32 для 32-разрядной ОС или в папке C:\WINDOWS\SYSWOW64 для 64-разрядной ОС.
2. Используем один из двух дополнительных вариантов синтаксиса метода ПодключитьВнешнююКомпоненту():
Вариант 1:
ОбъектДрайвера = Новый ("AddIn.АТОЛСканер.Scaner45");
Вариант 2:
ОбъектДрайвера = Новый (ProgID);
На мой взгляд, вариант № 2 предпочтительнее.
При этом 1С не пытается перерегистрировать ВК по новому пути в реестре и таким образом, все проблемы решаются.
Ну вот собственно и все. Успехов в работе!
Специальные предложения
В то время как при работе с локальных компьютеров никаких проблем с подключением внешних компонент нет.
Глубоко ошибаешься. В путних сетках и тут проблемы, потому что в путних сетках и локальных административных прав у юзверя быть не должно. А то они там нарегят/наинсталлируют!
Там и софт по минимуму, все что нужно - в терминале. :)
Но, если так необходимо, то, думаю, на локальной машине данная методика также будет работать, т.о. "ложка не существует". :)
Очередной баян для новичков в работе с внешними ВК.
Со времен 77 здесь ничего не изменилось :)
Но за изложение плюсую.
Ничего не изменилось говорите?
Вы хоть в сути описанной в статье проблемы разобрались?
Разве в 77 внешние компоненты хранились в макетах справочников?
Разве 77 сохраняла их во временном каталоге пользователя и пыталась их потом там зарегистрировать?
(6) А если еще подумать?
В 77 также были случаи неверной регистрации ВК - например, Админ в терминале заходит в одну базу и регистрирует ВК из каталога базы, а пользователь, у которого эта ВК юзается, но в другой базе, не может запустить эту ВК, если у него прав на папку с первой базой :(
Поэтому, например, для нормальной работы в 77 и придумано куча решений - тот же вариант с RunAs или загрузка обычных ВК через спец.ВК от Саши Орефкова и т.п.
Я же говорю - по работе с ВК ничего не изменилось!
А описанные проблемы - это проблемы прикладного кода, в частности, кода по работе с торговым оборудованием.
Разработчики этого кода либо не знали о сабжевой проблеме, либо пренебрегли ей :(
ЗЫ кстати, в 77 ВК также можно было хранить в макетах, правда, с использованием доп.ВК :)
ЗЗЫ а еще обрати внимание - плюс-то я тебе все-таки поставил :)
Вот это по моему мнению как раз и есть "париться" - т.е. разобравшись в сути проблемы только наполовину, искать обходные пути для ее решения.
Вот это по моему мнению как раз и есть "париться" - т.е. разобравшись в сути проблемы только наполовину
Ага, наполовину. Суть проблемы элементарна - отсутствие прав.
Ссылка раз и навсегда решает проблему того же regsvr32 БлаБла у любого юзверя выполнением RunAs от имени пользователя с админскими правами.
Ну-ка расскажи в чем ты там ПОЛНОСТЬЮ разобрался?
На терминале у обычных пользователей нет прав на изменение этой ветки реестра, поэтому компонента у них не подключается.
.
Итак, по шагам:
1. Регистрируем внешнюю компоненту утилитой regsvr32.exe на сервере терминалов в папке C:\WINDOWS\SYSTEM32 для 32-разрядной ОС или в папке C:\WINDOWS\SYSWOW64 для 64-разрядной ОС.
Ну в чем профит-то? В том что вы взяли её и зарегистрировали? Явно кто-то в чем-то полностью переразобрался.
Не понял смысл статьи.
Админ и так знает, как зарегистрировать dll-ку, у 1Сника при нормальном распределении обязанностей нет никаких прав на серваке.
Вот именно - отсутствие прав это вторая половина проблемы.
А первая и основная половина состоит в том, почему 1С пытается перерегистрировать ВК, и как этого избежать.
Потому что не надо использовать (в т.ч. и фирме 1С) дебильную ПодключитьВнешнюю.. с разными там синтаксисами,
а надо использовать ЗагрузитьВнешнююКомпоненту(ПолныйПутьКДЛЛ), а либы лучше всего хранить в КаталогПрограммы(), либо (для файлухи и 7.7) в КаталогИБ()
cool.vlad4 пишет:
Ну в чем профит-то? В том что вы взяли её и зарегистрировали? Явно кто-то в чем-то полностью переразобрался
Не спешите с выводами не разобравшись.
Дело в том, что вы ее хоть сто раз зарегистрируйте, но если вы оставите без изменений типовой код,
1С будет безуспешно пытаться ее перерегистрировать снова и снова.
(12) Не спешите с выводами, по поводу того, что я спешу с выводами не разобравшись. В типовой так сделано, потому, что ребята делали универсально, они не могут сидеть за вашим компьютером и регистрировать от имени администратора компоненту, не зная пароля тем более. А админы прекрасно об этом знают и ручками зарегят или скрипт напишут(run as). А ваша статья просто кэпство, но самое противное - преподносится как доселе неведомое чудо.
Ну что тут сказать? Значит невнимательно читали статью, или никогда не сталкивались с такими проблемами.
Конечно, админ знает, как зарегистрировать dll-ку.
Он ее и регистрирует. Но потом оказывается что у рядовых пользователей она в терминале не подключается.
Вот в чем суть проблемы то!
У вас видимо патологическое отвращение к чужим разработкам.:)
Конечно, это не чудо. Но тем не менее, я когда столкнулся с этой проблемой, нигде в инете не нашел объяснения причин этой проблемы. Везде освещалась только вторая часть проблемы (недостаток прав на реестр) и способы ее обхода. И нигде не говорилось об основной части проблемы - почему 1С пытается перерегистрировать ВК по новому пути.
Согласен, не спорю. Спасибо.:)
artbear пишет:
А описанные проблемы - это проблемы прикладного кода, в частности, кода по работе с торговым оборудованием.
Разработчики этого кода либо не знали о сабжевой проблеме, либо пренебрегли ей :(
Совершенно верно. Но рядовому программеру от этого как бы не легче.
А эта статья конечно не претендует на какую-то особенность и гениальность.
Это просто статья человека который столкнулся с проблемой, и не нашел приемлемого для себя метода ее решения в инете.
Это попытка самостоятельно разобраться в проблеме и поделиться своим решением с другими - быть может сэкономив кому то время на решение аналогичных проблем.
Здесь есть одно большое НО.
А мне нужно было подключать сканер штрих-кодов в ТОНКОМ клиенте.
(19) сканер штрих-кода успешно подключается в тонком клиенте, пример реализации можно посмотреть в УПП 1.3, в последних двух релизах
А скажи на милость: на фига в ТЕРМИНАЛЕ еще и тонкий клиент?
Терминал сам по себе уже тонким клиентом является
Abadonna пишет:
А скажи на милость: на фига в ТЕРМИНАЛЕ еще и тонкий клиент?
Терминал сам по себе уже тонким клиентом является
Ну, тут уж как бы наше руководство так решило для единообразия.
Как пел Высоцкий, "Жираф большой - ему видней".:)
Все работают с 1С в тонком клиенте управляемого приложения.
Чтобы можно было и через терминал подключаться и просто с локальной машины.
fishca пишет:
сканер штрих-кода успешно подключается в тонком клиенте, пример реализации можно посмотреть в УПП 1.3, в последних двух релизах
Пример реализации я брал из УТ11.
Он то конечно подключается, если у пользователя достаточно прав на запись в ветку реестра .
А вот если у пользователя недостаточно этих прав, тогда и начинаются проблемы которые описаны в этой статье.
После выполнения regsvr32 весь код укладывается в одну строку:
ОбъектДрайвера = Новый COMОбъект("AddIn.Scaner45");
Чтобы не быть голословным - рис.
(24)
"После выполнения regsvr32 весь код укладывается в одну строку:
ОбъектДрайвера = Новый COMОбъект("AddIn.Scaner45"); "
А страница свойств компоненты появится при таком подходе ?
Abadonna пишет:
После выполнения regsvr32 весь код укладывается в одну строку:
ОбъектДрайвера = Новый COMОбъект("AddIn.Scaner45");
Ну, раз говоришь что работает, верю.
Хотя мне это кажется странным. По идее не должно было.:)
Именно, что должно . :)))
Это как раз стандартное обращение к зарегенным в реестре интерфейсам COM, Active-X
В 7.7 это было бы так: Lib=СоздатьОбъект("Miracle.VCL")
В Дельфи: Lib:=CreateOleObject('Miracle.VCL')
И в любой другой виндовой хрени аналогично ;)
Да, но в 7.7 перед этим вызывался метод ЗагрузитьВнешнююКомпоненту("FormEx.dll");
Без этого СоздатьОбъект() не работало.
Ладно, начнем ликбез по порядку :))))
1. ЗагрузитьВнешнююКомпоненту от 1С - как раз и производит регистрацию в реестре интерфейса соотвествующей либы, написанной по технологии создания внешних компонент от 1С (ТСВК). Вот именно в этом случае, и возникает трабла с правами на запись в реестр, неважно в каком месте: на терминале или локальном компе
2. СоздатьОбъект - уже и создавала (в аналогии 8.2) Новый COMОбъект по указанному progid
В 8.2, как в обычной виндовой программе, все точно так же.
Если ЛЮБАЯ ВК написана по технологии COM и предварительно зарегена через regsvr32 (т.е. уже есть progid), никаких
Подключить/ЗагрузитьВнешнююКомпоненту уже не надо ни в 7.7, ни в 8.2.
В моем примере выше либа для 7.7 писалась не по ТСВК, она обязательно требовала regsvr32, но при этом совершенно не понимала никаких Подключить/ЗагрузитьВнешнююКомпоненту
+(29) А FormEx.dll - вообще супер-специфичная либа, там Лёха залез в самое нутро 1С, последние её версии вообще в реестре следов не оставляют, и ЗагрузитьВнешнююКомпоненту("FormEx.dll") пройдет всегда, у любого юзверя, с любыми правами
УТ 10.3. Платформа 8.2.13.202. У меня при настройке перенаправленого в терминальный сервер торгового оборудования выпадает 1С при тестировании драйвера. Однако если на это не заморачиваться, то Интерфейс Кассира работает и чеки пробиваются. Может кому-то пригодится, т.к. мы очень долго не понимали в чем дело и не пробовали пробить чек из Интерфейса Кассира ))))
В описанном мной случае проблемы возникали когда ВК хранится в макете справочника.
При подключении она сохраняется во временный файл временного каталога пользователя.
Поэтому для использования RegsvrEx нужно знать полный путь к этому временному файлу.
Ну а вообще использование нескольких дополнительных разработок вместо стандартного
типового механизма и маленькой правки кода не кажется мне оптимальным.:)
(33) Смею заметить, ничего против Вашей публикации не имею :). "стандартный типовой механизм" не всегда вставляет, иногда своя реализация кажется более универсальной :).
Спасибо за просвещение, а то у БиТ купили продукт, а они используют свой сервер лицензий, и для этого пытаются регистрировать внешние компоненты, до сих пор приходилось делать запуск под Админом, теперь попробуем переписать чтобы было по человечески.
Спасибо за статью. Столкнулся с аналогичным случаем при работе с эмулятором фискального регистратора. Конечно же лучше запускать 1С через тонкий клиент с машины к которой подключено оборудование, но некоторые клиенты настаивают на использовании терминала ( тем более если фискальный регистратор виртуальный - используется эмулятор). Почему-то после обновления УТ11 до 11.1 вдруг 1С стала просить драйвера на эмулятор фискального регистратора, хотя сканнер штрих-кодов продолжает прекрасно работать.
Добавил бы уточнения к алгоритму решения этой проблемы: ( которые кстати подчерпнул из вашего же комментария только в другом форуме )
В общих макетах лежат драйвера различного оборудования. Там собственно и хранилась нужная мне dll.
Щелкаем на этом макете и нажимаем кнопочку "Выгрузить в файл".
Файлу даем любое имя и расширение zip.
Открыв архив видим несколько файлов, в том числе нужный мне FPEmulator1C.dll. Распаковываем и копируем его в зависимости от разрядности windows в папку для 32х - C:\Windows\Sysytem32 , для 64х - C:\Windows\SysWOW64.
Запускаем Пуск/Все программы / Стандартные / Командная строка - только правой кнопкой мыши вибираем "Запуск от имени администратора" . В командной строке переходим в нужную папку (C:\Windows\Sysytem32 или C:\Windows\SysWOW64 ).
В командной строке - cd C:\Windows\Sysytem32
Пробуем регистрировать его с помощью команды regsvr32.exe .
В командной строке - regsvr32 FPEmulator1C.dll
Если все успешно тогда переписываем код в конфигурации в соответствии со статьей.
С выходом 1С 839 появился баг в работающей до этого компоненте.
На серверной базе (на файловой все работает отлично) хоть тресни сыпет ошибки Тип не определен на всех попытках вызова классов.
Причем появлятся это только после второго использования.
То есть первый раз - все работает замечательно!
Но стоит только второй раз запустить туже обработку с компонентой - сыпет баг и хоть тресни.
Повторюсь - на файловой версии все отлично.
На серверной - баг после повторного использования.
Он сам не знает и не понимает - уже переколошматили все.
Все отлично работает за исключением сказанного.
Сервер - второй запуск.
А повторное подключение любой другой компоненты работает нормально?
Если да, то проблема именно в этой конкретной ВК, может, завершается там где-то чего-то некорректно.
Если с другими компонентами так же, может, это "фича" платформы.
(2) Значит ВК уже выгрузилась. Смотри где Ссылки на ВК обнуляются. Я на 64 разрядной пробовал все нормально.
(10) для серверной этот метод не доступен.
Единственный метод который доступен это ПодключитьВНешнююКомпоненту и он работает
(3) Ну то есть разработчик с дебаггером студии не смог отловить процесс инициализации компоненты и ошибку, которая в этот момент возникла, а мы тут по кофейной гуще всё угадаем?
Клиент х64 только в 8.3.9 появился, до этого только х86 (значит, все файловые версии х86), а сервера часто х64, компонента компилится отдельно для х86, отдельно для х64 - ты хоть сказал бы, какая архитектура. У тебя там вообще разные билды этой компоненты могут быть.
Платформа содержит оптимизацию - она в кэше хранит ВК и повторно подключает не так, как первый раз.
1. Попробовать поменять дурацкое имя XLS (которое в середине. Его определяет тот, кто использует метод ПодключитьВнешнююКомпоненту во втором параметре). Возможно, происходит конфликт где-то из-за имени
2. Если не помогает, генерить новое произвольное имя при каждом использовании. Это заполонит кэш, но по идее будет работать
(15) Так глюка с подключением во внешней обработке, когда на первое открытие обработки все ОК, а если повторно то нифига не сервере не пашет.
Потому что некоторые дятлы до сих пор не смогли понять что такое клиент-серверная УФ 1С.
Зачастую у программистов возникают проблемы с подключением внешних компонент (например, драйверов торгового оборудования), когда пользователи работают с 1С, подключаясь к серверу через терминал.
Это связано с некоторыми особенностями работы функции глобального контекста ПодключитьВнешнююКомпоненту().
Зачастую у программистов возникают проблемы с подключением внешних компонент (например, драйверов торгового оборудования), когда пользователи работают с 1С, подключаясь к серверу через терминал.
При этом пользователи видят, например, картинку представленную в анонсе статьи.
В то время как при работе с локальных компьютеров никаких проблем с подключением внешних компонент нет.
С чем это связано? Это связано с тем, что, когда пользователи работают через сервер терминалов, они имеют меньше прав, чем при работе на локальном компьютере.
В этом легко убедиться, если зайти на сервер терминалов под учетной записью с административными правами.
Причина такой разницы заключается в том, что 1С не может зарегистрировать внешнюю компоненту в реестре, когда пользователь работает в терминале под обычными правами, т.к. у обычного пользователя нет прав на запись в ветку системного реестра HKEY_CLASSES_ROOT.
В публикациях на тему подключения внешних компонент в терминале предлагаются самые разные методы решения этой проблемы.
1. Запустить первый раз 1С под административными правами.
Этот вариант далеко не всегда срабатывает. Ниже объясню, почему.
2. Дать обычным пользователям терминала права на запись в ветку системного реестра HKEY_CLASSES_ROOT.
Недостаточно «продвинутым» пользователям лучше этого не делать, иначе могут быть проблемы.
3. С помощью различных «примочек» регистрировать ВК от имени пользователя с полными правами.
Тоже не есть хорошо.
Так как же все таки лучше выйти из этой ситуации?
Я предлагаю свой вариант решения этой проблемы. По моему мнению — простой и красивый, не предлагавшийся на инфостарте ранее.
Дело оказалось в том, что в типовых конфигурациях 1С (например «Управление Торговлей») используется такой синтаксис метода глобального контекста ПодключитьВнешнююКомпоненту():
ОбъектДрайвера = Новый («AddIn.АТОЛСканер.Scaner45»);
Как видим, ВК драйвера подключается из макета «ДрайверАТОЛСканерШтрихкода» справочника «ПодключаемоеОборудование».
Что же при этом происходит?
1С сохраняет компоненту во временной папке пользователя, например «C:Documents and SettingsUserLocal SettingsTemp1032v8_4_12.tmp»
и пытается зарегистрировать ее в ветке реестра HKEY_CLASSES_ROOT именно по этому пути.
На терминале у обычных пользователей нет прав на изменение этой ветки реестра, поэтому компонента у них не подключается.
Теперь о том, как выйти из этой ситуации.
Метод глобального контекста ПодключитьВнешнююКомпоненту() имеет несколько вариантов синтаксиса. Вот этим мы и воспользуемся.
Итак, по шагам:
1. Регистрируем внешнюю компоненту утилитой regsvr32.exe на сервере терминалов в папке C:WINDOWSSYSTEM32 для 32-разрядной ОС или в папке C:WINDOWSSYSWOW64 для 64-разрядной ОС.
2. Используем один из двух дополнительных вариантов синтаксиса метода ПодключитьВнешнююКомпоненту():
Вариант 1:
ОбъектДрайвера = Новый («AddIn.АТОЛСканер.Scaner45»);
Вариант 2:
ОбъектДрайвера = Новый (ProgID);
На мой взгляд, вариант № 2 предпочтительнее.
При этом 1С не пытается перерегистрировать ВК по новому пути в реестре и таким образом, все проблемы решаются.
Ну вот собственно и все. Успехов в работе!
Related Posts
40 Comments
В то время как при работе с локальных компьютеров никаких проблем с подключением внешних компонент нет.
Глубоко ошибаешься. В путних сетках и тут проблемы, потому что в путних сетках и локальных административных прав у юзверя быть не должно. А то они там нарегят/наинсталлируют!
Там и софт по минимуму, все что нужно — в терминале. 🙂
Но, если так необходимо, то, думаю, на локальной машине данная методика также будет работать, т.о. «ложка не существует». 🙂
А вот и нет! 😉 На фига терминал всякой лабудой грузить? Там только двигун 1С и больше ничего
Очередной баян для новичков в работе с внешними ВК.
Со времен 77 здесь ничего не изменилось 🙂
Но за изложение плюсую.
Артур, а что могло измениться для ком-объектов? 😉
Винде по фиг от кого/для кого этот ком.
Со времен 77 здесь ничего не изменилось 🙂
Ничего не изменилось говорите?
Вы хоть в сути описанной в статье проблемы разобрались?
Разве в 77 внешние компоненты хранились в макетах справочников?
Разве 77 сохраняла их во временном каталоге пользователя и пыталась их потом там зарегистрировать?
Вот это по моему мнению как раз и есть «париться» — т.е. разобравшись в сути проблемы только наполовину, искать обходные пути для ее решения.
Вот это по моему мнению как раз и есть «париться» — т.е. разобравшись в сути проблемы только наполовину
Ага, наполовину… Суть проблемы элементарна — отсутствие прав.
Ссылка раз и навсегда решает проблему того же regsvr32 БлаБла у любого юзверя выполнением RunAs от имени пользователя с админскими правами.
Ну-ка расскажи в чем ты там ПОЛНОСТЬЮ разобрался?
Это красивое решение —
На терминале у обычных пользователей нет прав на изменение этой ветки реестра, поэтому компонента у них не подключается.
1. Регистрируем внешнюю компоненту утилитой regsvr32.exe на сервере терминалов в папке C:WINDOWSSYSTEM32 для 32-разрядной ОС или в папке C:WINDOWSSYSWOW64 для 64-разрядной ОС.
Ну в чем профит-то? В том что вы взяли её и зарегистрировали? Явно кто-то в чем-то полностью переразобрался.
Не понял смысл статьи.
Админ и так знает, как зарегистрировать dll-ку, у 1Сника при нормальном распределении обязанностей нет никаких прав на серваке.
Ага, наполовину… Суть проблемы элементарна — отсутствие прав
Вот именно — отсутствие прав это вторая половина проблемы.
А первая и основная половина состоит в том, почему 1С пытается перерегистрировать ВК, и как этого избежать.
Ну в чем профит-то? В том что вы взяли её и зарегистрировали? Явно кто-то в чем-то полностью переразобрался
Не спешите с выводами не разобравшись.
Дело в том, что вы ее хоть сто раз зарегистрируйте, но если вы оставите без изменений типовой код,
1С будет безуспешно пытаться ее перерегистрировать снова и снова.
Не понял смысл статьи.
Админ и так знает, как зарегистрировать dll-ку
Ну что тут сказать? Значит невнимательно читали статью, или никогда не сталкивались с такими проблемами.
Конечно, админ знает, как зарегистрировать dll-ку.
Он ее и регистрирует. Но потом оказывается что у рядовых пользователей она в терминале не подключается.
Вот в чем суть проблемы то!
(12) Не спешите с выводами, по поводу того, что я спешу с выводами не разобравшись. В типовой так сделано, потому, что ребята делали универсально, они не могут сидеть за вашим компьютером и регистрировать от имени администратора компоненту, не зная пароля тем более. А админы прекрасно об этом знают и ручками зарегят или скрипт напишут(run as). А ваша статья просто кэпство, но самое противное — преподносится как доселе неведомое чудо.
(6) А если еще подумать?
В 77 также были случаи неверной регистрации ВК — например, Админ в терминале заходит в одну базу и регистрирует ВК из каталога базы, а пользователь, у которого эта ВК юзается, но в другой базе, не может запустить эту ВК, если у него прав на папку с первой базой 🙁
Поэтому, например, для нормальной работы в 77 и придумано куча решений — тот же вариант с RunAs или загрузка обычных ВК через спец.ВК от Саши Орефкова и т.п.
Я же говорю — по работе с ВК ничего не изменилось!
А описанные проблемы — это проблемы прикладного кода, в частности, кода по работе с торговым оборудованием.
Разработчики этого кода либо не знали о сабжевой проблеме, либо пренебрегли ей 🙁
ЗЫ кстати, в 77 ВК также можно было хранить в макетах, правда, с использованием доп.ВК 🙂
ЗЗЫ а еще обрати внимание — плюс-то я тебе все-таки поставил 🙂
но самое противное — преподносится как доселе неведомое чудо
У вас видимо патологическое отвращение к чужим разработкам.:)
Конечно, это не чудо. Но тем не менее, я когда столкнулся с этой проблемой, нигде в инете не нашел объяснения причин этой проблемы. Везде освещалась только вторая часть проблемы (недостаток прав на реестр) и способы ее обхода. И нигде не говорилось об основной части проблемы — почему 1С пытается перерегистрировать ВК по новому пути.
ЗЗЫ а еще обрати внимание — плюс-то я тебе все-таки поставил 🙂
Согласен, не спорю. Спасибо.:)
А описанные проблемы — это проблемы прикладного кода, в частности, кода по работе с торговым оборудованием.
Разработчики этого кода либо не знали о сабжевой проблеме, либо пренебрегли ей 🙁
Совершенно верно. Но рядовому программеру от этого как бы не легче.
А эта статья конечно не претендует на какую-то особенность и гениальность.
Это просто статья человека который столкнулся с проблемой, и не нашел приемлемого для себя метода ее решения в инете.
Это попытка самостоятельно разобраться в проблеме и поделиться своим решением с другими — быть может сэкономив кому то время на решение аналогичных проблем.
Потому что не надо использовать (в т.ч. и фирме 1С) дебильную ПодключитьВнешнюю.. с разными там синтаксисами,
а надо использовать ЗагрузитьВнешнююКомпоненту(ПолныйПутьКДЛЛ), а либы лучше всего хранить в КаталогПрограммы(), либо (для файлухи и 7.7) в КаталогИБ()
надо использовать ЗагрузитьВнешнююКомпоненту(ПолныйПутьКДЛЛ)
Здесь есть одно большое НО…
Доступность:
Толстый клиент.
А мне нужно было подключать сканер штрих-кодов в ТОНКОМ клиенте.
А скажи на милость: на фига в ТЕРМИНАЛЕ еще и тонкий клиент?
Терминал сам по себе уже тонким клиентом является
(19) сканер штрих-кода успешно подключается в тонком клиенте, пример реализации можно посмотреть в УПП 1.3, в последних двух релизах
А скажи на милость: на фига в ТЕРМИНАЛЕ еще и тонкий клиент?
Терминал сам по себе уже тонким клиентом является
Ну, тут уж как бы наше руководство так решило для единообразия.
Как пел Высоцкий, «Жираф большой — ему видней».:)
Все работают с 1С в тонком клиенте управляемого приложения.
Чтобы можно было и через терминал подключаться и просто с локальной машины.
сканер штрих-кода успешно подключается в тонком клиенте, пример реализации можно посмотреть в УПП 1.3, в последних двух релизах
Пример реализации я брал из УТ11.
Он то конечно подключается, если у пользователя достаточно прав на запись в ветку реестра.
А вот если у пользователя недостаточно этих прав, тогда и начинаются проблемы которые описаны в этой статье.
(0)Кстати, если ты так уж «полностью разобрался», на фига ты совершаешь в коде лишние телодвижения?
После выполнения regsvr32 весь код укладывается в одну строку:
ОбъектДрайвера = Новый COMОбъект(«AddIn.Scaner45»);
Чтобы не быть голословным — рис.
После выполнения regsvr32 весь код укладывается в одну строку:
ОбъектДрайвера = Новый COMОбъект(«AddIn.Scaner45»);
Ну, раз говоришь что работает, верю.
Хотя мне это кажется странным. По идее не должно было.:)
Именно, что должно. :)))
Это как раз стандартное обращение к зарегенным в реестре интерфейсам COM, Active-X
В 7.7 это было бы так: Lib=СоздатьОбъект(«Miracle.VCL»)
В Дельфи: Lib:=CreateOleObject(‘Miracle.VCL’)
И в любой другой виндовой хрени аналогично 😉
(25) а что такое progid и clsid?;-)
В 7.7 это было бы так: Lib=СоздатьОбъект(«Miracle.VCL»)
Да, но в 7.7 перед этим вызывался метод ЗагрузитьВнешнююКомпоненту(«FormEx.dll»);
Без этого СоздатьОбъект() не работало.
Ладно, начнем ликбез по порядку :))))
1. ЗагрузитьВнешнююКомпоненту от 1С — как раз и производит регистрацию в реестре интерфейса соотвествующей либы, написанной по технологии создания внешних компонент от 1С (ТСВК). Вот именно в этом случае, и возникает трабла с правами на запись в реестр, неважно в каком месте: на терминале или локальном компе
2. СоздатьОбъект — уже и создавала (в аналогии 8.2) Новый COMОбъект по указанному progid
В 8.2, как в обычной виндовой программе, все точно так же.
Если ЛЮБАЯ ВК написана по технологии COM и предварительно зарегена через regsvr32 (т.е. уже есть progid), никаких
Подключить/ЗагрузитьВнешнююКомпоненту уже не надо ни в 7.7, ни в 8.2.
В моем примере выше либа для 7.7 писалась не по ТСВК, она обязательно требовала regsvr32, но при этом совершенно не понимала никаких Подключить/ЗагрузитьВнешнююКомпоненту
+(29) А FormEx.dll — вообще супер-специфичная либа, там Лёха залез в самое нутро 1С, последние её версии вообще в реестре следов не оставляют, и ЗагрузитьВнешнююКомпоненту(«FormEx.dll») пройдет всегда, у любого юзверя, с любыми правами
УТ 10.3. Платформа 8.2.13.202. У меня при настройке перенаправленого в терминальный сервер торгового оборудования выпадает 1С при тестировании драйвера. Однако если на это не заморачиваться, то Интерфейс Кассира работает и чеки пробиваются. Может кому-то пригодится, т.к. мы очень долго не понимали в чем дело и не пробовали пробить чек из Интерфейса Кассира ))))
Использую вот это
А в совокупности вот с этим
вообще больше проблем при работе в ВК практически не ощущаю. Больше ничего и не нужно. Главное не злоупотреблять использованием ВК 🙂
Использую вот это
В описанном мной случае проблемы возникали когда ВК хранится в макете справочника.
При подключении она сохраняется во временный файл временного каталога пользователя.
Поэтому для использования RegsvrEx нужно знать полный путь к этому временному файлу.
Ну а вообще использование нескольких дополнительных разработок вместо стандартного
типового механизма и маленькой правки кода не кажется мне оптимальным.:)
(33) Смею заметить, ничего против Вашей публикации не имею :). «стандартный типовой механизм» не всегда вставляет, иногда своя реализация кажется более универсальной :).
Спасибо за просвещение, а то у БиТ купили продукт, а они используют свой сервер лицензий, и для этого пытаются регистрировать внешние компоненты, до сих пор приходилось делать запуск под Админом, теперь попробуем переписать чтобы было по человечески.
«После выполнения regsvr32 весь код укладывается в одну строку:
ОбъектДрайвера = Новый COMОбъект(«AddIn.Scaner45″); »
А страница свойств компоненты появится при таком подходе ?
Артур, а что могло измениться для ком-объектов? 😉
Винде по фиг от кого/для кого этот ком.
Спасибо за статью. Столкнулся с аналогичным случаем при работе с эмулятором фискального регистратора. Конечно же лучше запускать 1С через тонкий клиент с машины к которой подключено оборудование, но некоторые клиенты настаивают на использовании терминала ( тем более если фискальный регистратор виртуальный — используется эмулятор). Почему-то после обновления УТ11 до 11.1 вдруг 1С стала просить драйвера на эмулятор фискального регистратора, хотя сканнер штрих-кодов продолжает прекрасно работать.
Добавил бы уточнения к алгоритму решения этой проблемы: ( которые кстати подчерпнул из вашего же комментария только в другом форуме )
В общих макетах лежат драйвера различного оборудования. Там собственно и хранилась нужная мне dll.
Щелкаем на этом макете и нажимаем кнопочку «Выгрузить в файл».
Файлу даем любое имя и расширение zip.
Открыв архив видим несколько файлов, в том числе нужный мне FPEmulator1C.dll. Распаковываем и копируем его в зависимости от разрядности windows в папку для 32х — C:WindowsSysytem32 , для 64х — C:WindowsSysWOW64.
Запускаем Пуск/Все программы / Стандартные / Командная строка — только правой кнопкой мыши вибираем «Запуск от имени администратора» . В командной строке переходим в нужную папку (C:WindowsSysytem32 или C:WindowsSysWOW64 ).
В командной строке — cd C:WindowsSysytem32
Пробуем регистрировать его с помощью команды regsvr32.exe .
В командной строке — regsvr32 FPEmulator1C.dll
Если все успешно тогда переписываем код в конфигурации в соответствии со статьей.
Читайте также: