Lookup: Combobox и String - когда можно использовать методы контролов

[kitty]

D365
Нужно было сделать 2 фильтра на форме.
1) по: "All" + набору значений стандартного enum.
Сделала как видела в стандарте - забиваю значения Combobox в init формы, а потом selectionChange контрола (то есть, по сути, метод на коде форме) вызываю executeQuery. Прекрасно работает.

2) Для второго фильтра нужно было сделать кастомный query (через SysTableLookup).
Я сделала контрол combobox и переписала метод lookup контрола ... Но вот только он не вызывается(дебагила). ...Cделала контрол типа String и переписала его метод lookup(), но та же проблема, код . В итоге сделать контрола String и переписала onLookup eventHandler ...
Работает

Теперь мучают вопросы
a) Почему второй фильтр с query невозможно сделать, если контрол типа Combobox
a) Как понять, когда можно использовать методы контролов, а когда только eventHandler?

Спасибо

[Владимир Максимов]

Не скажу за 365, но в младших версиях ComboBox - это объект для отображения фиксированных, заранее известных списков из Base Enum (или набранных вручную в init).

Соответственно, перекрытие LookUp для них никакого смысла не имеет. Здесь просто не может быть динамического формирования списка элементов. Список элементов определен заранее и не меняется на протяжении жизни объекта. Насколько я понимаю, по той причине, что обычно это очень небольшой список из нескольких элементов. Что здесь фильтровать-то?

С другой стороны, объект String - это обычно ссылка на внешний справочник. И вот тут уместно предоставить возможность накладывать фильтр на этот внешний справочник. Т.е. можно перекрыть lookUp

Это ответ на первый вопрос про отличие ComboBox. Про eventHendler - не в курсе. Это уже специфика 365

[Logger]

Делали что-то подобное, правда для 2012-й. Но возможно сработает и для 365-й.
https://github.com/KozlovPavel677/AxTunedCombobox

Основное использование - добавить к енуму в фильтре дополнительное значение (как правило All). Но в общем случае можно резвиться как хочешь. Добавлять, убирать итп.

[TasmanianDevil]

Для того, чтобы не загаживать AOT паскудными дублями Enum'ов с доп. значением "Все", делали в свое время класс-обертку, которому в init() формы передавались потребные контролы ComboBox и их Enum'ы. Он хранил в себе Map (int, class) для соответствия ID контрола и вложенной map(int, int) соответствия индекса элементов тек. контрола числовым значениям элемента используемого enum. Потом в modified() контрола из такого класса легко вытаскивалось, что выбрано

[michel1971]

есть стандартные классы
\Classes\SysFormEnumComboBox
\Classes\DialogEnumComboBox
прикрутить в них "Все" не составляет труда

[sukhanchik]

Один из вариантов решения исходной задачи по добавлению значения "Все" в енум для целей фильтрации

Интерфейс правда из 2012 (просто под рукой), однако эта же идея применима и к D365FO (с поправкой на паттерны конечно - если они дают так сделать).

Каждый фильтр помещается в свою группу (Group), у которой FrameOptionButton = Check
Ну и в коде производится анализ - если флажок стоит на группе - значит фильтр применим. Если нет - значит неприменим. Является весьма неплохой альтернативой енумам.
Из минусов:
- Необходимо использовать как минимум 2 переменные (на группу и на сам фильтр)
- Много места "отъедает" на форме, если сравнивать с обычным полем.
- Для установки фильтра надо сделать 2 клика - на группу и уже на поле
Плюсы:
- Универсальность для любого типа критерия, в т.ч. для енумов со значащими нулевыми значениями
- Эффектная визуализация (сразу очевидно - что если поле недоступно - значит фильтр в нем не задан), причем за счет ядра