Почему MSScriptControl падает при вызове Run в 1С 7.7 и как это исправить?

← На главную

При разработке на платформе 1С:Предприятие 7.7 программисты часто сталкиваются с необходимостью обработки данных в формате JSON. Поскольку встроенных средств для этого в «семерке» нет, стандартным решением является использование COM-объекта MSScriptControl.ScriptControl, который позволяет исполнять код на языке JScript или VBScript. Однако на практике возникает странная ситуация: один и тот же код прекрасно работает во внешней обработке (.ert), но вызывает фатальную ошибку или «тихий» вылет при переносе его в модуль формы списка или справочника.

В этой статье мы подробно разберем, почему возникает эта проблема, проанализируем механизмы работы ScriptControl и выработаем надежное решение для парсинга JSON.

Разбор ситуации: Контекст исполнения и область видимости

Проанализируем поведение системы. Когда мы запускаем код во внешней обработке, 1С создает для неё отдельный контекст. Если же код выполняется из формы списка, в игру вступают особенности потоков интерфейса и жизненного цикла объектов. Одной из главных причин падения метода Run является некорректная инициализация или преждевременное уничтожение объекта управления скриптами.

Рассмотрим стандартный пример инициализации, который часто приводит к ошибке в формах:


Процедура ВыполнитьПарсинг()
    scriptCtrl = СоздатьОбъект("MSScriptControl.ScriptControl");
    scriptCtrl.Language = "jscript";
    // Добавление кода парсера...
    Рез = scriptCtrl.Run("parseJSON", Стр);
КонецПроцедуры

Если этот код вызывается из формы списка, объект scriptCtrl может вести себя нестабильно. Рекомендуется выносить объявление переменной на уровень модуля формы. Это гарантирует, что объект будет «жив» на протяжении всего времени работы формы и не будет переинициализироваться некорректно при каждом нажатии кнопки.

Проверка входных данных: Валидация JSON

Часто метод Run падает без описания ошибки просто потому, что передаваемая строка не является валидным JSON. Выясним причину: JScript внутри MSScriptControl крайне чувствителен к синтаксису. Если в строке отсутствуют ожидаемые элементы, выполнение прерывается. Перед тем как передавать данные в парсер, необходимо выполнить хотя бы минимальную проверку.

Посмотрим на пример простой функции проверки формата:


// Простая проверка на соответствие формату JSON
Если (Лев(Стр, 1) = "{") И (Прав(СокрЛП(Стр), 1) = "}") Тогда
    // Это потенциально корректный JSON, можно пробовать парсить
Иначе
    Сообщить("Получен ответ, не являющийся строкой в формате JSON: " + СокрЛП(Стр), "!");
    Возврат;
КонецЕсли;

Такая проверка отсекает пустые ответы сервера или сообщения об ошибках в формате HTML, которые часто приходят вместо ожидаемого JSON и «вешают» скриптовый движок.

Проблема длинных строк и кодировок

Выясним еще одну скрытую причину падения метода Run. Компонент msscript.ocx — это довольно старое 32-битное решение. При передаче очень длинных строк (более нескольких десятков килобайт) в качестве параметров функции Run("ИмяФункции", Параметр) часто происходит переполнение стека или внутренняя ошибка памяти.

Чтобы избежать этого, проанализируем альтернативный способ передачи данных в JScript — через прямое исполнение инструкций. Вместо передачи строки как аргумента, мы можем записать её в переменную внутри скриптового движка:


// Вместо scriptCtrl.Run("parseJSON", ОченьДлиннаяСтрока)
scriptCtrl.ExecuteStatement("var rawData = '" + Стр + "';");
Рез = scriptCtrl.Eval("JSON.parse(rawData)");

Важный нюанс: 1С 7.7 работает в кодировке ANSI (Windows-1251), а данные JSON обычно приходят в UTF-8. Если в строке есть кириллица, прямой парсинг может вернуть «кракозябры» или вызвать ошибку. Убедитесь, что перед парсингом строка корректно преобразована в Unicode (например, с помощью объекта ADODB.Stream).

Использование альтернативы: COM-объект htmlfile

Если MSScriptControl продолжает вести себя нестабильно (что не редкость в современных ОС Windows 10/11), рассмотрим более надежный метод, который используют опытные разработчики. Это использование объекта htmlfile, который предоставляет доступ к движку Internet Explorer (MSHTML).

Разберем преимущества этого метода: он более устойчив к утечкам памяти и позволяет использовать современный синтаксис JSON.parse без загрузки сторонних библиотек JScript. Пример реализации выглядит так:


// Создаем объект HTML-документа
html = СоздатьОбъект("htmlfile");
html.write("<meta http-equiv='x-ua-compatible' content='IE=9'>"); // Включаем поддержку современного JS
// Теперь можно использовать стандартный JSON.parse
JSONОбъект = html.parentWindow.JSON.parse(СтрJSON);

Этот подход часто решает проблемы с «падением» Run, так как используется более современная и изолированная среда исполнения.

Итоговые рекомендации для стабильной работы

Подводя итог нашему анализу, сформулируем основные правила работы с внешними скриптами в 1С 7.7:

Область видимости: Всегда объявляйте переменную COM-объекта в разделе Перем в начале модуля, а не внутри процедуры.
Экранирование: Обязательно обрабатывайте спецсимволы в строке JSON (особенно символы переноса строк \n и \r), иначе JScript воспримет их как ошибку синтаксиса.
Контроль типов: Всегда проверяйте, что Стр не является пустой и начинается с соответствующих символов { или [.
Модальность: Избегайте вызова тяжелых скриптов в момент обновления интерфейса формы списка. Если возможно, выносите парсинг в отдельную процедуру, вызываемую через ОбработкаОжидания.

Соблюдение этих правил позволит вам избежать непредсказуемого поведения MSScriptControl и обеспечит стабильную интеграцию вашей конфигурации 1С 7.7 с современными веб-сервисами.