Хватит создавать формы выбора!
Комментарии
В избранное
Подписаться на ответы
Сортировка:
Древо развёрнутое
Свернуть все
(3) konstruktiv,
Как мне кажется создавать одну форму списка и форму выбора не правильно с точки зрения подходов к разработке.
Это как с обработчиками событий. Для каждого обработчика своя процедура. Так же и тут для каждой задачи своя форма. Как минимум путаницы будет меньше. Особенно если работаешь не один. И после тебя людям поддерживать и дорабатывать конфигурацию. И люди которые придут со стороны как минимум ожидают что это будут разные формы.
И что потом делать если вдруг надо изменить поведение формы списка, а поведение формы выбора оставить как есть... придётся делать две формы.
ИМХО не очень красивое решение...
Получается здесь какая-то неактуальная информация
Как мне кажется создавать одну форму списка и форму выбора не правильно с точки зрения подходов к разработке.
Это как с обработчиками событий. Для каждого обработчика своя процедура. Так же и тут для каждой задачи своя форма. Как минимум путаницы будет меньше. Особенно если работаешь не один. И после тебя людям поддерживать и дорабатывать конфигурацию. И люди которые придут со стороны как минимум ожидают что это будут разные формы.
И что потом делать если вдруг надо изменить поведение формы списка, а поведение формы выбора оставить как есть... придётся делать две формы.
ИМХО не очень красивое решение...
(4) TODD22, тут можно поспорить. Повторю публикацию - мне много раз приходилось убеждаться, что когда при выборе значения в поле ввода открывается такая же форма, как и при отображении списка - у пользователя возникает меньший дискомфорт. Он пользуется теми же приемами (например для отбора), что и при работе в форме списка. Колонки находятся на тех же местах, их ширина запомнена, ненужные для пользователя данные он сам выключил, условное оформление, которое он для себя настроил - схоранилось. А когда это две разных формы - то, например, добавлении реквизита или изменения запроса ДС для вывода доп. информации, приходится дорабатывать две формы, что влечет дублирование кода.
Как часто приходилось это делать? Понятно, что есть случаи типа отображения остатков и прочие особенности форм подбора. Но посчитайте по своим конфигурациям, сколько форм выбора по отображаемой информации дублируют формы списка. Или отображают меньше информации (которая бывает необходима)?
И что потом делать если вдруг надо изменить поведение формы списка, а поведение формы выбора оставить как есть... придётся делать две формы.
Как часто приходилось это делать? Понятно, что есть случаи типа отображения остатков и прочие особенности форм подбора. Но посчитайте по своим конфигурациям, сколько форм выбора по отображаемой информации дублируют формы списка. Или отображают меньше информации (которая бывает необходима)?
(6)
ИМХО тут даже спорить не о чем.
Нужно придерживаться стиля применяемого в типовых...
А не придумывать свои велосипеды...
Так создание однотипных обработчиков событий то же ведёт к дублированию кода. Может тогда один обработчик начать делать?
А что приёмы в форме выбора и форме списка отличаются?
тут можно поспорить.
ИМХО тут даже спорить не о чем.
Нужно придерживаться стиля применяемого в типовых...
А не придумывать свои велосипеды...
влечет дублирование кода.
Так создание однотипных обработчиков событий то же ведёт к дублированию кода. Может тогда один обработчик начать делать?
Он пользуется теми же приемами (например для отбора), что и при работе в форме списка.
А что приёмы в форме выбора и форме списка отличаются?
(8)
Ещё ни разу не видел раздражения пользователя на список формы и список выбора... Да так что бы раздражение вызывало что это две разные формы и нужно срочно переделать в одну.
А вот такие "неожиданные" решения ИМХО не правильно. Механизмы должны быть так сказать с ожидаемым поведением и очевидной реализацией, 1С в первую очередь открытая система.
Если везде и всегда используются две разные формы то наверное правильно делать так же. Чем придумывать свой велосипед.
Пусть даже это увеличивает трудоёмкость. Зато это понятно и очевидно.
вот именно - меньше разных контекстов, меньше раздражение кожи пользователя
Ещё ни разу не видел раздражения пользователя на список формы и список выбора... Да так что бы раздражение вызывало что это две разные формы и нужно срочно переделать в одну.
А вот такие "неожиданные" решения ИМХО не правильно. Механизмы должны быть так сказать с ожидаемым поведением и очевидной реализацией, 1С в первую очередь открытая система.
Если везде и всегда используются две разные формы то наверное правильно делать так же. Чем придумывать свой велосипед.
Пусть даже это увеличивает трудоёмкость. Зато это понятно и очевидно.
(9) TODD22, ну, у вас пользователи не настраивают условное оформление, видимо. Не настраивают ширину колонок, не выключают "лишние" для них.
Я посчитал, сколько у меня одинаковых форм и как часто приходится дорабатывать обе, и вывел для себя подобное решение. Например когда дополнительная связанная информация хранится в РС и данные в этом РС вдруг расширили доп. реквизитом, надо этот реквизит добавить в обе формы.
Естественно, данное решение не панацея. Я не призываю его применять вообще везде. Например брать и перепиливать вдоль и поперек объекты типовых конфигураций не следует. А вот провести анализ, понять, сколько же одинаковых форм у нас есть в конфигурации - бывает полезно.
Я посчитал, сколько у меня одинаковых форм и как часто приходится дорабатывать обе, и вывел для себя подобное решение. Например когда дополнительная связанная информация хранится в РС и данные в этом РС вдруг расширили доп. реквизитом, надо этот реквизит добавить в обе формы.
Естественно, данное решение не панацея. Я не призываю его применять вообще везде. Например брать и перепиливать вдоль и поперек объекты типовых конфигураций не следует. А вот провести анализ, понять, сколько же одинаковых форм у нас есть в конфигурации - бывает полезно.
Да вы провокатор батенька.
Вам люди говорят о не нужности лишнего кода и работы, когда можно обойтись одной формой. Это основной принцип программирования - не плодить дубли. Если у вас одна база на три сотрудника и вы её почти не дорабатываете, а только обновляете и регулярно скучаете от просмотра YouTube на работе, то тогда, да, ваш вариант делать много повторяющихся формочек - так не забудете, как программировать. Если вы франчик, который сегодня делает изменения в конфигурации, а завтра его прогнали и взяли другого, а через три месяца снова прибежали к вам, потому что вы делаете "дёсыва", тогда это тоже ваш вариант.
А, если у вас сотрудников 20 тыс. и пользователей около 10 тыс, баз по регионам обменивающихся конфигурацией штук - 100, и во всей этой каше вам постоянно нужно делать разные хотелки в этих конфигурациях, то вы вероятно, будете экономить ваши силы на создание повторяющегося кода. В том числе и ценой общих функций вставляемые в обработчики событий, чтобы не фигачить, как оголтелый, когда нужно будет глобально везде сменить механизм обработки какого-то шаблонного события. Вы работаете в обольшой корпорации, где история работающей конфигурации уже насчитывает второй десяток лет. У вас многие бизнес-процессы не так, как у 1С (потому что это жизнь, а не сферический конь в вакууме!).
Вот об этом толкуют люди. Что касается самой 1С, то она в своём коде уж очень любит всё попилить на кусочки в общих функциях, чтобы это всё бегало из процедуры в процедуру и выполняло там "по одному шажочку".
Вам люди говорят о не нужности лишнего кода и работы, когда можно обойтись одной формой. Это основной принцип программирования - не плодить дубли. Если у вас одна база на три сотрудника и вы её почти не дорабатываете, а только обновляете и регулярно скучаете от просмотра YouTube на работе, то тогда, да, ваш вариант делать много повторяющихся формочек - так не забудете, как программировать. Если вы франчик, который сегодня делает изменения в конфигурации, а завтра его прогнали и взяли другого, а через три месяца снова прибежали к вам, потому что вы делаете "дёсыва", тогда это тоже ваш вариант.
А, если у вас сотрудников 20 тыс. и пользователей около 10 тыс, баз по регионам обменивающихся конфигурацией штук - 100, и во всей этой каше вам постоянно нужно делать разные хотелки в этих конфигурациях, то вы вероятно, будете экономить ваши силы на создание повторяющегося кода. В том числе и ценой общих функций вставляемые в обработчики событий, чтобы не фигачить, как оголтелый, когда нужно будет глобально везде сменить механизм обработки какого-то шаблонного события. Вы работаете в обольшой корпорации, где история работающей конфигурации уже насчитывает второй десяток лет. У вас многие бизнес-процессы не так, как у 1С (потому что это жизнь, а не сферический конь в вакууме!).
Вот об этом толкуют люди. Что касается самой 1С, то она в своём коде уж очень любит всё попилить на кусочки в общих функциях, чтобы это всё бегало из процедуры в процедуру и выполняло там "по одному шажочку".
(7) TODD22, чувак, открой ЗУП 3.0!!! Это АДДДДДДДД. Там фильтров в форме выбора сотрудников (уволен, организация, подразделение, архивный) жесть скока. И может так случиться, что в форме выбора сотрудника нет, а в форме списка есть. И пользователь сходу не врубается, почему данные отличаются. Я молчу, что при выборе физ-лица они показывают формы выбора сотрудника.
Я с автором солидарен: одна форма, единая логика работы! Прячем "архивных" сотрудников, следовательно прячем их и там и там. Один справочник - одна форма со списком.
Я с автором солидарен: одна форма, единая логика работы! Прячем "архивных" сотрудников, следовательно прячем их и там и там. Один справочник - одна форма со списком.
(21) monkbest,
Запустил штук 10 зупов 3.0. Никаких проблем описанных тобой не было ни у одного пользователя с формами списков и выборов так что бы их нужно было переделать в одну форму.
чувак, открой ЗУП 3.0!!! Это АДДДДДДДД. Там фильтров в форме выбора сотрудников (уволен, организация, подразделение, архивный) жесть скока.
Запустил штук 10 зупов 3.0. Никаких проблем описанных тобой не было ни у одного пользователя с формами списков и выборов так что бы их нужно было переделать в одну форму.
(6) Есть конечно и такие формы выбора и списка где одинаково все, но чаще наоборот форма списка раскрашенная , куча настроек быстрых отборов и т.д. А форма выбора минималистична, а порой ввод по строке вообще избавляет от формы выбора.А еще форма выбора очень часто открывается с программным отбором который не нужен списку, ну и так далее, если если если....
Поддержу (13) alyaev.a.v.
Решение с 1 формой не рекомендовал бы только из-за наложенных отборов. На форму списка почти всегда накладываются пользовательские отборы. При использовании этой формы как формы выбора мы рискуем:
- пересечь пользовательский отбор с "программным"
- ввести пользователя в заблуждение, не отобразив доступные для выбора элементы, скрытые пользовательскими отборами.
Хотя реализация с 1 формой встречается и в типовых конфигурациях 1С.
Решение с 1 формой не рекомендовал бы только из-за наложенных отборов. На форму списка почти всегда накладываются пользовательские отборы. При использовании этой формы как формы выбора мы рискуем:
- пересечь пользовательский отбор с "программным"
- ввести пользователя в заблуждение, не отобразив доступные для выбора элементы, скрытые пользовательскими отборами.
Хотя реализация с 1 формой встречается и в типовых конфигурациях 1С.
(14) Drak0n, да, с пользовательскими отборами косяк есть. Это один из самых спорных моментов, причем это спорный момент в архитекторе платформы, о который немало копий сломано на партнерском форуме. Сломать форму можно не только в данном случае, но и в случае разных форм. Например, если есть несколько полей, открывающих одну форму выбора с разной связью параметров выбора.
Вроде бы есть даже записанное пожелание у разработчиков 1с, чтобы снималось "использование" пользовательского отбора в случае пересечения фиксированных и пользовательских настроек.
Вроде бы есть даже записанное пожелание у разработчиков 1с, чтобы снималось "использование" пользовательского отбора в случае пересечения фиксированных и пользовательских настроек.
Мы с самого начала отказались от идеи плодить лишние сущности. Только стандартный код при создании на сервере у нас немножко другой:
За нюанс с множественным выбором - спасибо.
ЭтаФорма.Элементы.Список.РежимВыбора = Параметры.РежимВыбора;
Если ЭтаФорма.Элементы.Список.РежимВыбора Тогда
ЭтаФорма.РежимОткрытияОкна = РежимОткрытияОкнаФормы.БлокироватьОкноВладельца;
КонецЕсли;
За нюанс с множественным выбором - спасибо.
Не так давно тоже начал применять данный подход и столкнулся с двумя особенностями из-за которых перестал использовать данный способ:
1. Сохраняются все настройки формы (добавленные поля, пользовательский отбор, размещение элементов на форме). Добавил я как то в форму списка подчиненного владельцу пользовательский отбор по владельцу, так как на форме списка его не было по бизнес логике, и соответственно он сохранился и применялся в режиме выбора с установленным отбором по владельцу через Связи параметров выбора.
2. Если используется метод глобального контекста ПоказатьВводЗначения или ВвестиЗначение, то в открываемой форме режим выбора не устанавливается, в результате приходится дописывать параметр РежимВыбора в модуль менеджера в событие ОбработкаПолученияФормы при открытии формы выбора что не очень удобно. Не тестировал еще работу в режиме подбора в список значений, открываемый в отборе компоновки с видом сравнения "В списке" и т.п.
1. Сохраняются все настройки формы (добавленные поля, пользовательский отбор, размещение элементов на форме). Добавил я как то в форму списка подчиненного владельцу пользовательский отбор по владельцу, так как на форме списка его не было по бизнес логике, и соответственно он сохранился и применялся в режиме выбора с установленным отбором по владельцу через Связи параметров выбора.
2. Если используется метод глобального контекста ПоказатьВводЗначения или ВвестиЗначение, то в открываемой форме режим выбора не устанавливается, в результате приходится дописывать параметр РежимВыбора в модуль менеджера в событие ОбработкаПолученияФормы при открытии формы выбора что не очень удобно. Не тестировал еще работу в режиме подбора в список значений, открываемый в отборе компоновки с видом сравнения "В списке" и т.п.
(28) Спасибо за замечания!
1. Проблема понятна, обход делается в три строчки:
Если Параметры.РежимВыбора И Не ЗначениеЗаполнено(Параметры.КлючПользовательскихНастроек) Тогда
Параметры.КлючПользовательскихНастроек = "РежимВыбора";
Список.АвтоматическоеСохранениеПользовательскихНастроек = Ложь;
КонецЕсли;
добавлю это в публикацию.
2. Странно, видимо имеет место ошибка платформы в конкретном вашем релизе. У меня при ПоказатьВводЗначения Параметры.РежимВыбора = Истина. Проверял на релизе 8.3.8.2137, режим совместимости = не использовать.
1. Проблема понятна, обход делается в три строчки:
Если Параметры.РежимВыбора И Не ЗначениеЗаполнено(Параметры.КлючПользовательскихНастроек) Тогда
Параметры.КлючПользовательскихНастроек = "РежимВыбора";
Список.АвтоматическоеСохранениеПользовательскихНастроек = Ложь;
КонецЕсли;
добавлю это в публикацию.
2. Странно, видимо имеет место ошибка платформы в конкретном вашем релизе. У меня при ПоказатьВводЗначения Параметры.РежимВыбора = Истина. Проверял на релизе 8.3.8.2137, режим совместимости = не использовать.
(29)
И т.к. в 8.2 отборы не запоминаются, то оно и не нужно.
1. Проблема понятна, обход делается в три строчки:
Если Параметры.РежимВыбора И Не ЗначениеЗаполнено(Параметры.КлючПользовательскихНастроек) Тогда
Параметры.КлючПользовательскихНастроек = "РежимВыбора";
Список.АвтоматическоеСохранениеПользовательскихНастроек = Ложь;
КонецЕсли;
добавлю это в публикацию.
На платформе 8.2.19 выдаёт ошибку на этих строках
Если Параметры.РежимВыбора И Не ЗначениеЗаполнено(Параметры.КлючПользовательскихНастроек) Тогда
Параметры.КлючПользовательскихНастроек = "РежимВыбора";
Список.АвтоматическоеСохранениеПользовательскихНастроек = Ложь;
КонецЕсли;
добавлю это в публикацию.
)}: Поле объекта не обнаружено (КлючПользовательскихНастроек)
Если Параметры.РежимВыбора И Не ЗначениеЗаполнено(Параметры.КлючПользовательскихНастроек) Тогда
И т.к. в 8.2 отборы не запоминаются, то оно и не нужно.
Ещё ни разу не видел раздражения пользователя на список формы и список выбора...
У Вас еще все впереди, видимо :)
И после тебя людям поддерживать и дорабатывать конфигурацию. И люди которые придут со стороны как минимум ожидают что это будут разные формы.
Может стоит посмотреть в основные формы в конфигураторе?
Использование одной формы в место двух оправданно и с точки зрения разработчиков и точки зрения пользователей.
Для меня как для разработчика проще обслуживать одну и туже форму, особенно на сильно доработанных конфигурациях, и особенно на сложных формах. Если в форме 100500 отборов, и она находится в активной разработке, и в день приходит 15 "указивок" что и как изменить.
Например у меня форма документа заказ покупателя:
на форме колонки с текущим долгом, датой ближайшей отгрузки, статусом обеспечения и оплаты, менеджер видит только свои заказы, старший менеджер заказы своего отдела, руководить направления только заказы по своему направлению и еще 50 "если".
И ты еще одну задачу типа "если это младший менеджер, то что бы только не отгруженные", и все это надо сделать в двух СОВЕРШЕННО ОДИНАКОВЫХ ФОРМАХ, открывающихся в разных режимах...
С проблемой программных отборов при открытии формы в режиме выбора пока не сталкивался, но уверен что решение есть. Тоже программное :)
А с точи зрения пользователя - уже писали выше. Одни колонки, одно оформление.
(30)
при наличии отборов можно выключать "предопределенные" пользовательские настройки, и использовать отдельный ключ для "непредопределенных". Вторая часть есть в примере кода, первая часть (и для фиксированных настроек для сложногоотбора и для отбора при связи параметров выбора) используется, например в в форме списка документа "Задачи".
С проблемой программных отборов при открытии формы в режиме выбора пока не сталкивался, но уверен что решение есть. Тоже программное :)
при наличии отборов можно выключать "предопределенные" пользовательские настройки, и использовать отдельный ключ для "непредопределенных". Вторая часть есть в примере кода, первая часть (и для фиксированных настроек для сложногоотбора и для отбора при связи параметров выбора) используется, например в в форме списка документа "Задачи".
Кстати, у 1С в типовых все тоже самое (немного видоизменен код в "ПриСозданииНаСервере" у формы списка), только никаких "нюансов" со множественностью выбора, работает и без этого:
Подозреваю, что код статьи подсмотрен через партнерский форум в типовых, т.к. навряд ли 1С использовала данный материал в своих разработках ))
Если Параметры.РежимВыбора Тогда
Элементы.Список.РежимВыбора = Истина;
КонецЕсли;
Подозреваю, что код статьи подсмотрен через партнерский форум в типовых, т.к. навряд ли 1С использовала данный материал в своих разработках ))
Прикрепленные файлы:
Не актуально совсем... 8.3.11.3034 (без режима совместимости)- если форма не является формой выбора - стандартные команды выбора исчезают и недоступны, а в старых формах списка которые использовались как формы выбора - получаем программные ошибки с завершением работы (форма пользователей от ут например)
(43) условия проявления косяка - 8.3.11.3034, Режим совместимости - Не использовать.
Поясню итоги исправлений:
Косяк провился в первую очередь в справочниках из типовой УТ (Пользователи, внешние пользователи, группы пользователей), там форма списка была назначена и на список и на выбор, программно устанавливался Режим выбора у списков на форме, и в зависимости от "РежимВыбора" прятались/показывались кнопки выбора - результат был выбивание из программы. Если у каждого отдельного элемнта формы списка не установлен режим выбора - в списке команд нет стандартной команды "Выбрать", в результате если вынесена кнопка этой команды на форму и управляется её видимость, а режим выбора назначается программно - в случае параметра РежимВыбора = Ложь, у кнопки пропадает команда и кнопка сама пропадает из элемнтов формы, в результате код который их прячет - вызывает ошибку с вылетом.
Поясню итоги исправлений:
Косяк провился в первую очередь в справочниках из типовой УТ (Пользователи, внешние пользователи, группы пользователей), там форма списка была назначена и на список и на выбор, программно устанавливался Режим выбора у списков на форме, и в зависимости от "РежимВыбора" прятались/показывались кнопки выбора - результат был выбивание из программы. Если у каждого отдельного элемнта формы списка не установлен режим выбора - в списке команд нет стандартной команды "Выбрать", в результате если вынесена кнопка этой команды на форму и управляется её видимость, а режим выбора назначается программно - в случае параметра РежимВыбора = Ложь, у кнопки пропадает команда и кнопка сама пропадает из элемнтов формы, в результате код который их прячет - вызывает ошибку с вылетом.
Тоже было "лень" делать форму выбора, выбрал форму списка и был несказанно удивлен отсутствием у нее в списке свойства аля "Режим выбора" как в обычных формах. Автору спасибо, все получилось, но увидел результат и понял что форма списка с кнопками печатями и подключенным оборудованием выглядит как то диковато ) - все же по хорошему для выбора нужна отдельная форма. Но это конкретно моя ситуация.
Нужно было чтобы настройки формы выбора и формы списка сохранялись отдельно (пробовал на платформе 8.3.13) . Простого решения так и не нашел , привел свое , если есть проще буду рад увидеть .
&НаСервере
Процедура ПриСозданииНаСервере(Отказ, СтандартнаяОбработка)
ЭтаФорма.Параметры.ПользовательскиеНастройки = ХранилищеПользовательскихНастроекДинамическихСписков.Загрузить(ЭтаФорма.ИмяФормы,"РежимВыбора",,ПараметрыСеанса.ТекущийПользователь);
ЭтаФорма.Список.АвтоматическоеСохранениеПользовательскихНастроек = Ложь;
КонецПроцедуры
&НаСервере
Процедура ПриЗакрытииНаСервере()
ХранилищеПользовательскихНастроекДинамическихСписков.Сохранить(ЭтаФорма.ИмяФормы,"РежимВыбора",Список.КомпоновщикНастроек.ПользовательскиеНастройки,,ПараметрыСеанса.ТекущийПользователь);
КонецПроцедуры
&НаКлиенте
Процедура ПередЗакрытием(Отказ, ЗавершениеРаботы, ТекстПредупреждения, СтандартнаяОбработка)
Если Элементы.Список.РежимВыбора И НЕ ЗавершениеРаботы Тогда
// Если пользователь нажал кнопку завершения работы во время использования формы выбора последние изменения настроек не будут сохранены.
ПриЗакрытииНаСервере();
КонецЕсли;
КонецПроцедуры Показать
(48) Вот код моей процедуры для таких форм:
Как раз с параметром для автоматического сохранения
Процедура ФормаСпискаВыбораПриСозданииНаСервере(Знач Список, Знач ЭлементФормыСписок, Знач Параметры, Знач АвтоматическоеСохранениеПользовательскихНастроек = Ложь) Экспорт
// Элементы.Список - основной реквизит с динамическим списком
ЭлементФормыСписок.РежимВыбора = Параметры.РежимВыбора;
Если Параметры.МножественныйВыбор <> Неопределено Тогда
ЭлементФормыСписок.МножественныйВыбор = Параметры.МножественныйВыбор;
КонецЕсли;
// обход автоматического сохранения пользовательских настроек для разных режимов
Если Параметры.РежимВыбора И Не ЗначениеЗаполнено(Параметры.КлючПользовательскихНастроек) Тогда
Параметры.КлючПользовательскихНастроек = "РежимВыбора";
Список.АвтоматическоеСохранениеПользовательскихНастроек = АвтоматическоеСохранениеПользовательскихНастроек;
КонецЕсли;
КонецПроцедуры
ПоказатьКак раз с параметром для автоматического сохранения
(51) Я пробовал так сделать сначала , но если Установить "АвтоматическоеСохранениеПользовательскихНастроек " в Истина , тогда оно грузит настройки с формы списка , если Ложь , тогда не грузит совсем . А мне нужны были отдельные для Формы "Списка" чтобы сохранялись и для формы "Выбора" чтоб сохранялись .
Иногда разные формы списка и выбора очень нужны, когда реализуется такой функционал, чтобы пользователь в форме выбора не мог создавать элементы, а только выбирать, и также, чтобы в форме выбора было минимальное количество колонок, чтобы не путать пользователя.
(49)
Если надо - делайте отдельные формы. Но по моему опыту - достаточно частый случай, когда одна форма достаточно хорошее решение.
Иногда разные формы списка и выбора очень нужны, когда реализуется такой функционал, чтобы пользователь в форме выбора не мог создавать элементы, а только выбирать, и также, чтобы в форме выбора было минимальное количество колонок, чтобы не путать пользователя.
Если надо - делайте отдельные формы. Но по моему опыту - достаточно частый случай, когда одна форма достаточно хорошее решение.
(52) Верю, что по вашему личному опыту - это частный случай, а вот по моему опыту не совсем частный. Если делаются новые документы в стандартных конфигурациях, особенно для упр.учета, где используются вновь созданные справочники, то там это широко используется. Очень многие пользователи хотят попроще, не хотят они кучу колонок и кучу кнопок, поэтому в таких случаях разные формы очень актуальны и нужны
У нас часто вместо списков для выбора открывались формы обработки, была в 7ке такая универсальная, выбор из таблицы значений. Работало оно так же медленно, как и любая форма динамического списка в 8ке.
Но в 7ке не было возможности создавать дополнительные поля программно на этой форме.
В 8ке такая возможность есть. В html насколько я поняла, осталась только эта возможность.
Плюс мобильное приложение компилируется под Андроид. Пока у меня нет понимания работы с ос андроид, но интересно, почему нельзя так же скомпилировать и приложение для линукса и виндоус? И еще я не понимаю, что "нам" это даст.
Простите за глупые вопросы:(
Но в 7ке не было возможности создавать дополнительные поля программно на этой форме.
В 8ке такая возможность есть. В html насколько я поняла, осталась только эта возможность.
Плюс мобильное приложение компилируется под Андроид. Пока у меня нет понимания работы с ос андроид, но интересно, почему нельзя так же скомпилировать и приложение для линукса и виндоус? И еще я не понимаю, что "нам" это даст.
Простите за глупые вопросы:(
Вроде нашел самый просто способ разделить настройки формы. ПриСозданииНаСервере
Если ФормаДокумента.Параметры.РежимВыбора Тогда
ЭтаФорма.КлючНазначенияИспользования = "РежимВыбора";
КонецЕсли;
После форма списка имеет свои быстрые отборы а формы выбора свои.
Если ФормаДокумента.Параметры.РежимВыбора Тогда
ЭтаФорма.КлючНазначенияИспользования = "РежимВыбора";
КонецЕсли;
После форма списка имеет свои быстрые отборы а формы выбора свои.
Это стандарты разработки 1С в плане интерфейса:
Область применения: управляемое приложение.
Рекомендуется не создавать формы выбора, а использовать генерируемые платформой по умолчанию.
Если, в соответствии с прикладной логикой, в форме выбора нужно предусмотреть особенный состав команд или колонок, то можно создать форму выбора, следуя рекомендациям
В командной панели формы рекомендуется размещать минимально необходимый набор команд для выбора, создания нового и поиска/отбора.
В часто используемых формах выбора из больших наборов данных рекомендуется делать область быстрого отбора/поиска.
Состав колонок следует оптимизировать для быстрого визуального поиска данных
Вопрос почему так рекомендуется.
В БСП 3.1.3 есть исключения, например, Справочник.Пользователи(то, что нашел навскидку). А так все в основном как и рекомендуется, либо форма выбора не задана, либо создана пользователем.
Область применения: управляемое приложение.
Рекомендуется не создавать формы выбора, а использовать генерируемые платформой по умолчанию.
Если, в соответствии с прикладной логикой, в форме выбора нужно предусмотреть особенный состав команд или колонок, то можно создать форму выбора, следуя рекомендациям
В командной панели формы рекомендуется размещать минимально необходимый набор команд для выбора, создания нового и поиска/отбора.
В часто используемых формах выбора из больших наборов данных рекомендуется делать область быстрого отбора/поиска.
Состав колонок следует оптимизировать для быстрого визуального поиска данных
Вопрос почему так рекомендуется.
В БСП 3.1.3 есть исключения, например, Справочник.Пользователи(то, что нашел навскидку). А так все в основном как и рекомендуется, либо форма выбора не задана, либо создана пользователем.
