Как избежать отмены фильтра на форме

[DSan]

Имеется форма, которая, в частности, показывает количество доступной номенклатуры на складе. Она вызывается из формы по созданию строк в складском журнале. При открытии формы с доступной номенклатурой, в методе run() накладывается фильтр на склад, указанный в вызывающей форме. Но если вдруг пользователь нажимает кнопку сброса фильтра, наложенный фильтр сбрасывается, и становится доступна номенклатура с других складов. Собственно вопрос, как сделать так, чтобы этот фильтр нельзя было сбросить? Может накладывать его надо в другом месте, или восстанавливать в каком-то другом методе?

[longson]

Если я правильно помню, то вам необходимо наложить фильтр в методе excuteQuery() на datasource. Тогда даже кнопка сброса фильтра изначально тоже станет недоступной.

[ZVV]

а может лучше диналинк таки прикрутить к складу? красивее будет, мне кажется.

ну либо, как отметил longson, пробивайте фильтр на executeQuery(), только проверьте, что нет других условий на склад, иначе будет "или". Должно быть только одно условие на склад - ваше. Так как executeQuery() выполняется собственно в момент выполнения запроса, то перебить этот фильтр уже никто не сможет.

[СибирскийКлещ]

Цитата:

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

а может лучше диналинк таки прикрутить к складу? красивее будет, мне кажется.

На какую таблицу ?
Диналинк при просмотре остатков срабатывает на InventSum по буферу InventJournalTrans ...
В обоих склада нету в принципе - он в при-joinen-ом InventDim.

Вывести в форму отображения остатков галчонку "фильтр по складу", по ее значению/изменению в executeQuery() у InventDim либо добавлять залоченный range по складу из соотвествующего InventDim'у от InventJournalTrans либо не добавлять.

И овцы сыты, и волки целы

[AndyD]

При сбросе фильтра используется запрос, хранящийся в ds.Query(), т.е. то, что добавлено в _ds.QueryRun().Query() теряется.
Для формирования фильтров используйте метод Init() датасорса - он вызывается один раз при его создании.

[ZVV]

Цитата:

Сообщение от СибирскийКлещ

На какую таблицу ?

Сорри, я условие невнимательно протитал похоже...
Да, в стандарте такое сложновато будет так сделать.


Можно сделать это всё и в ините датасорса, но тогда нужно блокировать этот range().

[ZVV]

Если на инит датасорса, то выглядит так:

public void init()
{
    QueryBuildRange qbr;
    ;

    super();

    qbr = this.query().dataSourceNo(1).findRange(fieldNum(InventLocation, InventLocationId));

    if (! qbr )
        qbr = this.query().dataSourceNo(1).addRange(fieldNum(InventLocation, InventLocationId));
    qbr.value(queryValue("ля-ля-ля"));

    //qbr.status(RangeStatus::Locked);
}

Наличие qbr.status(RangeStatus::Locked); не позволит пользователю изменить этот рэндж или добавить новый такой же.

В принципе то же самое можно сделать и на executeQuery(), но этот вариант не считается "бест практис":

public void executeQuery()
{
    QueryBuildRange qbr;
    ;

   qbr = this.query().dataSourceNo(1).findRange(fieldNum(InventLocation, InventLocationId));

    if (! qbr )
        qbr = this.query().dataSourceNo(1).addRange(fieldNum(InventLocation, InventLocationId));
    qbr.value(queryValue("ля-ля-ля"));

    //qbr.status(RangeStatus::Locked);

    super();
}

И тоже будет работать (2 AndyD). Проверял на 3.0. При сбросе фильтра тоже остаётся это условие.
Как ни странно (я тоже не ожидал), оба этих варианта оказались с точки зрения пользователя одинаковые.
(Либо я что-то не заметил)

[mazzy]

Цитата:

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

Наличие qbr.status(RangeStatus::Locked); не позволит пользователю изменить этот рэндж или добавить новый такой же.

Точно.

[mazzy]

Цитата:

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

public void init()
{
    qbr = this.query().dataSourceNo(1).findRange(fieldNum(InventLocation, InventLocationId));

    if (! qbr )
        qbr = this.query().dataSourceNo(1).addRange(fieldNum(InventLocation, InventLocationId));

Вместо такой тягомотной конструкции лучше писать

SysQuery::findOrCreateRange(this.query().dataSourceTable(tablenum(InventLocation)),fieldNum(InventLocation, InventLocationId));

Кстати, обратите внимание, что dataSourceNo - источник очень трудноуловимых runtime ошибок, если датасоры с форме поменяются. Лучше юзать tablnum...

[ZVV]

Цитата:

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

Кстати, обратите внимание, что dataSourceNo - источник очень трудноуловимых runtime ошибок, если датасоры с форме поменяются. Лучше юзать tablnum...

Абсолютно согласен, всегда так и пишу.
Это просто был тестовый пример, совсем не на это.

А SysQuery::findOrCreateRange - действительно интерестно, не знал (или забыл). надо запомнить

[petergunn]

Цитата:

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

Вместо такой тягомотной конструкции лучше писать

SysQuery::findOrCreateRange(this.query().dataSourceTable(tablenum(InventLocation)),fieldNum(InventLocation, InventLocationId));

Для DAX 4.0 используя Global::findOrCreateRange_W можно пойти еще дальше в направлении компактного написания кода и тогда

qbr = this.query().dataSourceNo(1).findRange(fieldNum(InventLocation, InventLocationId));

    if (! qbr )
        qbr = this.query().dataSourceNo(1).addRange(fieldNum(InventLocation, InventLocationId));
    qbr.value(queryValue("ля-ля-ля"));

    //qbr.status(RangeStatus::Locked);

будет выгдядеть как:

...
findOrCreateRange_W( this.query().dataSourceTable(tablenum(InventLocation)),
                     fieldNum(InventLocation, InventLocationId),
                     queryValue("ля-ля-ля") ).status(RangeStatus::Locked);
...

[AndyD]

2 zvv
Что будет срабатывать - это понятно. Только executeQuery() срабатывает каждый раз, когда запрос отправляется на сервер, в том числе и при фильтрации или сортировке. Будут избыточные вызовы.

[ZVV]

Цитата:

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

2 zvv
Что будет срабатывать - это понятно. Только executeQuery() срабатывает каждый раз, когда запрос отправляется на сервер, в том числе и при фильтрации или сортировке. Будут избыточные вызовы.

Согласен.
Просто изночально думалось, что сброс фильтра не будет оставлять это, а оказалось оставляет.
Это раз.
А второй прикол, который я заметил в этом случае такой:
Когда нажимешь сброс фильтра, то код, добавляющий рэндж на executeQuery(), отрабатывает и добавляет ещё один (прикольно, если не делать findOrCreate ).
А если просто делать "фильтр" и выполнять запрос ещё раз, то код на executeQuery() как бы отрабатывает, но на действующую кверю это не "возымевает" никакого действия - все рэнджи остаются как в фильтре! Вот так-то.

[AndyD]

Тут надо помнить про такую вещь - пользовательские фильтры добавляются на _ds.QueryRun().Query(). При вызове пользовательского фильтра или при программном вызове research() во вновь создаваемый QueryRun передается _ds.QueryRun().Query() (в отличие от простого вызова ExecuteQuery() - там передается _ds.Query()).
По-этому, если делать какие-либо изменения в _ds.Query() внутри метода ExecuteQuery(), то есть вероятность рассогласования с пользовательским фильтром.

[DSan]

Какая дискуссия получилась, не ожидал. Буду осмысливать написанное, спасибо