В управляемой форме 8.3, НЕ "Такси" есть реквизит типа "Строка". Требуется автоматически сохранять то, что пользователь туда вводит, чтобы потом он мог выбрать это из списка. (см. рис.)

Как это лучше сделать? Через справочник, регистр сведений, хранилище? Или для этого уже есть какой-то штатный механизм?
---
регистр сведений напрашивается сам собой
---
штатный механизм поиска сохраняет историю введенных значений только не в строковые поля, а в ссылочные.. чтобы сильно механизм не менять логично предположить, что лучше уж создать справочник ВведенныеСтроки и в наименовании хранить введенное. Поиск очевидно по наименованию. Не сталкивался еще за свою практику с такой задачей. Действительно пользователям такое нужно?
---
Действительно пользователям такое нужно?

Да, нужно, к сожалению.

лучше уж создать справочник ВведенныеСтроки и в наименовании хранить введенное

А в виде кода сделать сделать дату в формате ГГГГММДДЧЧММСС для сохранения порядка ввода. Только геморройно получится. Поле служит для ввода каталога. Люди хотят, чтобы было так:
1) задал путь руками
2) или вызвал стандартный диалог и выбрал существующий путь оттуда (с этим проблем нет ;) )
3) или вызвал стандартный диалог, выбрал существующий путь оттуда и допечатал руками ещё 2-3 уровня.

И всё это без дополнительных форм, ввода элементов в справочник на ходу и т.п.
---
я такое делал в ТТН для указания водителей. Там строка. Но данные берет из КЛК.
А судя по скрину автора надо в кеш писать и потом его чистить.
---
Что за КЛК?
---
сокращение - контактные лица контрагентов (или партнеров)
---
регистр сведений напрашивается сам собой
---
А чем это лучше справочника?
---
там не нужна ссылочная привязка. А для этого РС более подходит.
---
Так по-любому надо будет отслеживать ПриИзменении(), заносить строку в справочник или регистр, открывать форму справочника или регистра или наполнять выпадающий список - разницы особой-то и нет.

Единственно, если регистр сведений периодический, то можно чуть меньше напрягаться, чтобы отсортировать строки в порядке ввода. Зато в справочнике можно отсортировать по наименованию для удобства поиска строки плюс можно сделать фальшивое поле типа СправочникСсылка, для которого 1С будет открывать форму автоматом, правда, тогда пользователя не устроит логика работы со строкой. Так что 1:1.
---
РС более универсальный.
Можно не напрягаясь использовать механизм для разных полей ввода.
Не нужно создавать новый справочник каждый раз.
Правки вносить проще.
Выводить не все строки, а ограничивать количество строк показа.
Сортировать в РС по наименованию ничем не сложнее.
Много плюсов к РС.
---
Выводить не все строки, а ограничивать количество строк показа.

А можно, пожалуйста, по-подробнее?
---
Выбрать первые 5
---
А, так через запрос и у справочника можно.
---
можно, но в совокупности с историей ввода будет сложнее.
---
Вы верно мыслите и скоро придёте к мысли "зачем хранить отдельно то, что уже хранится в базе". Получится, что никаких доп.объектов создавать и не надо... см.(17)
---
непонятно только, с чего решили, что это вообще хранится в базе?
---
При чтении документа однократно заполнять список выбора в нужном поле. Всё. Никаких "ПриИзменении".
---
Ещё можно запросом анализировать уникальные значения этого поля в последних там 10 документах, допустим. Или за последний месяц. Тогда никаких изменений по архитектуре не надо. Там же, в запросе для сортировки прикрутить последнюю дату ввода строки из даты документа.
Или брать по количеству найденных. Например, последние 5. При этом указать срок побольше. Комбинаций, в общем, много. Выбирайте удобную.

ps: Всегда следует помнить, что на форуме ответчики разного уровня и иногда статус форума в ваших глазах придаёт мнению обывателя весомость, но это мнение может быть неоптимальным или вовсе ошибочным.
---
Чем же? Если хранить строку в ресурсе, то как её искать? Хотя через запрос что справочник, что регистр сведений всё равно.

А если хранить в измерении, то что тогда ресурс?
---
Да ничего нигде не хранится. Строка - всего лишь имя каталога, которая может быть очень длинной. Я лично сделал через справочник, а для поиска дублей использовал хеш. Теоретически есть маловероятная ситуация, когда у 2 разных строк хеши совпадут, и это надо бы обрабатывать, но у меня не такая ценная информация. Если что, можно ввести каталог ещё раз.