DAX 4.2 Фильтры, возникающие в диалоге автоматически

[Qaz Qwerty]

Делаю отчет в котором много datasources.
Каждый из них в диалоге создает по умолчанию свой фильтр (range) и форма выглядит огромной.
Как сделать, чтобы не было этих фильтров? Все равно никто не будет их использовать.

[Андре]

RunBase.showQueryValues(), если я правильно помню, отвечает за это. Скорее всего вы его перекрыли и возвращаете true.

[slava]

как уже правильно написл Андре, RunBase.showQueryValues(). Если он будет возвращать false, фильтры будут невидимы в диалоге, но и недоступны для ввода.

[coolibin]

Цитата:

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

как уже правильно написл Андре, RunBase.showQueryValues(). Если он будет возвращать false, фильтры будут невидимы в диалоге, но и недоступны для ввода.

Возможно, будет достаточно сделать, чтобы не showQueryValues(), а showIndexFields() возвращал false. А дипазоны выборочно можно сделать невидимыми и проще - с помощью свойства QueryBuildRange.status = RangeStatus::Hidden

PS: в отчете свойство Range = Hide

[S.Kuskov]

А можно немного оффтопика? Всегда интересовал один вопрос.

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

[mazzy]

Цитата:

Сообщение от S.Kuskov

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

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

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

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

[S.Kuskov]

Цитата:

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

программный lookup к каждому фильтру ...

А разве lookup не зависит от ExtendetDataType контрола? Мне так видится напротив реализация разных лукапов для одной и той же колонки грида - посложнее будет.

Самым сложным моментом мне сдесь представляется оперативная синхронизация значений фильтров в диалоге и на форме выбора. Т.е. необходим программный modified

Цитата:

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

кроме того, непременно надо было бы давать возможность управления видимостью и доступностью

Вот про права пользователя я забыл. Спасибо. Но ведь это тоже вопрос решаемый.

Осталось только победить лень

[mazzy]

Цитата:

Сообщение от S.Kuskov

А разве lookup не зависит от ExtendetDataType контрола? Мне так видится напротив реализация разных лукапов для одной и той же колонки грида - посложнее будет.

А там не EDT контрола, а тип для критерия.

Если EDT контрола позволяет вводить максимум 20 символов, то никаким образом в него нельзя будет ввести длинный критерий (хотя бы в 200 символов).
В окошке ввода критериев используется тип Criterias, а не EDT

Цитата:

Сообщение от S.Kuskov

Самым сложным моментом мне сдесь представляется оперативная синхронизация значений фильтров в диалоге и на форме выбора. Т.е. необходим программный modified

Это как раз не проблема. Модифицируйте QueryRun. Он везде отобразится.

Цитата:

Сообщение от S.Kuskov

Осталось только победить лень

Не надо.
Разберитесь как работает форма критериев. Посмотрите на ее методы. Подумайте - а оно нужно?

Вернемся к первоосновам:
1. dialog - простой класс для работы с простыми динамически создаваемыми диалогами.
2. если нужен сложный диалог (в том числе со сложной логикой), то лучше нарисовать отдельное окно, объявить его диалогом и... (см. методику работы с диалогами)

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

[S.Kuskov]

Цитата:

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

А там не EDT контрола, а тип для критерия

Это всё понятно. Хочешь сложный фильтр - используй форму выбора. А простой можно и непосредственно на дилоге задать.

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

Цитата:

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

dialog - простой класс для работы с простыми динамически создаваемыми диалогами

Ну так никто и не предлагает возлагать работу по реализации этой функциональность на конечных потребителей калсса dialog. Нужно научить dialog самостоятельно всё это дело прокручивать. Справляется же он сам с отображением критериев. Так и пусть будет для программистов помимо showQueryValues() ещё и например alowEditQueryValues().

Цитата:

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

если в простом диалоге появится возможность вводить критерии непосредственно, то придется такую же возможность вводить и в диалоги-отдельные-окна.

а что такое 'диалоги-отдельные-окна'?

[mazzy]

Цитата:

Сообщение от S.Kuskov

Это всё понятно. Хочешь сложный фильтр - используй форму выбора. А простой можно и непосредственно на дилоге задать.

КАТЕГОРИЧЕСКИ ПРОТИВ.

Представим, что я тупой пользователь.
Я вбиваю фильтр в эту глупую программу... И вдруг она не дает записать последний символ моего фильтра?
Я как тупой пользователь ищу инструкцию, нажимаю кнопку Выбор, перевбиваю свой фильтр заново...
При этом постоянно матерюсь и чертыхаюсь.

Нет уж! Если давать возможность вводить, то единообразно. Как и в критериях.

Цитата:

Сообщение от S.Kuskov

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

Вот-вот. Видел такое неоднократно. Поубивал бы.

Во-первых, пользователь не может ввести нормальные критерии через звездочку (а потом удивляемся почему пользователи такие тупые)
Во-вторых, значения в этих "часто используемых фильтрах" не совпадают с теми, что используются в критериях
В-третьих, не запоминаются (поскольку разработчики тупо не используют xSaveLast)
В-четвертых, ...
В-пятых, ...
...
В-мамнадцатых.

Интерфейс должен быть предсказуем. А для этого он должен быть единообразным.

Цитата:

Сообщение от S.Kuskov

а что такое 'диалоги-отдельные-окна'?

Э-э-э...
М-м-м...

В общем...
Черт, не ожидал я такого поворота разговора.

Пример - диалог, который выскакивает при создании заказа на продажу, заказа на закупку, заказа на производство.

[Qaz Qwerty]

Цитата:

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

как уже правильно написл Андре, RunBase.showQueryValues(). Если он будет возвращать false, фильтры будут невидимы в диалоге, но и недоступны для ввода.

У меня отчет наследован от RunBaseReport, так что может это там что то перекрыто, но в любом случае - заработало! Спасибо все большое!