Разработка интерфейсов для мобильных устройств в среде 1С:Предприятие накладывает ряд ограничений, с которыми разработчики редко сталкиваются в настольных версиях. Одной из таких проблем является программное управление отображением табличного документа. В настольной платформе (Windows/Linux) достаточно установить свойство ТекущаяОбласть, и приложение автоматически прокрутит экран к нужным ячейкам. Однако в мобильном приложении или мобильном клиенте этот механизм работает иначе: фокус (выделение) перемещается, но визуальная прокрутка (скролл) не происходит.
В этой статье мы подробно проанализируем причины такого поведения мобильной платформы, рассмотрим стандартные способы адресации и разберем альтернативные методы, которые позволяют добиться желаемого результата при работе с большими отчетами или таблицами.
Рассмотрим стандартную ситуацию. У нас есть форма, на которой размещен элемент типа ПолеТабличногоДокумента. Мы хотим, чтобы при нажатии на определенную кнопку экран автоматически перемещался, например, к 50-й строке документа. В классическом варианте программист пишет следующий код:
&НаКлиенте
Процедура ПерейтиКОбласти(Команда)
// Устанавливаем область через строковый адрес
Элементы.ПолеТаблДок.ТекущаяОбласть = Объект.ТабличныйДокумент.Область("R50C2");
КонецПроцедуры
На мобильном устройстве после выполнения этой команды мы увидим, что если вручную прокрутить документ до 50-й строки, ячейка действительно будет выделена (обычно тонкой зеленой рамкой). Однако автоматического смещения экрана не произойдет. Пользователь останется на той же позиции, где и был. Проанализируем, почему это происходит: мобильная платформа старается минимизировать нагрузку на графическую подсистему и разделяет логическое выделение элемента и физическую отрисовку позиции скролла.
Прежде чем искать обходные пути для прокрутки, важно обратить внимание на способ задания области. В сообщениях форума справедливо отмечается, что использование формата "R50C2" (RC-формат) менее эффективно, чем прямое указание числовых координат. Рассмотрим, как правильно задавать область для мобильной платформы:
// Вместо этого:
// Область = ТабДок.Область("R50C2");
// Используйте этот метод:
Область = ТабДок.Область(50, 2, 50, 2);
Использование числовых параметров (НомерПервойСтроки, НомерПервойКолонки, НомерПоследнейСтроки, НомерПоследнейКолонки) позволяет избежать лишнего парсинга строки платформой. Это не решает проблему прокрутки напрямую, но делает код более надежным и быстрым, что критично для мобильных устройств с ограниченными ресурсами. Кроме того, хранить ссылки на области в виде чисел в структурах или массивах гораздо удобнее для алгоритмической обработки.
В мобильной платформе многие свойства элементов формы, отвечающие за внешний вид, игнорируются. Например, попытка скрыть полосы прокрутки через ИспользованиеПолосыПрокрутки.НеИспользовать часто не дает результата. Платформа принудительно оставляет элементы навигации, чтобы пользователь не потерял возможность просмотра данных, если программная логика даст сбой.
Выясним причину: мобильный клиент работает через слой абстракции, который транслирует команды 1С в нативные компоненты Android или iOS. Событие установки ТекущаяОбласть передает идентификатор ячейки, но не инициирует команду scrollTo для контейнера. Это поведение на текущий момент считается особенностью (или ограничением) мобильного движка.
Одним из недокументированных «лайфхаков» для принудительной прокрутки является использование встроенного поиска. Проанализируем ситуацию: когда платформа выполняет поиск текста, она обязана показать пользователю результат. Если вызвать метод НайтиТекст(), мобильный клиент во многих случаях выполняет визуальный переход к найденному значению.
&НаКлиенте
Процедура СдвинутьЭкранКЯчейке(ТекстДляПоиска)
// Метод НайтиТекст может спровоцировать прокрутку
Элементы.ПолеТаблДок.НайтиТекст(ТекстДляПоиска, ПоискНаправленийТабличногоДокумента.Вперед, Истина);
КонецПроцедуры
Важный нюанс: этот способ работает нестабильно и сильно зависит от версии мобильной платформы. Кроме того, в целевой ячейке должен содержаться уникальный текст, по которому можно осуществить навигацию.
Если бизнес-задача требует гарантированного и точного перехода к конкретному разделу (например, навигация по оглавлению сложного отчета), лучшим решением будет отказ от стандартного ТабличногоДокумента в пользу ПоляHTMLДокумента. Рассмотрим этот подход по шагам:
<a name="якорь"> или идентификаторы id для нужных строк.scrollIntoView().Разберем пример реализации через JavaScript, так как это наиболее гибкий способ для мобильного приложения:
// В HTML-коде ячейка выглядит так:
// <td id="row_50">Данные</td>
// Программный код для перехода (через вызов JS):
ТекстСкрипта = "document.getElementById('row_50').scrollIntoView();";
Элементы.ПолеHTML.ИсполнитьScript(ТекстСкрипта);
Мобильная платформа 1С гораздо лучше обрабатывает инструкции внутри WebView (компонент, отображающий HTML), чем в нативном табличном документе. Это позволяет реализовать плавную и точную навигацию.
Иногда прокрутка не работает из-за конфликтов в иерархии элементов формы. Посмотрим на структуру формы: если ПолеТабличногоДокумента помещено в группу с автоматической высотой, которая сама находится внутри прокручиваемой группы, возникают проблемы с расчетом координат.
Рекомендации по настройке элементов:
РастягиватьПоВертикали = Истина.На текущий момент прямого и надежного способа заставить стандартный табличный документ в мобильном приложении 1С прокручиваться к области через ТекущаяОбласть не существует. Это известное ограничение платформы. Для решения задачи рекомендуется:
НайтиТекст() для простых случаев.Проанализировав поведение мобильной платформы, мы приходим к выводу, что разработчику необходимо заранее проектировать интерфейс под мобильные устройства, избегая слишком больших таблиц, требующих сложной программной навигации, либо выбирая инструменты с более гибким управлением отображением.