Программа 1С предполагает, что каждому объекту нужна отдельная форма выбора. Да, такое иногда нужно. Но в моей практике почти всегда удобно пользоваться одинаковыми формами для выбора (не подбора!) и для списка.
Как мне кажется создавать одну форму списка и форму выбора не правильно с точки зрения подходов к разработке.
Это как с обработчиками событий. Для каждого обработчика своя процедура. Так же и тут для каждой задачи своя форма. Как минимум путаницы будет меньше. Особенно если работаешь не один. И после тебя людям поддерживать и дорабатывать конфигурацию. И люди которые придут со стороны как минимум ожидают что это будут разные формы.
И что потом делать если вдруг надо изменить поведение формы списка, а поведение формы выбора оставить как есть... придётся делать две формы.
(4) TODD22, тут можно поспорить. Повторю публикацию - мне много раз приходилось убеждаться, что когда при выборе значения в поле ввода открывается такая же форма, как и при отображении списка - у пользователя возникает меньший дискомфорт. Он пользуется теми же приемами (например для отбора), что и при работе в форме списка. Колонки находятся на тех же местах, их ширина запомнена, ненужные для пользователя данные он сам выключил, условное оформление, которое он для себя настроил - схоранилось. А когда это две разных формы - то, например, добавлении реквизита или изменения запроса ДС для вывода доп. информации, приходится дорабатывать две формы, что влечет дублирование кода.
И что потом делать если вдруг надо изменить поведение формы списка, а поведение формы выбора оставить как есть... придётся делать две формы.
Как часто приходилось это делать? Понятно, что есть случаи типа отображения остатков и прочие особенности форм подбора. Но посчитайте по своим конфигурациям, сколько форм выбора по отображаемой информации дублируют формы списка. Или отображают меньше информации (которая бывает необходима)?
вот именно - меньше разных контекстов, меньше раздражение кожи пользователя
Ещё ни разу не видел раздражения пользователя на список формы и список выбора... Да так что бы раздражение вызывало что это две разные формы и нужно срочно переделать в одну.
А вот такие "неожиданные" решения ИМХО не правильно. Механизмы должны быть так сказать с ожидаемым поведением и очевидной реализацией, 1С в первую очередь открытая система.
Если везде и всегда используются две разные формы то наверное правильно делать так же. Чем придумывать свой велосипед.
Пусть даже это увеличивает трудоёмкость. Зато это понятно и очевидно.
(9) TODD22, ну, у вас пользователи не настраивают условное оформление, видимо. Не настраивают ширину колонок, не выключают "лишние" для них.
Я посчитал, сколько у меня одинаковых форм и как часто приходится дорабатывать обе, и вывел для себя подобное решение. Например когда дополнительная связанная информация хранится в РС и данные в этом РС вдруг расширили доп. реквизитом, надо этот реквизит добавить в обе формы.
Естественно, данное решение не панацея. Я не призываю его применять вообще везде. Например брать и перепиливать вдоль и поперек объекты типовых конфигураций не следует. А вот провести анализ, понять, сколько же одинаковых форм у нас есть в конфигурации - бывает полезно.
Да вы провокатор батенька.
Вам люди говорят о не нужности лишнего кода и работы, когда можно обойтись одной формой. Это основной принцип программирования - не плодить дубли. Если у вас одна база на три сотрудника и вы её почти не дорабатываете, а только обновляете и регулярно скучаете от просмотра YouTube на работе, то тогда, да, ваш вариант делать много повторяющихся формочек - так не забудете, как программировать. Если вы франчик, который сегодня делает изменения в конфигурации, а завтра его прогнали и взяли другого, а через три месяца снова прибежали к вам, потому что вы делаете "дёсыва", тогда это тоже ваш вариант.
А, если у вас сотрудников 20 тыс. и пользователей около 10 тыс, баз по регионам обменивающихся конфигурацией штук - 100, и во всей этой каше вам постоянно нужно делать разные хотелки в этих конфигурациях, то вы вероятно, будете экономить ваши силы на создание повторяющегося кода. В том числе и ценой общих функций вставляемые в обработчики событий, чтобы не фигачить, как оголтелый, когда нужно будет глобально везде сменить механизм обработки какого-то шаблонного события. Вы работаете в обольшой корпорации, где история работающей конфигурации уже насчитывает второй десяток лет. У вас многие бизнес-процессы не так, как у 1С (потому что это жизнь, а не сферический конь в вакууме!).
Вот об этом толкуют люди. Что касается самой 1С, то она в своём коде уж очень любит всё попилить на кусочки в общих функциях, чтобы это всё бегало из процедуры в процедуру и выполняло там "по одному шажочку".
(7) TODD22, чувак, открой ЗУП 3.0!!! Это АДДДДДДДД. Там фильтров в форме выбора сотрудников (уволен, организация, подразделение, архивный) жесть скока. И может так случиться, что в форме выбора сотрудника нет, а в форме списка есть. И пользователь сходу не врубается, почему данные отличаются. Я молчу, что при выборе физ-лица они показывают формы выбора сотрудника.
Я с автором солидарен: одна форма, единая логика работы! Прячем "архивных" сотрудников, следовательно прячем их и там и там. Один справочник - одна форма со списком.
чувак, открой ЗУП 3.0!!! Это АДДДДДДДД. Там фильтров в форме выбора сотрудников (уволен, организация, подразделение, архивный) жесть скока.
Запустил штук 10 зупов 3.0. Никаких проблем описанных тобой не было ни у одного пользователя с формами списков и выборов так что бы их нужно было переделать в одну форму.
(34) так реакция все равно будет только по своему обработчику. Да и полностью совместить обработку параметров разных обработчиков в одной процедуре не удастся.
(6) Есть конечно и такие формы выбора и списка где одинаково все, но чаще наоборот форма списка раскрашенная , куча настроек быстрых отборов и т.д. А форма выбора минималистична, а порой ввод по строке вообще избавляет от формы выбора.А еще форма выбора очень часто открывается с программным отбором который не нужен списку, ну и так далее, если если если....
Поддержу (13) alyaev.a.v.
Решение с 1 формой не рекомендовал бы только из-за наложенных отборов. На форму списка почти всегда накладываются пользовательские отборы. При использовании этой формы как формы выбора мы рискуем:
- пересечь пользовательский отбор с "программным"
- ввести пользователя в заблуждение, не отобразив доступные для выбора элементы, скрытые пользовательскими отборами.
Хотя реализация с 1 формой встречается и в типовых конфигурациях 1С.
(14) Drak0n, да, с пользовательскими отборами косяк есть. Это один из самых спорных моментов, причем это спорный момент в архитекторе платформы, о который немало копий сломано на партнерском форуме. Сломать форму можно не только в данном случае, но и в случае разных форм. Например, если есть несколько полей, открывающих одну форму выбора с разной связью параметров выбора.
Вроде бы есть даже записанное пожелание у разработчиков 1с, чтобы снималось "использование" пользовательского отбора в случае пересечения фиксированных и пользовательских настроек.
(11) jerry_maguire, к сожалению, этот параметр у формы всегда есть (просто равен Неопределено) и .Свойство() возвращает Истина. А Параметры.Свойство("МножественныйВыбор", Элементы.Список.МножественныйВыбор) вообще выдает ошибку "несоответствие типов".
Ну, для простейших справочников (которые суть перечисления с парой доп-реквизитов) предложение вполне здравое.
Вряд ли там когда-то потребуется отдельная форма выбора, как и отборы.
Мы с самого начала отказались от идеи плодить лишние сущности. Только стандартный код при создании на сервере у нас немножко другой:
ЭтаФорма.Элементы.Список.РежимВыбора = Параметры.РежимВыбора;
Если ЭтаФорма.Элементы.Список.РежимВыбора Тогда
ЭтаФорма.РежимОткрытияОкна = РежимОткрытияОкнаФормы.БлокироватьОкноВладельца;
КонецЕсли;
(23) kg_am, добавлю в пост, если не против
UPD: проверил, при стандартной обработке начала выбора окно и так открывается в этом режиме, эта строка не требуется.
Не так давно тоже начал применять данный подход и столкнулся с двумя особенностями из-за которых перестал использовать данный способ:
1. Сохраняются все настройки формы (добавленные поля, пользовательский отбор, размещение элементов на форме). Добавил я как то в форму списка подчиненного владельцу пользовательский отбор по владельцу, так как на форме списка его не было по бизнес логике, и соответственно он сохранился и применялся в режиме выбора с установленным отбором по владельцу через Связи параметров выбора.
2. Если используется метод глобального контекста ПоказатьВводЗначения или ВвестиЗначение, то в открываемой форме режим выбора не устанавливается, в результате приходится дописывать параметр РежимВыбора в модуль менеджера в событие ОбработкаПолученияФормы при открытии формы выбора что не очень удобно. Не тестировал еще работу в режиме подбора в список значений, открываемый в отборе компоновки с видом сравнения "В списке" и т.п.
(28) Спасибо за замечания!
1. Проблема понятна, обход делается в три строчки:
Если Параметры.РежимВыбора И Не ЗначениеЗаполнено(Параметры.КлючПользовательскихНастроек) Тогда
Параметры.КлючПользовательскихНастроек = "РежимВыбора";
Список.АвтоматическоеСохранениеПользовательскихНастроек = Ложь;
КонецЕсли;
добавлю это в публикацию.
2. Странно, видимо имеет место ошибка платформы в конкретном вашем релизе. У меня при ПоказатьВводЗначения Параметры.РежимВыбора = Истина. Проверял на релизе 8.3.8.2137, режим совместимости = не использовать.
1. Проблема понятна, обход делается в три строчки:
Если Параметры.РежимВыбора И Не ЗначениеЗаполнено(Параметры.КлючПользовательскихНастроек) Тогда
Параметры.КлючПользовательскихНастроек = "РежимВыбора";
Список.АвтоматическоеСохранениеПользовательскихНастроек = Ложь;
КонецЕсли;
добавлю это в публикацию.
На платформе 8.2.19 выдаёт ошибку на этих строках
)}: Поле объекта не обнаружено (КлючПользовательскихНастроек)
Если Параметры.РежимВыбора И Не ЗначениеЗаполнено(Параметры.КлючПользовательскихНастроек) Тогда
И т.к. в 8.2 отборы не запоминаются, то оно и не нужно.
Ещё ни разу не видел раздражения пользователя на список формы и список выбора...
У Вас еще все впереди, видимо :)
И после тебя людям поддерживать и дорабатывать конфигурацию. И люди которые придут со стороны как минимум ожидают что это будут разные формы.
Может стоит посмотреть в основные формы в конфигураторе?
Использование одной формы в место двух оправданно и с точки зрения разработчиков и точки зрения пользователей.
Для меня как для разработчика проще обслуживать одну и туже форму, особенно на сильно доработанных конфигурациях, и особенно на сложных формах. Если в форме 100500 отборов, и она находится в активной разработке, и в день приходит 15 "указивок" что и как изменить.
Например у меня форма документа заказ покупателя:
на форме колонки с текущим долгом, датой ближайшей отгрузки, статусом обеспечения и оплаты, менеджер видит только свои заказы, старший менеджер заказы своего отдела, руководить направления только заказы по своему направлению и еще 50 "если".
И ты еще одну задачу типа "если это младший менеджер, то что бы только не отгруженные", и все это надо сделать в двух СОВЕРШЕННО ОДИНАКОВЫХ ФОРМАХ, открывающихся в разных режимах...
С проблемой программных отборов при открытии формы в режиме выбора пока не сталкивался, но уверен что решение есть. Тоже программное :)
А с точи зрения пользователя - уже писали выше. Одни колонки, одно оформление.
С проблемой программных отборов при открытии формы в режиме выбора пока не сталкивался, но уверен что решение есть. Тоже программное :)
при наличии отборов можно выключать "предопределенные" пользовательские настройки, и использовать отдельный ключ для "непредопределенных". Вторая часть есть в примере кода, первая часть (и для фиксированных настроек для сложногоотбора и для отбора при связи параметров выбора) используется, например в http://infostart.ru/public/556514/ в форме списка документа "Задачи".
Кстати, у 1С в типовых все тоже самое (немного видоизменен код в "ПриСозданииНаСервере" у формы списка), только никаких "нюансов" со множественностью выбора, работает и без этого:
Если Параметры.РежимВыбора Тогда
Элементы.Список.РежимВыбора = Истина;
КонецЕсли;
Подозреваю, что код статьи подсмотрен через партнерский форум в типовых, т.к. навряд ли 1С использовала данный материал в своих разработках ))
(37) ну вот не написали так, сделали через условие. Я же говорю - немного видоизменили.
Главное - что никаких проблем с множественным выбором и пользовательскими настройками.
Поэтому нет дополнительного кода.
Не актуально совсем... 8.3.11.3034 (без режима совместимости)- если форма не является формой выбора - стандартные команды выбора исчезают и недоступны, а в старых формах списка которые использовались как формы выбора - получаем программные ошибки с завершением работы (форма пользователей от ут например)
(43) условия проявления косяка - 8.3.11.3034, Режим совместимости - Не использовать.
Поясню итоги исправлений:
Косяк провился в первую очередь в справочниках из типовой УТ (Пользователи, внешние пользователи, группы пользователей), там форма списка была назначена и на список и на выбор, программно устанавливался Режим выбора у списков на форме, и в зависимости от "РежимВыбора" прятались/показывались кнопки выбора - результат был выбивание из программы. Если у каждого отдельного элемнта формы списка не установлен режим выбора - в списке команд нет стандартной команды "Выбрать", в результате если вынесена кнопка этой команды на форму и управляется её видимость, а режим выбора назначается программно - в случае параметра РежимВыбора = Ложь, у кнопки пропадает команда и кнопка сама пропадает из элемнтов формы, в результате код который их прячет - вызывает ошибку с вылетом.
(44)
1. Это очень похоже на ошибку платформы
2. БСП 2.4 У(и УТ в частности) не поддерживает режим совместимости, отличный от 8.3.10 ;)
надо проверить в БСП 3.0 (ну и на платформе 8.3.12), но там куча косяков и я пока не готов её себе ставить
Тоже было "лень" делать форму выбора, выбрал форму списка и был несказанно удивлен отсутствием у нее в списке свойства аля "Режим выбора" как в обычных формах. Автору спасибо, все получилось, но увидел результат и понял что форма списка с кнопками печатями и подключенным оборудованием выглядит как то диковато ) - все же по хорошему для выбора нужна отдельная форма. Но это конкретно моя ситуация.
Нужно было чтобы настройки формы выбора и формы списка сохранялись отдельно (пробовал на платформе 8.3.13) . Простого решения так и не нашел , привел свое , если есть проще буду рад увидеть .
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
ЭтаФорма.Параметры.ПользовательскиеНастройки = ХранилищеПользовательскихНастроекДинамическихСписков.Загрузить(ЭтаФорма.ИмяФормы,"РежимВыбора",,ПараметрыСеанса.ТекущийПользователь);
ЭтаФорма.Список.АвтоматическоеСохранениеПользовательскихНастроек = Ложь;
КонецПроцедуры
&НаСервере
Процедура ПриЗакрытииНаСервере()
ХранилищеПользовательскихНастроекДинамическихСписков.Сохранить(ЭтаФорма.ИмяФормы,"РежимВыбора",Список.КомпоновщикНастроек.ПользовательскиеНастройки,,ПараметрыСеанса.ТекущийПользователь);
КонецПроцедуры
&НаКлиенте
Процедура ПередЗакрытием(Отказ, ЗавершениеРаботы, ТекстПредупреждения, СтандартнаяОбработка)
Если Элементы.Список.РежимВыбора И НЕ ЗавершениеРаботы Тогда
// Если пользователь нажал кнопку завершения работы во время использования формы выбора последние изменения настроек не будут сохранены.
ПриЗакрытииНаСервере();
КонецЕсли;
КонецПроцедуры
Процедура ФормаСпискаВыбораПриСозданииНаСервере(Знач Список, Знач ЭлементФормыСписок, Знач Параметры, Знач АвтоматическоеСохранениеПользовательскихНастроек = Ложь) Экспорт
// Элементы.Список - основной реквизит с динамическим списком
ЭлементФормыСписок.РежимВыбора = Параметры.РежимВыбора;
Если Параметры.МножественныйВыбор <> Неопределено Тогда
ЭлементФормыСписок.МножественныйВыбор = Параметры.МножественныйВыбор;
КонецЕсли;
// обход автоматического сохранения пользовательских настроек для разных режимов
Если Параметры.РежимВыбора И Не ЗначениеЗаполнено(Параметры.КлючПользовательскихНастроек) Тогда
Параметры.КлючПользовательскихНастроек = "РежимВыбора";
Список.АвтоматическоеСохранениеПользовательскихНастроек = АвтоматическоеСохранениеПользовательскихНастроек;
КонецЕсли;
КонецПроцедуры
Показать
Как раз с параметром для автоматического сохранения
(51) Я пробовал так сделать сначала , но если Установить "АвтоматическоеСохранениеПользовательскихНастроек " в Истина , тогда оно грузит настройки с формы списка , если Ложь , тогда не грузит совсем . А мне нужны были отдельные для Формы "Списка" чтобы сохранялись и для формы "Выбора" чтоб сохранялись .
(54) раньше работало. Такое ощущение, что 1с что-то поломало. Я вставил "Сообщить" во все события формы, связанные с настройками - ни одно из них не вызвалось.
(56) Остановку надо делать в событии таблицы динамического списка ПриСохраненииПользовательскихНастроекНаСервере. Но проблема, описанная в (54) действительно имеется (платформа 8.3.16 в режиме совместимости 8.3.12).
Иногда разные формы списка и выбора очень нужны, когда реализуется такой функционал, чтобы пользователь в форме выбора не мог создавать элементы, а только выбирать, и также, чтобы в форме выбора было минимальное количество колонок, чтобы не путать пользователя.
Иногда разные формы списка и выбора очень нужны, когда реализуется такой функционал, чтобы пользователь в форме выбора не мог создавать элементы, а только выбирать, и также, чтобы в форме выбора было минимальное количество колонок, чтобы не путать пользователя.
Если надо - делайте отдельные формы. Но по моему опыту - достаточно частый случай, когда одна форма достаточно хорошее решение.
(52) Верю, что по вашему личному опыту - это частный случай, а вот по моему опыту не совсем частный. Если делаются новые документы в стандартных конфигурациях, особенно для упр.учета, где используются вновь созданные справочники, то там это широко используется. Очень многие пользователи хотят попроще, не хотят они кучу колонок и кучу кнопок, поэтому в таких случаях разные формы очень актуальны и нужны
У нас часто вместо списков для выбора открывались формы обработки, была в 7ке такая универсальная, выбор из таблицы значений. Работало оно так же медленно, как и любая форма динамического списка в 8ке.
Но в 7ке не было возможности создавать дополнительные поля программно на этой форме.
В 8ке такая возможность есть. В html насколько я поняла, осталась только эта возможность.
Плюс мобильное приложение компилируется под Андроид. Пока у меня нет понимания работы с ос андроид, но интересно, почему нельзя так же скомпилировать и приложение для линукса и виндоус? И еще я не понимаю, что "нам" это даст.
Простите за глупые вопросы:(
Это стандарты разработки 1С в плане интерфейса:
Область применения: управляемое приложение.
Рекомендуется не создавать формы выбора, а использовать генерируемые платформой по умолчанию.
Если, в соответствии с прикладной логикой, в форме выбора нужно предусмотреть особенный состав команд или колонок, то можно создать форму выбора, следуя рекомендациям
В командной панели формы рекомендуется размещать минимально необходимый набор команд для выбора, создания нового и поиска/отбора.
В часто используемых формах выбора из больших наборов данных рекомендуется делать область быстрого отбора/поиска.
Состав колонок следует оптимизировать для быстрого визуального поиска данных
Вопрос почему так рекомендуется.
В БСП 3.1.3 есть исключения, например, Справочник.Пользователи(то, что нашел навскидку). А так все в основном как и рекомендуется, либо форма выбора не задана, либо создана пользователем.