Конфигурация ПО

8.0-8.3.18, обычная и управляемая формы

Проблема

Платформа 1С при копировании в буфер обмена текста ячейки таблицы или табличного документа отсекаются правые (конечные) пробелы

Воспроизведение

Открыть приложенную внешнюю обработку в управляемом клиентском приложении любой базы. Одинарным кликом (без входа в режим редактирования) активировать единственную ячейку таблицы. Нажать сочетание клавиш CTRL+C. Вставить текст в блокнот. Вставится строка "ф". Двойным кликом войти в режим редактирования ячейки и убедиться, что в ней содержится текст "ф  ". Таким образом в буфер обмена текст копируется с отсечением правых (конечных) пробелов.

Аналогичная ситуация и в обычной форме, которую также можно проверить этой же внешней обработкой.

Ради чего это сделано - понятно. Колонки таблиц БД с типом "Строка фиксированной длины" возвращают строковые значения, дополненные до нужной длины пробелами.Тут действительно вреда от удаления пробелов практически нет, а польза есть. Но такие колонки используются практически только для свойства "Код".

А применяется это поведение и к колонкам переменной длины. Мы получаем вред в том, что нет простой возможности скопировать точно то значение, которое находится в ячейке. Хорошо, если есть возможность войти в режим редактирования строки таблицы и тогда можно скопировать оригинальное значение. Но она есть не всегда. В остальных случаях приходится командой "Вывести строки" выводить ячейки в табличный документ и уже там входить в режим редактирования ячейки и оттуда копировать. Последний способ достаточно не очевиден и многие просто не додумаются до этого.

При анализе проблемных ситуаций я много раз терял время по этой причине. Я копировал из ячейки текст и не видел в нем конечных пробелов, а они там были.

Попробовал найти другие приложения, которые ведут себя подобным образом и не смог. Например проверил EXCEL и Microsoft SQL Server Management Studio, где также есть тип "Строка фиксированной ширины".

Предлагаю применять такое отсечение при копировании в буфер обмена только для колонок с фиксированной длиной строки. Если информации о типе длины строки нет, то не применять.
Реализовал такое поведение в разрабатываемой версии ИР https://www.hostedredmine.com/issues/910752

Возможно у кого еще будут идеи как уменьшить негативный эффект от этого поведения?

Иллюстрации
https://i.imgur.com/xh0QoYJ.png
https://i.imgur.com/l49BjMy.png

Скачать внешнюю обработку с примером можно в полном описании проблемы https://www.hostedredmine.com/issues/910780

(0) Пишешь, что отсекаются пробелы, потом картинки, что не отсекаются. Непонятное описание.

(0) шифт инсерт дает такое же поведение?

(4) Да

Неужели больше нет идей?

есть идея. перед копированием как-то заменять пробелы на неразрывные пробелы. если надо - то после вставки обратно.

копирование из Ексель еще хуже, там перевод строки зачем-то копируется

(8) Ты слишком подробно описал проблему. Думаю большинство не поймут о чем ты. Я не понял.

(8) из экселя куча мусора копируется. у меня у одного клиента постоянно вылазит непечатаемый символ с кодом 28

А в буфере обмена же есть несколько форматов хранения.
Если хочется подробно,то EnumClipboardFormat и смотрим,что там есть и как оно копируется.

(0) у меня не воспроизводится. Строка копируется с пробелами. Пробовал вставлять в ворд, эксель, блокнот, таб. документ 1с, табличное поле и по всякому между ними, и в конфигураторе и в 1с предприятии. ЧЯДНТ? Может ты какую-нибудь хрень установил на комп, которая в буфере обмена шарится?

"Одинарным кликом (без входа в режим редактирования) активировать единственную ячейку таблицы"

Невнимательно прочитал. А зачем ты так делаешь? В экселе поведение при копипасте выделенной ячейки и выделенного в ней текста тоже отличается

(13) Зачем я так делаю? Опять же странный вопрос, учитывая то, что в (0) есть ответ =) Ну и кажется даже без (0) ответ довольно очевиден - это единственный простой способ скопировать значение недоступной для редактирования ячейки.

сорри не по теме, в ИР версии дата года съехала (2000)

(14) неправильный способ. Жмем cntr+F. Открывается окно с нужным значением и оттуда копируем с пробелами.

(0) >При анализе проблемных ситуаций я много раз терял время по этой причине.

Если сравнить время, потерянное в таких ситуациях разработчиками, со временем, которое теряли бы простые пользователи (которые пробел вообще за символ не считают), если бы концевые пробелы везде мешались, думаю выбор разработчиков платформы становится очевидным и железно обоснованным. :)

Концевые пробелы — зло, которое проще не замечать, чем бороться с ним. :)

(17) Почему тогда при входе в режим редактирования ячейки/поля концевые пробелы отображаются? Ну удаляли бы тогда их везде автоматически. Сейчас же нет целостности в подходе. Если копирование ячейки в режиме просмотра выполняется для дальнейшего поиска, то удаление пробелов почти всегда будет полезно. А вот если пользователь копирует с целью сравнения значений или другой чувствительной к длине строки цели, то это для него будет вредно. Железным обоснованием на мой взгляд это сложно назвать. Ну и хотелось бы еще примеров приложений, где сделано подобное поведение. Я так и не смог найти.

Зато при создании базы данных и копирования путя из буфера обмена эта падлина не убирает пробелы, а ведь он чаще всего попадает в буфер с пробелами (например, из тотал коммандера). при массовой обработке, баз так на 50, это сильно напрягает. короче, все в 1С работает наоборот. в семерке буфер обмена и поиск по спискам были намного удобнее.

ни разу за 15 лет работы с 1С не видел необходимости пробелов в конце и начале в адресах баз

на последнем обновлении перестало работать
ВнешниеОбработки.Создать("C:\Program Files\1cv8\ИР\ирПортативный.epf", Ложь).От(Запрос)
а на Портативный 5.71.3p
работает

(21) http://devtool1c.ucoz.ru/forum/2-2-1