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

[Андрей К.]

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

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

используется Ax 2009
спасибо

[MikeR]

Что сразу приходит в голову, так это запретить редактирование

actDate.status(RangeStatus::Locked);

или скрыть из показа в фильтре.

 actDate.status(RangeStatus::Hidden);

[d&m]

если у вас RU5 или старше посмотрите как такая задача решена на стандартной форме
Банк / Импортированная выписка.

Там и фильтры вынесены отдельно и филтр по сетке доуступен

[Андрей К.]

Цитата:

Сообщение от d&m

если у вас RU5 или старше посмотрите как такая задача решена на стандартной форме
Банк / Импортированная выписка.

Там и фильтры вынесены отдельно и филтр по сетке доуступен

что-то найти не могу, можно полный путь начиная с главного меню ?

[d&m]

Цитата:

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

что-то найти не могу, можно полный путь начиная с главного меню ?

это и есть полный путь, начиная с главное меню

Цитата:

Сообщение от d&m

Банк / Импортированная выписка.

название формы BankClientImportedStatement_RU
она была добавлена в ru5

[Андрей К.]

Цитата:

Сообщение от d&m

это и есть полный путь, начиная с главное меню


название формы BankClientImportedStatement_RU
она была добавлена в ru5

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

[d&m]

Цитата:

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

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

согласен, но реализация следующая:

невозможно перекрыть те фильтры, которые заданы в "вынесенных" фильтрах.

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

а вот добавить другой фильтр, в дополнение к "вынесенным" фильтрам,к примеру фильтр по контрагенту, я могу - это как раз и кажется мне правильным и удобным

[Maximin]

Если надо закрыть только расширенный фильтр, а фильтрацию по полям оставить, то можно попробовать закомментировать вызов super() в методе prompt() нужного datasource.

[Андрей К.]

Цитата:

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

Что сразу приходит в голову, так это запретить редактирование

actDate.status(RangeStatus::Locked);

или скрыть из показа в фильтре.

 actDate.status(RangeStatus::Hidden);

нужно не скрыть(заблочить) созданные ренджи а запретить возможность добавлять новые ренджи

Цитата:

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

Если надо закрыть только расширенный фильтр, а фильтрацию по полям оставить, то можно попробовать закомментировать вызов super() в методе prompt() нужного datasource.

годится! но конечно хотелось бы залочить возможность фильтровать из контекстного меню полей

[oip]

Как вариант, если надо чтобы только конкретная кнопка не работала, можно перекрыть метод task:

public int task(int _taskId)
{
    int ret;

    if (_taskId != 2837 && _taskId != 2844)
        ret = super(_taskId);

    return ret;
}

[mayk]

Андрей К.

public void executeQuery()
{
    if(this.queryRun())
    {
        this.queryRun().query().dataSourceNo(1).clearRanges();
        //TODO: восстановление фильтров из контролов на форме
    }    
    super();
}

d&m, #6

[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

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

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

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

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

[gl00mie]

Отсюда напрашивается вывод: не надо вообще делать контролы-фильтры на форме, за исключением, разве что, простейших случаев (журналы открытые/разнесенные/все) Потому что иначе получается неоправданно сложное и дорогое решение частной задачи, которая в системе уже решена в общем случае как минимум двумя способами: за счет расширенного фильтра и фильтра по grid'у.

[_scorp_]

Не помню где читал такое мнение:

Цитата:

Сделай систему, в которой сможет работать даже дурак, и только дурак захочет в ней работать.

Мне кажется, что это как раз этот случай. Просто обучайте пользователей, не программируйте.