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

2 vandalsvq.  Вот кусок кода и картинка

Нашлась минутка, пофиксил два бага и сделал одну хотелку (не форумную).

3.04.016 от 23.03.10 г.
- Исправлены некоторые выявленные ошибки при работе со справочниками, у которых длина кода = 0.
- Исправлена ошибка, при которой, в момент нажатия Ctrl+Enter не вызывалась кнопка по умолчанию назначенная для формы. Решение: для атрибута на котором установлено табличное поле назначается формула «Форма.Заголовок(“”,1);» (если не назначена программистом).
- При нажатии кнопки на командной панели, при невозможности выполнения процедуры будет выдано сообщение пользователю с именем процедуры.

Вот в процессе подготовки к публикации на инфостарте решил сделать небольшой пример с использованием справочника "Контрагенты". Необходимые классы (в том числе доп. кроме поставщика), длл, обработка и инструкция приложены. Вроде все батарейки приложены.

Есть мысль по переделке коллекции Отбор.

На текущий момент (кто не знал) Отбор = это созданный и заполненный АссоциативныйВектор из 1С++.
Лично меня не устраивает что:
1. Нельзя создавать "усложненные" условия. Т.е. с комбинацией ИЛИ-И-НЕ и т.д.
2. Нельзя задавать условия с повторяющимися полями. Например: Наименование | НачинаетсяС | А ИЛИ Наименование | НачинаетсяС | Б.
3. Нельзя ставить отборы на значения реквизитов у элементов если это документы, справочники и т.д.
Конечно п.3 = снижение производительности, поэтому его необходимость для меня под вопросом. Кому надо и через ПриПолученииЗапроса справится. Но все-таки мысль есть мысль.

Интерфейс (программиста и пользователя) в принципе известен (смотрите в сторону 8.2). Но как оставить обратную совместимость и реализовать данный интерфейс.
Была мысль такая:
1. Реализую новый интерфейс класса Отбор с возможностью группировки. Называю его РасширенныйОтбор (+ признак ИспользоватьРасширенныйОтбор), и если программист использует РасширенныйОтбор то тогда стандартный не работает.
Плюсы: обратная совместимость, наличие двух механизмов с разным уровнем сложности в понимании и использовании (иногда хорошо для неподготовленных пользователей)
Минусы: неочевидность отборов. Можно запутаться что ты используешь.
2. Реализую интерфейс аналогичный расширенному отбору, в него по умолчанию добавляю все поля страндартного отбора чтобы через Отбор.Наименование можно было до них достучаться. Далее пользователь/программист сам все настраивает.
Плюсы: обратная совместимость
Минусы: изменение интерфейса может привести к неработоспособности механизмов вектора используемых программистами ранее (если такие были конечно). Изменение пользовательского интерфейса без возможности использовать старый.

Режимы без обратной совместимости даже не рассматриваются.

В планах на перспективу ближайших пары месяцев.
Кому что больше нравится, высказывайтесь.
Кстати вторым эшелоном пойдет объект УсловноеОформление. Но для него надо измененный отбор.

В примере автора для справочника Контрагенты при свернутом окне вылазит горизонтальный скроллер ТП ТабличноеПолеАлфавит. Реально его как-то отключить?

2 vandalsvq.
По поводу отборов. Мне первый вариант больше нравиться. Да, можно запутаться, но если проблемы с Расширенным Отбором, то используешь Обычный. Но расширенный отбор нужен иначе не всегда можно отобрать только то, что нужно, и приходится придумывать разные из вращения.

У меня хотелка: добавить сохранение текущей строки и колонки табличного поля при влучении-выключении отборов.

vandalsvq писал(а) 25. Марта 2010 :: 10:16:


можно еще также в журнале документов, реквизит "Вид документа"  в значение отбора добавлять не все все виды документов, а только те которые относятся к журналу