Где выполняется общий модуль с флагами клиента и сервера при вызове из обычного приложения: на клиенте или на сервере?

При разработке кроссплатформенных решений на платформе 1С:Предприятие часто возникает задача определения операционной системы текущего рабочего места. Рассмотрим типичную ситуацию: клиентское приложение запущено на операционной системе Linux, а сервер 1С работает под управлением Windows. Из интерфейса обычных форм вызывается экспортная функция общего модуля, у которого в свойствах включены флаги Сервер, Клиент (обычное приложение), Внешнее соединение и Вызов сервера.

Разберем подробно, в каком контексте выполнится такой код, что вернет свойство ИнформацияОСистеме.ТипПлатформы и как правильно организовать логику работы с файлами в гетерогенной среде.

В каком контексте выполняется вызов в обычном приложении?

Проанализируем правила компиляции и вызова процедур и функций общих модулей платформой 1С:Предприятие:

1. Локальная компиляция модуля: Если в свойствах общего модуля установлены флаги для нескольких контекстов (например, Сервер и Клиент (обычное приложение)), платформа компилирует отдельные независимые экземпляры этого модуля для каждого доступного окружения.
2. Приоритет клиентского контекста: При запуске толстого клиента в режиме обычного приложения среда выполнения сначала ищет вызываемый метод в локальном клиентском контексте. Поскольку установлен флаг Клиент (обычное приложение), функция исполняется локально на рабочей станции пользователя.
3. Игнорирование флага «Вызов сервера»: Присутствие галочки Вызов сервера разрешает вызовы из тонкого клиента или управляемых форм к серверному экземпляру модуля, однако при вызове из обычного приложения при наличии клиентского флага сетевой вызов к серверу не инициируется.

Таким образом, при вызове функции из обычного приложения под управлением Linux код выполнится на клиентской машине. Объект СистемнаяИнформация вернет параметры клиентской операционной системы (Linux), а не сервера (Windows).

Особенности работы со свойством ТипПлатформы

Посмотрим на пример кода получения системной информации и разберем важные нюансы типизации:

ИнформацияОСистеме = Новый СистемнаяИнформация;
Если Найти(ИнформацияОСистеме.ТипПлатформы, "Linux") Тогда
    Фильтр = "Все файлы (*.*)|*.*|"
        + "Документ Microsoft Word (*.doc)|*.[Dd][Oo][Cc]|";
КонецЕсли;

Выясним причину возможных скрытых ошибок в данном фрагменте:

1. Тип значения: Свойство ТипПлатформы возвращает не строку, а значение системного перечисления ТипПлатформы (например, ТипПлатформы.Linux_x86, ТипПлатформы.Linux_x86_64, ТипПлатформы.Windows_x86, ТипПлатформы.Windows_x86_64).
2. Неявное приведение типов: Использование функции Найти() с объектом перечисления опирается на неявное преобразование к строке. Для надежного кода рекомендуется использовать прямое сравнение с элементами системного перечисления либо явное преобразование с помощью функции Строка().

Рассмотрим пример корректного сравнения системного типа платформы:

ИнформацияОСистеме = Новый СистемнаяИнформация;

Если ИнформацияОСистеме.ТипПлатформы = ТипПлатформы.Linux_x86 
   Или ИнформацияОСистеме.ТипПлатформы = ТипПлатформы.Linux_x86_64 Тогда
    
    // Формирование фильтра с учетом чувствительности к регистру в Linux
    Фильтр = "Документ Microsoft Word (*.doc)|*.[Dd][Oo][Cc]|Все файлы (*.*)|*.*";
Иначе
    Фильтр = "Документ Microsoft Word (*.doc)|*.doc|Все файлы (*.*)|*.*";
КонецЕсли;

Почему в Linux требуется маска вида *.[Dd][Oo][Cc]?

В операционных системах семейства Linux файловые системы по умолчанию чувствительны к регистру символов (case-sensitive). Если в диалоге выбора файлов указать стандартный фильтр *.doc, файлы с расширениями .DOC или .Doc будут скрыты в проводнике.

Использование шаблона вида *.[Dd][Oo][Cc] или явное перечисление вариантов через точку с запятой (*.doc;*.DOC) обеспечивает корректное отображение файлов с любым регистром расширения при интерактивной работе пользователя через объект ДиалогВыбораФайла.

Рекомендации по организации архитектуры модулей

Для предотвращения путаницы с контекстом выполнения рекомендуется придерживаться следующих правил:

1. Разделение модулей по назначению: Логику работы с диалогами, файловой системой на машине пользователя и интерфейсом следует размещать в специализированных клиентских общих модулях (например, только с флагами клиента).
2. Использование инструкций препроцессора: Если общий модуль скомпилирован в нескольких средах, необходимо разграничивать платформозависимый код директивами #Если Клиент Тогда, #Если Сервер Тогда или #Если ТолстыйКлиентОбычноеПриложение Тогда.
3. Применение библиотечных механизмов: При разработке на базе типовых решений (БСП) для кроссплатформенного взаимодействия с файлами рекомендуется использовать методы подсистемы работы с файлами клиентского контекста, где обработка регистрозависимости и специфика операционных систем уже реализованы платформенно.