12.03.2010, 14:02 | #1 |
Участник
|
как создать поле-критерий, как в sysQueryForm
Нужно добавить на диалог поле, вкотором пользователь может указать критерий как в sysQueryForm форме. То есть , допустим," поставщик1, поставщик2" .... или ," поставщик1 .. поставщик2" и тд (чтобы выбирались в этом поле только поставщики и только на них накладывать можно было условие) Я потом если этот критерий заполнен, могу добавить нужные таблицы в запрос и наложить это условие. Если критерий не заполнен - оставить запрос неизменным.
Как такое сделать? Последний раз редактировалось IKA; 12.03.2010 в 14:05. |
|
12.03.2010, 14:17 | #2 |
Участник
|
Может, можно как-то стандартным запросом обойтись?
Изначально постановка такая: Есть таблица А , есть таблица B (1одной записи в А может соответствовать несколько в B либо вообще в В не быть соответствующей записи). Если пользователь накладывает ограничение на таблицу В, то в А надо выбрать соответствующие записи, причем, не задваивая , если в B для А две записи (т.е group by сделать). Если пользователь не наложил критерий на B, то надо просто выбирать основываясь только по критериям, надоженным на А и соответствеенно, выбирать из А даже те записи, которых нету в B |
|
12.03.2010, 14:31 | #3 |
Участник
|
Цитата:
Сообщение от IKA
Нужно добавить на диалог поле, вкотором пользователь может указать критерий как в sysQueryForm форме. То есть , допустим," поставщик1, поставщик2" .... или ," поставщик1 .. поставщик2" и тд (чтобы выбирались в этом поле только поставщики и только на них накладывать можно было условие) Я потом если этот критерий заполнен, могу добавить нужные таблицы в запрос и наложить это условие. Если критерий не заполнен - оставить запрос неизменным.
Как такое сделать? Поле для критерия должно быть основано на типе Ragne. Есть два способа реализации подобной штуки: 1. универсальный и сложный как в форме SysQueryForm. Нужно будет перехватывать методы Lookup, Validate и пр. 2. простой и понятный: создать новый тип на основе Range и добавить туда Relation, настроить внешний вид lookup-кнопок, ширину по-умолчанию и т.п. Есть очень неприятная засада при реализации хотелки "добавить на диалог поле". Очень легко реализовать одну сторону: пользователь вводит значение в поле, программист изменяет query. Чертовски трудно реализовать обратную сторону: пользователь изменяет критерий в SysQueryForm, программист отображает значение в поле. Поэтому очень многие реализовавшие эту хотелку запрещают пользователям юзать SysQueryForm. Что приводит к другим проблемам... В общем, лучше научить пользователей юзать стандартный функционал. |
|
12.03.2010, 14:39 | #4 |
Участник
|
Цитата:
Компромисс - это собрать изначально полный запрос A exists join B (именно exists, чтобы не делать group by) и потом анализировать задал ли пользователь фильтр по таблице B, если нет то программно удалять(отключать) источник данных B. |
|
12.03.2010, 14:59 | #5 |
Участник
|
спасибо большое. насчет
Цитата:
пользователь изменяет критерий в SysQueryForm, программист отображает значение в поле.
Последний раз редактировалось IKA; 12.03.2010 в 15:21. |
|
15.03.2010, 17:06 | #6 |
NavAx
|
Я не скажу, что первый "универсальный" метод настолько уж сложен.
Из SysQueryForm нужно выдрать не так уж много методов, обеспечивающих нужный функционал. Правда, если в искомой таблице будут контейнерные поля (фин. аналитики), то все равно придется лезть в стандартную форму DimensionsLookup, т.к. иначе фильтроваться при lookup аналитики не будут соответственно своему номеру, но это мелочи. Тем более, если есть возможность ограничить создаваемую функциональность "заточив" её на работу только с определенной таблицей (как в этом случае - только "Поставщики"). Не вижу также проблем при изменении запроса при использовании SysQueryForm. Сложнее, если там начнут использоваться extended query ranges. Но, думаю, налагающий такой критерий человек, знает, что делает. Пишу, т.к. мои консультанты очень любят настраиваемые разного рода критерии, так что эту собаку ел уже неоднократно. Сложнее бывает, когда где-то в настройках есть преднастроенный запрос, и требуется "наложить " его на текущий в форме с сохранением текущих ranges и прицепленных datasources. Но это уже совсем другая история. Что должно получиться при этом надо подробно описывать в постановке. Приходилось писать и такое.
__________________
Жизнь прекрасна! Если, конечно, правильно подобрать антидепрессанты... |
|
15.03.2010, 20:53 | #7 |
Участник
|
Проблема в том, что твое условие невозможно реализовать без программирования. Точнее, без создания принципиально разных 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*. А вот как достравивать запросы, тут несколько сложнее, хотя не так, чтобы очень. Просто есть некоторые тонкости... |
|
15.03.2010, 21:34 | #8 |
Участник
|
Цитата:
Просто никогда не надо "править" element.Query() всегда надо работать с element.QueryRun().Query(). А какие хитрости имеются в виду? |
|
|
|