Имеется форма (много похожих форм) и панель фильтров. На панели располагаются эдиты, чекбоксы, комбобоксы, радиокнопки и т.п.
Совокупность заполнения этих контролов дает фильтр в условие "WHERE" SELECT-запроса.
При чем, некоторые контролы имеют приоритет (если заполнен, то другие контролы игнорируются)
Имеются зависимые контролы (чекбокс + эдит).
В итоге, по нажатию кнопки все контролы проверяются на заполнение и клеится фильтр.
Ну, вот в общих словах.

Теперь вопрос.
Существует ли готовое решение или паттерн для подобного хозяйства?
Инструмент разработки - C++ Builder. Поэтому проектирование превратилось в анти-паттерн "Магическая кнопка".

Почему TFrame?

Я имел в виду, подход, который упростит формирование фильтра для SELECT

iscrafm
поищите в инете, был раньше PuterSoft SDK.

Видел уже похожую реализацию - встречается довольно часто.
Как я понял, можно неограниченно увеличивать сложность фильтра (динамически добавляя всё новые условия).
Плюсы - возможность создавать гибкие и разнообразные фильтры
Минусы - малая скорость взаимодействия с пользователем

Сейчас уже реализованный интерфейс (куча этитов и комбобоксов) и сотрудники к нему привыкли.

Программист-ЛюбительМогу поделиться идеей реализации. При разработке приложения оказалось, что подавляющее большинство контролов, задающих условия выбора, являются комбобоксами и списками. Т.е. экозитка типа групп опшионов с эдитами около некоторых оказалась не востребована. Вернее там, где она есть, сделана конкретная кодировка "в лоб".

А вот все остальное привелось к следующему виду:

1. Имеется словарь пользовательских источников данных - VIEW, табличные FUNC, процедуры PROC

2. Имеется реестр пользовательских форм разных видов
* вложенный грид
* карточка (содержит на вкладках вложенный грид с набором фильтрующие контролов, оределяющих WHERE его источника данных)
* табличная форма (окно, содержащее грид с набором фильтрующие контролов, оределяющих WHERE его источника данных
* структура с деревом слева и таблицей (для корневых узлов) либо карточкой (для обычных узлов) справа

3. Имеется реестр всех фильтрующих контролов - комбо и списков.

Каждый контрол содержит баунд столбец, один или более столбцов для наглядного вывода и скрытый столбец условий, задающий кусочек WHERE, который будет использоваться для фильтрации источника, с которым будет связан фильтрующий контрол.

Несколько фильтрующих контролов, связанных с одним и тем же источником в пределах пользовательской формы, соединяются через AND.

Для процедур фильтрующие контролы обеспечиват подстановку параметров.

Для табличных функций фильтрующие контролы обеспечиват подстановку параметров или куски WHERE.
Надо обмозговать :)

softwarerПлохо. Сразу отсекаются потребности умных пользователей.
В большей массе умные пользователи встречаются редко, поэтому делается под основную массу.

softwarerПросто кошмар. Надеюсь, они хоть визуально дисейблятся.
С визуализацией более или менее (приоритетные с жирным лейблом). Пользователи привыкли.

Собственно, что дали - с тем и пришлось работать. Идея не моя - теперь приходится разгребать готовое. По началу я был в шоке от проекта. Коментариев ноль (абсолютно). Все имена контролов типа Edit1, ..., Edit105... Оформления кода просто не существует...

softwarerПаттерн - в любом случае начать следует с того, что отделить "формирователь фильтров", "условие фильтрации" и GUI, который эти условия формирует. То есть, к примеру, желание изменить интерфейс с "панель с кучей всего" на "листбокс фильтруемых полей и справа панелька с контролами для этого поля" не должно быть заметно для "собственно фильтров".
Так что от кучи контролов не уйти (на переделку сотни интерфейсов времени нет).
--
Идея с алгеброй - супер! Вот отвертку по-больше найду и прикручу тригонометрию к SQL