Как проверить возможность создания COM-объекта Word в 1С:Предприятие

← На главную

В процессе разработки конфигураций на платформе 1С:Предприятие часто возникает необходимость взаимодействия с офисными приложениями, в частности с Microsoft Word. Однако перед тем как вызывать методы формирования печатных форм или заполнения шаблонов, критически важно убедиться, что соответствующий COM-объект доступен в системе. В этой статье мы подробно разберем, как реализовать такую проверку, какие существуют подводные камни и как оптимизировать производительность вашего кода.

Стандартный метод через блок «Попытка — Исключение»

Разберем самый простой и распространенный способ. Он заключается в непосредственной попытке инициализации приложения. Если в системе не установлен Word или возникли проблемы с регистрацией библиотек, платформа сгенерирует исключение, которое мы сможем перехватить.

Рассмотрим пример кода:


Функция ПроверитьНаличиеWord() Экспорт
    Попытка
        WordApp = Новый COMОбъект("Word.Application");
        // Если объект создан, его нужно обязательно закрыть
        WordApp.Quit();
        Возврат Истина;
    Исключение
        Возврат Ложь;
    КонецПопытки;
КонецФункции

Проанализируем этот подход. Его преимущество в стопроцентной достоверности: если объект создался, значит, система готова к работе. Однако у этого метода есть существенный минус — время выполнения. Создание полноценного процесса winword.exe может занимать от 1 до 5 секунд в зависимости от мощности компьютера, что недопустимо при частых проверках.

Оптимизация производительности: использование повторного использования значений

Для того чтобы не нагружать систему постоянным запуском Word, мы можем использовать механизмы платформы для кэширования результата. Выясним, как это сделать правильно. Вынесем процедуру проверки в Общий модуль, у которого в свойствах установлено «Повторное использование возвращаемых значений: На время сеанса».

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

Быстрая проверка через реестр Windows

Если нам нужно проверить наличие Word максимально быстро, не запуская сам процесс, мы можем обратиться к реестру операционной системы. Для этого воспользуемся более «легким» объектом WScript.Shell, который практически всегда доступен в Windows.

Разберем алгоритм проверки ключа ProgID. Каждое зарегистрированное COM-приложение оставляет след в ветке HKEY_CLASSES_ROOT. Посмотрим на реализацию:


Функция WordУстановленБыстраяПроверка() Экспорт
    Попытка
        Shell = Новый COMОбъект("WScript.Shell");
        // Пытаемся прочитать версию Word по умолчанию
        RegValue = Shell.RegRead("HKEY_CLASSES_ROOT\Word.Application\CurVer\");
        Возврат Истина;
    Исключение
        // Если ключ не найден, значит Word не зарегистрирован
        Возврат Ложь;
    КонецПопытки;
КонецФункции

Этот метод работает мгновенно. Мы лишь проверяем запись в реестре, не инициализируя тяжеловесные библиотеки Microsoft Office. Однако стоит помнить, что наличие записи в реестре не гарантирует работоспособность самого Word (например, если файлы программы были удалены вручную без деинсталляции).

Проблема «зависших» процессов и правильное завершение

Важный технический нюанс, который часто упускают разработчики: при использовании метода Новый COMОбъект("Word.Application") операционная система создает новый процесс в диспетчере задач. Если мы просто присвоим переменной значение Неопределено, процесс winword.exe останется висеть в памяти.

Проанализируем правильную последовательность действий для очистки памяти:

Создаем объект.
Выполняем проверку.
Обязательно вызываем метод Quit().
Очищаем переменную 1С.

Без вызова Quit() при многократной проверке (например, в цикле или при частом открытии форм) сервер или рабочая станция могут быстро исчерпать ресурсы оперативной памяти из-за десятков невидимых копий Word.

Особенности работы на стороне сервера (64-бит и сессия 0)

Рассмотрим ситуацию, когда проверка выполняется в серверном коде (например, в регламентном задании). Здесь мы сталкиваемся с двумя проблемами:

1. Разрядность систем: Если сервер 1С 64-битный, а Microsoft Office установлен 32-битный, стандартный вызов может вернуть ошибку. В таком случае необходимо настраивать DCOM через утилиту dcomcnfg, чтобы разрешить взаимодействие между процессами разной разрядности.

2. Изоляция сессии: На серверных ОС Windows для работы COM-объектов Office требуются специфические папки профиля, иначе инициализация завершится сбоем. Проанализируем решение: необходимо вручную создать папку Desktop в системных профилях:

C:\Windows\System32\config\systemprofile\Desktop
C:\Windows\SysWOW64\config\systemprofile\Desktop

Только после создания этих директорий метод Новый COMОбъект на стороне сервера начнет отрабатывать корректно.

Выяснение версии Word для расширенной логики

Иногда нам недостаточно знать, что Word просто «есть». Например, старые версии (до 2007 года) не умеют штатно сохранять файлы в формате PDF или работать с современными .docx без специальных патчей. Посмотрим, как получить версию объекта после его создания:


Если WordApp <> Неопределено Тогда
    ВерсияЧислом = Число(WordApp.Version);
    Если ВерсияЧислом < 12 Тогда 
        // Версия ниже Word 2007
        Сообщить("Требуется обновление Microsoft Office для поддержки PDF");
    КонецЕсли;
КонецЕсли;

Современные альтернативы (без использования COM)

В завершение разберем вопрос: всегда ли нужна проверка COM? Современные стандарты разработки в 1С рекомендуют минимизировать использование COM-соединений, так как они платформозависимы и нестабильны. Если ваша задача — просто создать документ, рассмотрите возможность генерации файлов в формате .docx напрямую.

Формат .docx представляет собой ZIP-архив с XML-структурой внутри. Платформа 1С позволяет работать с архивами и XML без установленного Word. Это полностью снимает проблему проверки наличия офисного пакета на сервере и значительно повышает скорость формирования документов.

Подведем итог: для быстрой интерактивной проверки используйте чтение реестра через WScript.Shell, а для гарантированной проверки перед формированием отчета — блок Попытка с обязательным вызовом Quit() и кэшированием результата в общем модуле.