как создать поле-критерий, как в sysQueryForm

[IKA]

Нужно добавить на диалог поле, вкотором пользователь может указать критерий как в sysQueryForm форме. То есть , допустим," поставщик1, поставщик2" .... или ," поставщик1 .. поставщик2" и тд (чтобы выбирались в этом поле только поставщики и только на них накладывать можно было условие) Я потом если этот критерий заполнен, могу добавить нужные таблицы в запрос и наложить это условие. Если критерий не заполнен - оставить запрос неизменным.
Как такое сделать?

[IKA]

Может, можно как-то стандартным запросом обойтись?
Изначально постановка такая:
Есть таблица А , есть таблица B (1одной записи в А может соответствовать несколько в B либо вообще в В не быть соответствующей записи).
Если пользователь накладывает ограничение на таблицу В, то в А надо выбрать соответствующие записи, причем, не задваивая , если в B для А две записи (т.е group by сделать).
Если пользователь не наложил критерий на B, то надо просто выбирать основываясь только по критериям, надоженным на А и соответствеенно, выбирать из А даже те записи, которых нету в B

[mazzy]

Цитата:

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

Нужно добавить на диалог поле, вкотором пользователь может указать критерий как в sysQueryForm форме. То есть , допустим," поставщик1, поставщик2" .... или ," поставщик1 .. поставщик2" и тд (чтобы выбирались в этом поле только поставщики и только на них накладывать можно было условие) Я потом если этот критерий заполнен, могу добавить нужные таблицы в запрос и наложить это условие. Если критерий не заполнен - оставить запрос неизменным.
Как такое сделать?

См. как сделано в форме со стандартными критериями SysQueryForm
Поле для критерия должно быть основано на типе Ragne.

Есть два способа реализации подобной штуки:
1. универсальный и сложный как в форме SysQueryForm. Нужно будет перехватывать методы Lookup, Validate и пр.
2. простой и понятный: создать новый тип на основе Range и добавить туда Relation, настроить внешний вид lookup-кнопок, ширину по-умолчанию и т.п.

Есть очень неприятная засада при реализации хотелки "добавить на диалог поле".
Очень легко реализовать одну сторону: пользователь вводит значение в поле, программист изменяет query.
Чертовски трудно реализовать обратную сторону: пользователь изменяет критерий в SysQueryForm, программист отображает значение в поле.

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

[S.Kuskov]

Цитата:

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

Изначально постановка такая:
...
Может, можно как-то стандартным запросом обойтись?

Стандартно - это изначально включить в запрос только таблицу A и научить пользователей в случае необходимости самостоятельно добавлять таблицу B (такая возможность присутствует в стандартном sysQueryForm).
Компромисс - это собрать изначально полный запрос A exists join B (именно exists, чтобы не делать group by) и потом анализировать задал ли пользователь фильтр по таблице B, если нет то программно удалять(отключать) источник данных B.

[IKA]

спасибо большое. насчет

Цитата:

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

- они не настолько смелы, чтобы добавлять таблицы самим в запросе. То есть, если я там оставлю только таблицу A, а таблицу B буду добавлять в ручную + сделаю поле на диалоге как Вы описали, то вероятность, что они догадаются в запрос навернуть таблицу B вручную оч мал. (если я правильно поняла проблему описанную Вами).

[Maximin]

Я не скажу, что первый "универсальный" метод настолько уж сложен.
Из SysQueryForm нужно выдрать не так уж много методов, обеспечивающих нужный функционал.
Правда, если в искомой таблице будут контейнерные поля (фин. аналитики), то все равно придется лезть в стандартную форму DimensionsLookup, т.к. иначе фильтроваться при lookup аналитики не будут соответственно своему номеру, но это мелочи.
Тем более, если есть возможность ограничить создаваемую функциональность "заточив" её на работу только с определенной таблицей (как в этом случае - только "Поставщики").
Не вижу также проблем при изменении запроса при использовании SysQueryForm. Сложнее, если там начнут использоваться extended query ranges. Но, думаю, налагающий такой критерий человек, знает, что делает.

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

Сложнее бывает, когда где-то в настройках есть преднастроенный запрос, и требуется "наложить " его на текущий в форме с сохранением текущих ranges и прицепленных datasources. Но это уже совсем другая история. Что должно получиться при этом надо подробно описывать в постановке. Приходилось писать и такое.

[Владимир Максимов]

Проблема в том, что твое условие невозможно реализовать без программирования. Точнее, без создания принципиально разных Query.

Условие 1: Если наложено ограничние на B, то запрос имеет вид

select A exists join B

Условие 2: Если не наложено никаких ограничений на B, то запрос имеет вид

select A

Если бы каждой записи таблицы A, соответствовала хотя бы одна запись таблицы B, то можно было бы обойтись одним запросом с exists. Но поскольку у тебя могут существовать записи A, которым не соответствует ни одной записи B, то так не получится.

В принципе, если по таблице B накладывается ограничение только по одному полю, то логично вывести это поле (точнее EDT по которому построено это поле) на форму диалога отдельно от Query. А потом, если там что-то указано, достраивать Query дополнительным DataSource.

Чтобы что-то дальше советовать, необходимо уточнение. Речь идет о классе-наследнике от RunBase, RunBaseButch, RunBaseReport? Какая версия Axapta?

Как добавить поле на форму диалога в RunBase можно посмотреть в классах Tutorial_RunBase*. А вот как достравивать запросы, тут несколько сложнее, хотя не так, чтобы очень. Просто есть некоторые тонкости...

[mazzy]

Цитата:

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

Сложнее бывает, когда где-то в настройках есть преднастроенный запрос, и требуется "наложить " его на текущий в форме с сохранением текущих ranges и прицепленных datasources.

Хм... А в чем сложность?

Просто никогда не надо "править" element.Query()
всегда надо работать с element.QueryRun().Query().

А какие хитрости имеются в виду?