Можно ли запретить пользовательский фильтр на форме?

[gl00mie]

Цитата:

Сообщение от Андрей К.

поскольку все необходимые пользователю фильтры были "вынесены" на форму, нужда в кнопке с воронкой отпала (в том числе и фильтр по выделенному полю)

Это вам сами пользователи сказали, или вы за них решили? А если появится продвинутый пользователь, который хорошо знаком с расширенным фильтром, который, может, знает про такие вещи, как SysQueryRangeUtil, про возможность сохранения запросов и последующего их применения, то он будет вынужден мучиться с вашими кургузыми контролами на форме, которые дергают executeQuery() после каждого изменения, вместо того, чтобы дернуть его один раз, когда установлены все необходимые фильтры, сужающие выборку?

Цитата:

Сообщение от Андрей К.

Точнее необходима защита от дурака , чтоб пользователь не мог фильтровать как ему захочется, кроме как используя вынесенный на форму функционал фильтрации

По-моему, вы пытаетесь прикрыть, скажем так, кривоватую реализацию тех фильтров, которые вы вынесли в виде контролов на форму; обычно при корректной их реализации никакая "защита от дурака" не нужна. Корректная же реализация заключается в следующем:

• фильтры применяются на executeQuery() до super(), причем как к form_ds.query(), так и к form_qr.query() (он же form_ds.queryRun().query()), если последний существует (при самом первом вызове executeQuery() до super() соотв. QueryRun еще не инициализирован);
• при изменении значения фильтра дергается research(), а не executeQuery(), чтобы не слетали пользовательские фильтры по другим полям.
• если значение фильтра по полю задано, то удалить все другие фильтры по этому полю и потом сделать фильтр со статусом RangeStatus::Locked, если же не задано, задать SysQuery::valueUnlimited() со статусом RangeStatus::Open, чтобы пользователь мог использовать поле в расширенном фильтре.
• при необходимости реализовать в классе управления формой (или у вас вся логика обработки фильтров реализована прямо на форме?) интерфейс SysSaveable и сохранять значения фильтров между вызовами формы.

В общем ничего сложного, и, главное, никакой насущной необходимости отрубать возможность расширенной фильтрации.

[mazzy]

полностью согласен.

хочу только добавить:

Цитата:

Сообщение от gl00mie

В общем ничего сложного, и, главное, никакой насущной необходимости отрубать возможность расширенной фильтрации.

сложности есть.
если пользователь изменит фильтр нормальными средствами (Ctrl+F3), то нужно корректно отобразить этот фильтр в контролах на форме (иначе будет очень досадное расхождение, которое приводит к очень досадным недоразумениям с пользователями).

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

кроме того, бывают стандартные формы (зачастую из локализации), которые страдают болезнью контролы-как-фильтры.

в результате и возникает задача "запретить".
хотя конечно лучше переделать так, чтобы пользователи могли использовать расширенные фильтры.

[gl00mie]

Цитата:

Сообщение от mazzy

если пользователь изменит фильтр нормальными средствами (Ctrl+F3), то нужно корректно отобразить этот фильтр в контролах на форме (иначе будет очень досадное расхождение, которое приводит к очень досадным недоразумениям с пользователями). но программисты часто выставляют на форме не критерий (с запятыми, звездочками, восклицательными знаками и пр.), а одно контрол с одним значением. Даже если программист выставит на форму критерий, то часто не занимаются обновлением критериев из query. и т.д.

Эта задача в общем случае, по-моему, не решается: даже если на форме сделать для фильтрации контрол не для одного-единственного значения поля, а контрол на базе range, пользователи через расширенный фильтр (Ctrl-F3) ведь могут задать несколько range'ей для одного и того же поля, причем таких, которые вместить в один range на форме просто не получится из-за совокупной длины условий фильтрации. Не добавлять же из-за этого на форму новые контролы для фильтрации с той лишь целью, чтобы корректно отобразить все то, что пользователь навводил через форму расширенного фильтра? Тут все-таки нужен разумный компромисс: хочешь пользоваться расширенным фильтром - пожалуйста, но не жди, что все условия фильтрации, введенные с его помощью, будут визуально отражены в контролах-фильтрах, вынесенных на форму.

[mazzy]

Цитата:

Сообщение от gl00mie

Не добавлять же из-за этого на форму новые контролы для фильтрации с той лишь целью, чтобы корректно отобразить все то, что пользователь навводил через форму расширенного фильтра?

пользователь всего-лишь должен понимать, что контролы на форме НЕ соответствуют реально действующему фильтру.

чтобы дать ему понять не обязательно делать обратный парсинг.
достаточно задисейблить контролы.

но ведь и этого не делается.