[8.2] Подсистема «Ввод по строке» + видео
Разработка - Механизмы платформы 1С
Файлы
ВНИМАНИЕ: Файлы из Базы знаний - это исходный код разработки. Это примеры решения задач, шаблоны, заготовки, "строительные материалы" для учетной системы. Файлы ориентированы на специалистов 1С, которые могут разобраться в коде и оптимизировать программу для запуска в базе данных. Гарантии работоспособности нет. Возврата нет. Технической поддержки нет.
Подписка PRO — скачивайте любые файлы со скидкой до 85% из Базы знаний
Оформите подписку на компанию для решения рабочих задач
Оформить подписку и скачать решение со скидкойВы можете заказать платную доработку или адаптацию этой разработки под вашу конфигурацию на «Бирже заказов».
- 0% комиссии — оплата напрямую исполнителю;
- Исполнители любого масштаба — от отдельных специалистов до команд под проект;
- Прямой обмен контактами между заказчиком и исполнителем;
- Безопасная сделка — при необходимости;
- Рейтинги, кейсы и прозрачная система откликов.
Когда выходила платформа 8, удобный ввод по строке позиционировали как одно из главных преимуществ перед 7.7. В версии 8.2 стандартную обработку не изменили, но появилась возможность переопределять поведение при вводе по подстроке, и идею этой публикации получилось реализовать практически «по-человечески». Подробнее о вводе по строке для 8.2 можно почитать в книге Разработка управляемого интерфейса, Ажеронок В.А, Островерх А.В., Радченко М.Г. Хрусталева Е.Ю., Глава 3.19 "Ввод по строке", Стр.564
Публикация является продолжением аналога на 8.1 (реализовал все пожелания для 8.1 в версии 8.2)
Описание: Подсистема позволяет предоставить пользователю более удобный и функциональный ввод по строке, а именно:
- Ввод производится по части строки и может содержаться в любом месте текста в начале, середине, конце где угодно
- Учитываются все данные заданные в конфигураторе (Связи выбора, Реквизиты для которых осущ. ввод по строке и т.д.)
- Можно производить поиск нескольким словам, они должны разделятся пробелом (например: "Русь 3" подходят "Русь 3л", "Русь 103")
- Работает со всем типами данных (Справочники, Документы, Перечисления, ПланыВидовХарактеристик, ПланыВидовРасчета, ПланыСчетов, ПланыВидовРасчета, ПланыОбмена, Задачи, БизнесПроцессы)
- Работает везде, где производится выбор значения в поле, таблице и т.д. и повсюду поведение единообразно
- Для документов, бизнес процессов доступен ввод по строке представления "Платежное поручение 0000001 от 10.10.2010 14:00:00" (удобно когда копируешь)
- Более информативный выбор (представление с кодом, видно пометку на удаление, признак проведенности (для документа), предопределенные элементы, признак группы и др.)
- Более удобная сортировка списка выбора (Помеченные на удаление элементы отображаются в конце списка, Документы по датам в порядке убывания и др.)
- Для быстрого выбора значений используется аналогичный более информативный выбор
- Осуществляется поиск с обратной раскладкой (полезно для случаев когда пользователь вводил запрос на неверной раскладке)
Недостатки:
- Относительная сложность встраивания (нужно прописать в менеджере каждого объекта код... можно копипастом)
- Работает только для реквизитов с типом строка (тип: Число не поддерживается)
- Более ресурсоемкий (насколько это уже другой вопрос… вроде все работает быстро)
- Стандартный ввод по подстроке выводит код только если строка поиска у элементов совпадает здесь же код выводится всегда (кроме случаев когда его длина в конфигураторе задана 0)
Все это можно наглядно увидеть на видео:
Встраивание подсистемы:
- Нужно перенести все объекты с префиксом «_» 2 модуля и несколько картинок
- В код менеджера объектов (для которых Ввод будет обрабатываться подсистемой) вставить предопределенную процедуру «ОбработкаПолученияДанныхВыбора» и код аналогичный примеру, можно глянуть для справочника «ТестовыйСправочник»
Внимание!!! Публикую для критики и полезных идей, если кто захочет использовать все вопросы в личку.
Реализацию прорабатывал серьезно, если кто поможет по её улучшению, буду очень благодарен. Огромное спасибо тов. artbear.
Вступайте в нашу телеграмм-группу Инфостарт
См. также
Механизмы платформы 1С Разработчик Бесплатно (free)
Разберем 15 мифов о работе платформы «1С:Предприятие 8» – как распространенных, так и малоизвестных. Начнем с классики: «Код, написанный в одну строку, работает быстрее, чем многострочный». Так ли это на самом деле?
16.07.2025 45526 TitanLuchs 109
Работа с интерфейсом WEB-интеграция Механизмы платформы 1С Бесплатно (free)
Веб-интерфейсы повышают качество внешнего вида приложений 1С, предсказуемы с точки зрения верстки, позволяют организовать удобные и высокопроизводительные рабочие места для пользователей. Расскажем об особенностях разработки веб-интерфейсов на React внутри 1С, двустороннем взаимодействии 1С и JavaScript, а также сборке веб-приложения в одностраничный файл.
19.06.2025 18558 zeegin 15
Механизмы платформы 1С Работа с интерфейсом Разработчик Стажер 1С:Предприятие 8 Бесплатно (free)
Про ООП в 1С и о том, как сделать свой код более кратким и выразительным при помощи использования текучего интерфейса (fluent interface).
03.02.2025 25956 bayselonarrend 127
Механизмы платформы 1С Разработчик 1С:Предприятие 8 Бесплатно (free)
В этой статье подробно рассматривается работа с JSON в XDTO в 1С:Предприятие. Вы узнаете, как сериализовать и десериализовать объекты XDTO в JSON, интегрировать 1С с веб-сервисами и API, а также корректно обрабатывать данные при обмене. Разбираются особенности работы с коллекциями, использование функций восстановления и частые ошибки при работе с JSON и XDTO.
30.01.2025 33146 user2122906 10
Механизмы платформы 1С Файловый обмен (TXT, XML, DBF), FTP Разработчик 1С:Предприятие 8 Бесплатно (free)
Этот материал познакомит вас с механизмом XDTO (XML Data Transfer Objects) в 1С и научит эффективно использовать его возможности. Мы разберёмся, как работать с XML-схемами, создавать модели данных, манипулировать объектами XDTO, а также сериализовать и десериализовать их в XML. Вы узнаете, как использовать XDTO для интеграции с внешними системами, избегать типичных ошибок и оптимизировать код. К концу вы будете уверенно применять XDTO для решения сложных задач обмена данными и автоматизации процессов.
17.01.2025 55497 user2122906 13
Механизмы платформы 1С WEB-интеграция Разработчик 1С:Предприятие 8 Бесплатно (free)
В платформе 8.3.27 появилась возможность использовать WebSocket-клиент. Давайте посмотрим, как это все устроено и чем оно нам полезно.
14.01.2025 46653 dsdred 110
Механизмы платформы 1С Разработчик 1С:Предприятие 8 Бесплатно (free)
Особенности "Знач" и разбор документации к нему.
10.01.2025 26344 VAAngelov 60
Механизмы платформы 1С Разработчик Стажер 1С:Предприятие 8 1C:Бухгалтерия Бесплатно (free)
Эта небольшая статья - некоторого рода шпаргалка по файловым потокам: как и зачем с ними работать, какие преимущества это дает.
23.06.2024 40345 bayselonarrend 24
Плюсую за интересное начинание.
Продать это будет сложно дороже чем за 400 рублей.
Можно конечно, но смысла в сложных запросах нет т.к. ищется в относительно простых коротких строках
Согласен... публикую что бы разработкчики посмотрели оценили покритиковали...
Я не растроюсь если данная идея будет только в моих проектах.
1. Я также себе нечто подобное уже внедрил для 8.1 на базе твоего предыдущего вариант, но ты пошел еще дальше.
В процессе эксплуатации в течение нескольких месяцев обратил внимание на один неудобный момент:
при вводе точного кода/номера происходит довольно долгая заминка (из-за неиндексированного Подобно), штатный вариант 1С быстрее обрабатывает, заминка иногда реально напрягает :)
Я думаю, что здесь нужно сделать какой-то промежуточный вариант - например, в случае, когда есть точные совпадения, выводить список из всех совпадений номеров (быстрый поиск по равенству, аналог штатного варианта) + доп.поле типа "Поиск по подобию". Если пользователь выбирает "Поиск по подобию", то уже выполнять медленный поиск.
2. >> Работает только для реквизитов с типом строка (тип: Число не поддерживается)
т.е. работает штатная схема, верно? Если да, то ИМХО описание лучше дополнить - Тип "Число" не поддерживается, в этом случае используется штатная схема
по п.2. штантная схема в этом случае не используется... выдается ошибка типа "Подсистема ... не поддерж. тип число" нужно устранять на этапе разработки.
при вводе точного кода/номера происходит довольно долгая заминка (из-за неиндексированного Подобно), штатный вариант 1С быстрее обрабатывает, заминка иногда реально напрягает :)
заминка (из-за неиндексированного Подобно), штатный вариант 1С быстрее обрабатывает, заминка иногда реально напрягает :)
В поля Ввода по строке добавляются только индексируемые поля...
Вроде для 8.2 такой проблемы нет
Проверил: Создал 9000 элементов... поиск по коду мгновенно по наименованию тоже
Еще какой момент:
Ты когда писал про поиск разделенный по словам: Ну например: "Русь 3" сейчас заменяет на %Русь%3% т.е. текст "3 Русь" не подходит по шаблон, а я так понимаю по твоей идее должен? Если да то нужно доработать сделать "Русь 3" на %Русь%3% ИЛИ %3%Русь% при том количество условий будет !(факториал) КоличестваСлов
еще хотелось бы сделать определение в каком поле найдено и строить исходя из этого представление. когда найдено в доп.поле не код и наименование в запрос попадает, но не видно почему. Допустим в поле поиска есть ИНН вводим его, находит ОАО Рога и Копыта, но где!
В поля Ввода по строке добавляются только индексируемые поля...
ИМХО При использовании Подобно индекс не используется.
Я получаю заминку при работе с большим количеством документов, количество более миллиона :)
Ты когда писал про поиск разделенный по словам: Ну например: "Русь 3" сейчас заменяет на %Русь%3% т.е. текст "3 Русь" не подходит по шаблон, а я так понимаю по твоей идее должен? Если да то нужно доработать сделать "Русь 3" на %Русь%3% ИЛИ %3%Русь% при том количество условий будет !(факториал) КоличестваСлов
На это не ответил
Если общее количество записей в таблице (это быстрый запрос) более определенного предела, то можно сделать, как я предлагал (сначала точный поиск, а уж потом по подобию), или сделать поиск через Подобно Строка% для использования индекса.
2. По определению в каком поле нашлось не понял, поясни, плиз, на примере.
3. "количество условий будет !(факториал) КоличестваСлов" - также не понял, это же проблемы Скуля :)
ЗЫ у меня пока юзается 8.1 активно до конца года, скорее всего, не перейду на 8.2
поэтому хочу твою систему перекинуть на 8.1 и потестить на реальных больших таблицах.
1. По заминке - может быть, добавить какое-то условие по объему/количеству записей.
Если общее количество записей в таблице (это быстрый запрос) более определенного предела, то можно сделать, как я предлагал (сначала точный поиск, а уж потом по подобию), или сделать поиск через Подобно Строка% для использования индекса.
Если общее количество записей в таблице (это быстрый запрос) более определенного предела, то можно сделать, как я предлагал (сначала точный поиск, а уж потом по подобию), или сделать поиск через Подобно Строка% для использования индекса.
Не пойму в чем выигрыш? когда мы ищем не знаем точный текст указан или нет (ну разве что длину текста поиска сравнить с длиной искомых полей и уже оптимизировать запрос, но это будет работать если полей поиска мало).
Нужно продумать какие оптимизации можно сделать по тексту запроса один из выше описанный пример
2. По определению в каком поле нашлось не понял, поясни, плиз, на примере.
Ну например есть справочник "Контры" ввод по строке : Код, Наименование, ИНН
Сейчас если ввести то поиск по ИНН осуществляется, но если элемент найден по ИНН пользователь этого не видит т.к. представление не включает ИНН. Нужно сделать определение в запросе поле в котором найден текст и в зависимости от этого строить представление аналогично стандартному механизму.
3. "количество условий будет !(факториал) КоличестваСлов" - также не понял, это же проблемы Скуля :)
Допустим запрос: "Русь 3" преобразуется в "%Русь%3%" и элемент "3 Русь" не подходит под запрос хотя как я понимаю должен?
ЗЫ у меня пока юзается 8.1 активно до конца года, скорее всего, не перейду на 8.2
поэтому хочу твою систему перекинуть на 8.1 и потестить на реальных больших таблицах.
Понимаю... если чего это работает и в обычных формах просто не должно стоять режим совместимости с 8.1
Здорово что тестится на больших таблицах... Хочу сделать из подсистемы универсальное оптимальное решение т.к. сказать черный ящик, который работает оптимально, не требует доработок, и который сложно повторить реализовать такой же по функционалу.
Спасибо за твои комментарии они очень для меня полезны.
Самая идея не имеет ценности... думаю скоро что то подобное будет во всех типовых конфах 8.2. Буду дорабатывать и дальше уже есть задачи 1. Более корректное формирование представления (п.2) 2. Оптимальные запросы в зависимости от строки запроса и полей Ввод по строке 3. И есть ошибка не могу понять по чему не сортирует по представлению (по всему сортирует, а по нему нет) 4. Еще подумать о опциях для возможности разработчика вмешиватся в стандартный механизм (добавляя свои особенности)
- Я когда приводил пример кода своего поиска, в первоначальной теме, в этом поиске я стравил ограничение на количество слов. Дело даже не в производительности , при словах больше 10 - поиск начал давать не всегда то, что надо, много лишнего. Насчет точного поиска- я соглашусь, логично сначала искать по точному совпадению, потом по подобию.
Трудно объяснить... попробую на примере
Допустим запрос: "Петр Ив 1"
под этот запрос подпадают:
"Петров Иван 100 лет", "1. Петр Иванович", "Петр 1 Иванов к доске" на и так (1*2*3 = 6) причем 7 слов 7! =~ 5000 т.е. пользователь может повесить систему (это тоже надо учитывать) причем как его предупредить что нельзя вводить такой запрос не знаю как?
Чтобы в запросе это корректно отрабатывалась нужно искать по шаблонам:
"%Петр%Ив%1%","%1%Петр%Ив%", "%Ив%1%Петр%" и т.д.
Данная подсиситема задумана как полная более функциональная замена стандартной обработке и работают они идентично т.е. берутся поля по которым назначен ВводПоСтроке в конфигураторе.
например наименование и инн
Поле ИНН должно быть в полях ВводаПоСтроке в конфигураторе и по нему также будет осуществлятся поиск.
ИМХО типовым кодом не обойдешь :( только или юзать внешние средства (прямой доступ к Скулю, правда, другие СУБД или файловый вариант отдыхают)
или раскладывать представление, получая номер и дату для документа, код или имя для справочника, и выполнять поиск по ним (условие по равно или для даты между)
ЗЫ кстати, еще не видел, как ты сейчас делаешь поиск по представлению.
Какой, интересно, метод юзаешь?
Обновил
1. Оптимизировал поиск по большой строке поиска (точному совпадению)
2. Более правильно формируется представление, ранее не учитывалось поле в котором найден текст
Исправил ошибки:
Ошибка с не иерархическим справочником
Не сортировались результаты поиска
Улучшил код
Что еще можно сделать!?
подумать о решении недостатка:
■ Стандартный ввод по подстроке выводит код только если строка поиска у элементов совпадает здесь же код выводится всегда (кроме случаев когда его длина в конфигураторе задана 0)
и поработать над кодом
ИМХО типовым кодом не обойдешь :( только или юзать внешние средства (прямой доступ к Скулю, правда, другие СУБД или файловый вариант отдыхают)
Не подходит
или раскладывать представление, получая номер и дату для документа, код или имя для справочника, и выполнять поиск по ним (условие по равно или для даты между)
ЗЫ кстати, еще не видел, как ты сейчас делаешь поиск по представлению.
Какой, интересно, метод юзаешь?
Да как! Определяю что строка представление, разбираю на номер и дату... ищу.
Работаю скоро сделаю еще чуток лучше
Для 8.1 встраивание действительно гемор, а в 8.2 все достаточно просто конечно для каждого объекта муторно, но не для каждого же поля как в 8.1 у кое где вообще никак.
Данная подсистема и так большой шаг вперед по сравнению со стандартным поведением платформы... дальше только когда движок улучшат.
Там подгружаются поле "ЭтоГруппа", которого нет у таких объектов.
Как вариант дополнительно проверять тип иерархии:
Если ОбъектМетаданных.Иерархический Тогда //Если справочник иерархический добавим поля группа (иначе: поле не нужно)
СписокПолей.Добавить("ЭтоГруппа");
КонецЕсли;
Добавил такую проверку:
Если ОбъектМетаданных.Иерархический И (ОбъектМетаданных.ВидИерархии = Метаданные.СвойстваОбъектов.ВидИерархии.ИерархияГруппИЭлементов) Тогда
СписокПолей.Добавить("ЭтоГруппа");
КонецЕсли;
подсистема будет/должна работать в толстом клиенте 8.2 ?
Попробовал запустить в толстом клиенте, обработка не запускается, т.к. форма только для управляемого приложения.
исправил основной режим запуска, добавил доп. форму (для обычного клиента),
запустил 1С в толстом клиенте, запустил обработку, открылась моя доп.форма, и ввод по строке из подсистемы не работает :(
Или для толстого клиента нужно явно прописывать обработчик события ВводПоСтроке для каждого реквизита, т.е. как обычно, в 8.1 и 8.2 ?
Удобно для разработчиков, чьи конфы работают в толстом клиенте, без упр.приложения
Запустил толстого клиента (обычное приложение), выбрал меню Операции, Обработки, Обработка1
проверил ввод данных, подсистема прекрасно отработала !!
проверил как на автоформе, так и на собственной форме, созданной вручную.
Т.о. подтверждаю работу в обычных формах
Ура!
ЗЫ что изменил между (45) и (47) включительно? :)
ведь оба проверяли, не работало в обычных формах:(
Подсистема не работает только для внешних обработок (и возможно, отчетов, не проверял) в режиме толстого клиента :(
Внешние обработки в режиме тонкого клиента работают верно!
ЗЫ оказывается, в (43) я не упомянул, что проверял только внешнюю обработку :(
даже не подумал, что может быть разница между внешней и встроенной обработкой.
Поэтому временной обход проблемы для внешних обработок и отчетов в обычном приложении такой:
в модуле формы обработки или отчета вставляем код обработчика
Процедура Реквизит1ОкончаниеВводаТекста(Элемент, Текст, Значение, СтандартнаяОбработка)
СтандартнаяОбработка = Ложь;
ТекущееЗначение = Элемент.Значение;
Параметры = Новый Структура("СтрокаПоиска", Текст);
ПодходящиеЗначения = Справочники[Элемент.Значение.Метаданные().Имя].ПолучитьДанныеВыбора(Параметры); // здесь подменяем метаданные на Документы и т.п.
Если ПодходящиеЗначения = Неопределено Тогда
Возврат;
КонецЕсли;
ВыбранноеЗначение = ВыбратьИзСписка(ПодходящиеЗначения, Элемент);
Значение = ?(ВыбранноеЗначение = Неопределено, ТекущееЗначение, ВыбранноеЗначение.Значение);
КонецПроцедуры
Также можно придумать общий код, чтобы в каждом обработчике не нужно было писать Справочники, Документы и т.п., т.е. сделать аналогично версии для 8.1
ЗЫ я тестировал на 8.2.13.219
совсем неудобен.
Зачем каждый раз вставлять наименование метаданного и его тип, ведь эта инфа уже есть в метаданных.
Проще сделать обобщенный код типа
а внутри основного метода разбирать метаданные.
В итоге прописывание вызова в модуле каждого менеджера метаданных сведется к простому, но безошибочному копи-пасту :)
это явно неудобно.
проще внутри подсистемы эту инфу получить, тем более, что это несложно.
ты сам в 8.1 юзал код типа :)
//
ИначеЕсли Метаданные.Документы.Содержит(НайденныйОбъектМетаданных) Тогда //Документ
Вот также явно проще писать
Не согласен... код прописывается в конфе один раз для одного объекта МД
можно сразу прописать в таком виде чем коде делать ненужный поиск (и другой код)
Производительность пострадает не сильно, т.к. пользователи чаще набирают правильный текст, чем неправильный, и поиск транслитерации будет выполняться не так часто.
Производительность пострадает не сильно, т.к. пользователи чаще набирают правильный текст, чем неправильный, и поиск транслитерации будет выполняться не так часто.
Это все понятно, но по мне перебор... наверно сделаю т.к доделывать особо больше нечего.
По мне алгоритм такой 1.ищем 2.когда не находим ещем преобразованный (но только если преобразованный текст не равен исходному)
По (56) Не согласен... код прописывается в конфе один раз для одного объекта МД
Не один раз для одного объекта :(, а один раз для КАЖДОГО объекта МД.
Будет 20 справочников и 30 документов, нужно будет 50 раз сделать не один простой копи-паст, а копи-паст с исправлением текста в одном/двух местах. совсем не удобно при внедрении в реальные базы :(
лично я для себя переделаю подсистему на свой подход.
удет 20 справочников и 30 документов, нужно будет 50 раз сделать не один простой копи-паст, а копи-паст с исправлением текста в одном/двух местах. совсем не удобно при внедрении в реальные базы :(
При любом внедрении нужно 50 раз скопипастить с изменением.
Какая разница между?
Метаданные.Справочник.Товары и двумя параметрами "Справочник", "Товары"
В 1С так сделано что уже в процедуре обработки не определить что за объект МД
Напиши конкретно что и как ты предлагаешь (код)
В 1С так сделано что уже в процедуре обработки не определить что за объект МД
Не понял, в чем у тебя здесь проблема ?
например, прекрасно работает в табло в режиме Предприятия
Метаданные.Справочники.Найти(Справочники.Контрагенты.ПустаяСсылка().Метаданные())
ЗЫ т.е. тот подход, что ты применял в 8.1, работает и в 8.2
в этом случае 50 раз тупо копипастим, без каких-либо исправлений :) - все просто, легко и безошибочно.
А уж внутри подсистемы по Метаданным определяем нужный тип и работаем с ним.
У тебя же в подсистеме 8.1 примерно так и было сделано :)
В этой части 8.2 сильно отличается от 8.1
Если бы я знал как сделать как ты говоришь уже бы сделал
Код обработки прописывается в модуле менеджера в проц. ОбработкаПолученияДанныхВыбора(ДанныеВыбора, Параметры, СтандартнаяОбработка)
в параметрах нет объекта для которого она вызвана и я не знаю как можно определить объект МД для которого она вызвана (так понимаю что в тек. версии платформы никак)
,
В этой части 8.2 сильно отличается от 8.1
Если бы я знал как сделать как ты говоришь уже бы сделал
Код обработки прописывается в модуле менеджера в проц. ОбработкаПолученияДанныхВыбора(ДанныеВыбора, Параметры, СтандартнаяОбработка)
в параметрах нет объекта для которого она вызвана и я не знаю как можно определить объект МД для которого она вызвана (так понимаю что в тек. версии платформы никак)
ИМХО Тут ты заплутал слегка :(
Кто мешает написать в модуле менеджера следующим образом
И тормозов не будет, и метаданные доступны.
(69) Допишу. Посмотри плиз реализацию функции преобразования раскладки может лучше можно
// Формирует строку на другой раскладке клавиатуры
//
// Параметры :
// Строка (Строка) - Исходная (преобразуемая) строка
//
// Возвращаемое значение:
// (Строка) - Преобразованная строка
//
// Например:
// Вход: "Русь"; Выход: "Hecm" (на другой раскладке)
Функция СтрокаНаДругойРаскладке (Строка)
СтрокаРезультат = "";
//Подготовка строк для преобразования
СтрокаНаРусскойРаскладкеНРег = "йцукенгшщзхъфывапролджэячсмитьбю.";
СтрокаНаАнглискойРаскладкеНРег = "qwertyuiop[]asdfghjkl;'zxcvbnm,./";
СтрокаНаРусскойРаскладке = СтрокаНаРусскойРаскладкеНРег + ВРег(СтрокаНаРусскойРаскладкеНРег);
СтрокаНаАнглискойРаскладке = СтрокаНаАнглискойРаскладкеНРег + ВРег(СтрокаНаАнглискойРаскладкеНРег);
Для Сч = 1 По СтрДлина(Строка) Цикл
Символ = Сред(Строка, Сч, 1);
НомерСимвола = Найти(СтрокаНаАнглискойРаскладке, Символ);
Если НомерСимвола Тогда
Символ = Сред(СтрокаНаРусскойРаскладкеНРег, НомерСимвола, 1);
Иначе
НомерСимвола = Найти(СтрокаНаРусскойРаскладке, Символ);
Если НомерСимвола Тогда
Символ = Сред(СтрокаНаАнглискойРаскладке, НомерСимвола, 1);
КонецЕсли;
КонецЕсли;
СтрокаРезультат = СтрокаРезультат + Символ;
КонецЦикла;
Возврат СтрокаРезультат;
КонецФункции
Показатьправильно и более производительно
2. СтрДлина(Строка) из заголовка цикла выкинуть, иначе будет вычисляться при каждой итерации.
3. Весь цикл лучше сделать в одну строку, производительность будет выше, читабельность хуже.
В остальном нормально, код не так часто будет выполняться, основные тормоза все равно на запросе будут.
1.Никакой опечатки все правильно НРег - это в нижнем регистре надо подумать ведь при подобно регистр не имеет значения
2.Да, можно
3.Не надо противоречит методикам разработки от 1С
Пока снял публикацию там была ошибка с перечислениями... доработаю выложу
не так уж редко нужный текст набирается не в той раскладке :(
В результате выдается ошибка, нужно наживать лишние клавиши, удалять текст, переключать раскладку и заново набирать текст.
В итоге такая схема напрягает :(
ИМХО можно сделать так: сначала подсистема работает как обычно, получает список подходящих элементов, если они найдены, возвращаем этот список. Но если список пуст, то выполняем проверку на наличие русских символов, если они есть, возвращаем пустой список, иначе выполняем транслитерацию текста на другую раскладку, и выполняем поиск по этому новому тексту.
Производительность пострадает не сильно, т.к. пользователи чаще набирают правильный текст, чем неправильный, и поиск транслитерации будет выполняться не так часто.
ЗЫ Аналогичный подход по транслитерации сейчас работает в Снегопате snegopat.ru
Очень удобно, не слишком заморачиваешься с ошибками :)
Версия 1.1
1.Общий модуль теперь входит в подсистему
2.Исправил ошибку в толстом клиенте проявлялось в версии 1.0 (в тонком все работало)
3.Теперь внедрение выглядит так:
ДанныеВыбора = _ВводПостроке.ПолучитьДанныеДляВыбора(ПустаяСсылка(), Параметры, СтандартнаяОбработка);при работе с внешней обработкой
Выдается ошибка "Попытка передачи мутабельного значения результата метода _ВводПостроке.ПолучитьДанныеДляВыбора"
видимо, на список значений ругается :(
ЗЫ странно, запускал твою конфу в таком режиме, внешняя обработка работает без проблем :(
Итак, чтобы запустить подсистему в толстом клиенте (обычное приложение) для клиент-серверного варианта базы основным режимом запуска "Обычное приложение", нужно:
1. Исправить свойства общего модуля _ОбщийМодульКлиентСервер, установив свойство "Клиент (обычного приложение)"
2. Добавить в общий модуль _ОбщийМодульКлиентСервер след.функцию
// удобно юзать для исключения ошибки: Попытка передачи мутабельного значения
Функция _ПолучитьСписокИзМассива(массивДляСписка) Экспорт
список = Новый СписокЗначений;
Для каждого лСтруктура Из массивДляСписка Цикл
список.Добавить(лСтруктура.Значение, лСтруктура.Представление, ,лСтруктура.Картинка);
КонецЦикла;
Возврат список;
КонецФункции
3. Изменить метод СформироватьСписок из общего модуля _ВводПостроке
в самом конце метода вместо кода
написать следующий код
Для каждого элемент Из Список Цикл
лСтруктура = Новый Структура("Значение,Представление,Картинка");
ЗаполнитьЗначенияСвойств(лСтруктура, элемент);
массивСписка.Добавить(лСтруктура);
КонецЦикла;
Возврат массивСписка;
4. В обработчика события ОбработкаПолученияДанныхВыбора каждого менеджера метаданных
после вызова основного метода ДанныеВыбора = _ВводПостроке.ПолучитьДанныеДляВыбора
добавить код
ДанныеВыбора = _ПолучитьСписокИзМассива(ДанныеВыбора);
КонецЕсли;
0.Исправил ошибки
1.Переработал с учетом более простого внедрения
2.Переработал код + мелкие оптимизации (если текст на преобразованной раскладке и текст запроса совпадают поиск не производится)
------
Подсистема заслужила номер версии 1.0
ИначеЕсли Тип(Тип) <> ТипЗнч("Строка") Тогда
Может я что-то пропустил в туториал? Спасибо за хэлп)
}: Тип не визначений (Рядок)
ИначеЕсли Тип(Тип) <> ТипЗнч("Строка") Тогда
ИначеЕсли Тип(Тип) <> ТипЗнч("Строка") Тогда
Может я что-то пропустил в туториал? Спасибо за хэлп)
Может это - Недостатки:
■ Работает только для реквизитов с типом строка (тип: Число не поддерживается)
Если не то, напишите подробно
//Если ИмяПоля = "ХХХХХ" Тогда
// ВызватьИсключение НСтр("ru = 'Ошибка подсистемы ввод по строке... нельзя использовать имя ХХХХХ оно зарезервировано подсистемой'");
//ИначеЕсли Тип(Тип) <> ТипЗнч("Строка") Тогда
// ВызватьИсключение НСтр("ru = 'Ошибка подсистемы ввод по строке... один из реквизитов нестрокового типа'");
//КонецЕсли;
Вот)
Точка останова показала, что процесс идет через эту ветвь Тип = НайденныйРеквизит.Тип; Но Тип(Тип) не функциклирует. Выдает эту ошибку.
ИначеЕсли НЕ Тип.СодержитТип(Тип("Строка")) Тогда
Приемлемо? Извини, пожалуйста, что надоедаю, две недели на 1с программирую. Спасибо за терпение)
ИначеЕсли НЕ Тип.СодержитТип(Тип("Строка")) Тогда
Приемлемо? Извини, пожалуйста, что надоедаю, две недели на 1с программирую. Спасибо за терпение)
Чет странно что у вас за тип поля (для ввода по строке)???
Что делает эта проверка? От чего защищает?
Пример:
Если ТипЗнч(ТекОбъект) = Тип("СправочникСсылка.Номенклатура") Тогда
...
КонецЕсли;
Стало вываливаться исключение)
2) Еще - не срабатывает сообщение платформы про 51 - показывает пустой список.((
3) Из-за всего этого жаль, что в отчетах придется додумывать как править поля отбора.
Но тема реально удобная, потому огромное спасибо за труд)))
Работает, но с некоторыми особенностями:
- Ищет, только если введено 3 и больше символа.
- Из нескольких похожих строк в списке выбора показывает только одну наиболее подходящую.
Напр.: Иван, тел. = "0632553311"
Николай, тел. = "0671234567, 0632553377"
В поле ввода набираем "063", "0632" или ""063255" - подбирает только Ивана, Николая не находит.
И только при наборе "0632557" или "06325577" - находит Николая.
П.С. Понял - это срабатывает стандартный механизм 1С поиска по строке. А как в таком случае его обходить?
Подскажите, я недавно реализовал нечто подобное, но на обычной форме 8.2
Столкнулся с одной неприятностью: после ввода первых символов, список внизу раскрывается и курсор (фокус) уходит с поля ввода на этот список. Дальнейший ввод символов возможен только после установки курсора обратно, на поле ввода.
Очень неудобно. Подскажите, как заставить не "ускользать" фокус с поля ввода?
Вы можете заказать платную консультацию или разработку у автора. Будет создан приватный заказ на «Бирже заказов» для автора.
№ 89892
Создание 10.09.11 14:04
Обновление 30.12.19 12:11
Просмотры 43386
Загрузки 299
Рейтинг
123
Комментарии 129
Код открыт Да
Рубрики Механизмы платформы 1С
Кому Разработчик
Тип файла Архив с данными
Платформа 1С:Предприятие 8
Конфигурация 1C:Бухгалтерия
Операционная система Не имеет значения
Страна Россия
Отрасль Не имеет значения
Налоги Не имеет значения
Вид учета Не имеет значения
Доступ к файлу Абонемент ($m)
