Динамические контролы в отчете основанные на display-методе

[petr]

Можно ли в Аксапте создавать динамические контролы в отчете основанные на display-методе (не на поле таблицы)?

Суть проблемы: Я узнаю сколько столбцов будет в отчете уже во время выполнения (на основе выбора пользователя в диалоговом окне). Следовательно я добавляю необходимое мне количество столбцов уже во время выполнения (в методе init() отчета). Если контрол основан на поле таблицы, то все просто:

control = element.design().sectionName(#Detailed).addRealControl(tableId, fieldId);

Если же контрол основан на display методе, который определен в отчете?

Я пытаюсь делать так:
control = element.design().sectionName(#Detailed).addRealControl(tableId, fieldId);
control.dataMethod("custBalanceAge");
Но все равно отчет пытается отразить значение в поле таблицы.

[oip]

А не проще не создавать динамически, а скрывать динамически? Или это невозможно в данной задаче?

[db]

addDisplayControl()

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

[oip]

И еще, там есть метод addRealDisplayControl(). Не поможет? Думаю поможет. Но ИМХО лучше скрывать поля, чем добавлять.

[petr]

To oip.
Именно необходимо создавать динамически, потому что скрывать можно когда есть checkBox и поле либо отображается, либо нет (я такое часто использую). В моей же задаче я не знаю заранее даже примерное количесто, оно зависит от того на сколько подпериодов большой период (м.б. на 2 или на 10). Пользователь выбирает в диалоге количество подпериодов (может поставить любое количество) и на каждый необходимо создать свой столбец.

To db.
Про addDisplayControl(). Сейчас попробую.
Про OLAP. В принципе согласен, хотя в нашей задаче может такой подход и не подойдет. И вообще я пока с OLAP не сильно разобрался, т.ч. приходиться пользоваться стандартными средствами.

[petr]

To All.
Да. Да!!! Есть такой метод addRealDisplayControl().
Сейчас проверю, как все заработает и пойду к окулисту.

[oip]

Цитата:

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

В моей же задаче я не знаю заранее даже примерное количесто, оно зависит от того на сколько подпериодов большой период (м.б. на 2 или на 10). Пользователь выбирает в диалоге количество подпериодов (может поставить любое количество) и на каждый необходимо создать свой столбец.

Может быть тогда лучше Excel?

[db]

Цитата:

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

выбирает в диалоге количество подпериодов (может поставить любое количество) и на каждый необходимо создать свой столбец.

OLAP в чистом виде

[mazzy]

Цитата:

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

...оно зависит от того на сколько подпериодов большой период (м.б. на 2 или на 10). Пользователь выбирает в диалоге количество подпериодов (может поставить любое количество)...

Я опять со своим брюзжанием.
Но я КАТЕГОРИЧЕСКИ против такого программисткого подхода к решаемым задачам.

Пользователь НЕ МОЖЕТ поставить ЛЮБОЕ количество.
Колчество чего бы то ни было более-менее полезного для пользователя ОГРАНИЧЕНО рамками восприятия этого пользователя.

Как проверить утверждение petr?
Есть два проверочных вопроса по сути:
1. Может ли пользователь поставить 1млн. "подпериодов"
2. Может ли пользователь поставить число <1?

Есть еще один проверочный вопрос по форме:
3. Сколько столбцов может уместится на странице, чтобы пользователь еще мог прочитать информацию? (Должен ли пользователь склеивать несколько листов?)

И сразу выясняется, что утверждение petr не является истинным.

Мало того, готов утверждать, что:
Pert просто не разобрался в задаче И не знает что именно надо пользователю от этого отчета. Вместо того, чтобы разобраться petr переносит проблему на пользователя - на тебе, гад пользователь, 30...50...60.. столбцов, разбирайся.

Уважаемые программисты, пожалуйста, не используйте такой принцип!
Уважаемые программисты, пожалуйста, разбирайтесь в задаче.


Что касается вопроса petr...
Petr - скрывать намного легче, чем добавлять. Я бы остановился на том, что бы скрывать.
Однако, если вы хотите именно добавлять, то разберитесь как формируются финансовые отчеты (они формируются именно динамически).
О финансовых отчетах здесь http://axapta.mazzy.ru/lib/ledger_report/
addDisplayControl() - это только начало. Вам придется управлять заголовком, шириной, точностью, форматом вывода, итогами и прочими свойствами (а могли бы просто задать из в свойствах AOT)

[kvg6]

Цитата:

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

OLAP в чистом виде

А если расчетные поля из 2-х и более таблиц, то лучше грузить в Excel

[petr]

Ok. Предлагаю вашему вниманию полную постановку задачи. Может действительно я избрал не лучший подход к ее решению.

Есть отчеты в "Расчетах с поставщиками" и в "Расчетах с клиентами" которые называются в меню "Список распределения по срокам". (Путь РП/РК - Отчеты - Статус). Они выводят сальдо по клиенту в разрезе периодов, когда проводка сформировалось или когда ее надо оплатить. Периодов жестко 6. И они все одинаковой длины (которую можно изменять).
Я же хочу сделать аналогичный отчет, в котором количество периодов и их продолжительность будет настраиваться в определенной таблице, называемой "График". Т.е. бухгалтер настраивает себе несколько удобных графиков: например 2 интервала: текущий год и до текущего года, либо 4 интервала: месяц назад, два месяца, три месяца и больше чем три месяца. В диалоге отчета бухгалтер выбирает по какому графику от будет анализировать задолженность клиента или поставщику. Понятно, что бухгалтер знает, что если он задаст много интервалов для графика - то отчет отмаштабируется и будет нечитаемым.
Но я не хочу ограничивать бухгалтера максимальным колиеством периодов. В принципе если предложенный oip метод хорошо сработает (а я думаю, что так и будет) я получаю хороший отчет.

По-моему я нашел лучший выход, но если кто-то предложит более грамотное решение, я с удоволтьствием его выслушаю (прочитаю)

Спасибо всем откликнувшимся.

[petr]

Все получилось. addRealDisplayControl() работает замечательно.

[EVGL]

Рекомендую посмотреть на:
\Classes\RTax25Report_RegisterTrans\buildReportDesign
\Reports\RTax25RegisterTrans

[oip]

Насколько я помню, этот отчет использует табличку TmpAccountSum. Туда тоже "динамически" будете поля добавлять? Или по-другому будете все заполнять?

PS В такой постановке задачи я сильно сомневаюсь в необходимости программного добавления контролов. Никакому бухгалтеру, ИМХО, не потребуется больше, например, 6 периодов. 6 мало? Ну сделайте 10. Или 12. Опять мало? Думаете бухгалтер больше захочет?

[petr]

To EVGL.
Да у меня теперь подобное и получается. Только у меня все проще, т.к. все типы Real и соответственно не надо сильно мудрить.
Вообще то вся проблема в том, что я забыл про метод
addRealDisplayControl("custBalanceAge"),
а пытался использовать связку:
control = element.design().sectionName(#Detailed).addRealControl(tableId, fieldId);
control.dataMethod("custBalanceAge");
Хотя раньше точно помню, что уже использовал. Просто забыл и попал в тупик.

[petr]

А из-за этого разгорелась такая активная дискуссия.

[mazzy]

Цитата:

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

Вообще то вся проблема в том, что я забыл про метод ********** а пытался использовать***********

И я об этом.
ДОБАВИТЬ можно различными способами.
При ДОБАВЛЕНИИ нужно учесть массу параметров.
Когда программист ДОБАВЛЯЕТ что-либо динамически, то, как правило, он решает НЕ ИЗНАЧАЛЬНО поставленную задачу.
В нашей области практически не бывает задач в которых присутствует формулировка "произвольное число".

Вам предлагается другая парадигма:
1. Выясните максимально возможное значчение.
2. ЕСЛИ количество столбцов меньше 30 ТОГДА
2.1. создайте эти столбцы руками в отчете, установите все необходимые свойства в AOT
2.2. из кода только скрывайте ненужное (и может быть меняйте названия колонок)
3. ИНАЧЕ
3.1. Ваши столбцы не уместятся на бумаге. Попробуйте решить задачу по-другому
4. КОНЕЦЕСЛИ

[petr]

To Mazzy и oip

Вообщее можно ограничиться 7 периодами. Вообще задача сейчас стоит так:
1-ый период: менее месяцы
2-ой период: от 1 мес. до 2-х
3-ый период: от 2-х до 3-х.
4-ый период: от 3-х до полугода
5-ый период: от полугода до года
6-ой период: от года до 2-х
7-ой период: более 2-х лет.
Итак можно даже создать таблицу с семью полями, добавить их статически в отчет, зашить в код интервалы для каждого периода и отчет полностью удовлетворяет бухгалтерию.

Но!
1. А если им захочется иметь отчет с периодами 1 года, 2 года и более (т.е. более общий)?
2. А если прийдет новый бухгалтер или фин. директор, который сдвинет границы периодов?
3. А если этот отчет использовать на другом предприятии, у фин. директор которого использует другие рамки периодов?

Для того, чтобы решить эти 3 вопроса, т.е. создать отчет, который полностью настраивается их интерфейса программы и без дополнительного программирование дорабатывается под любой возможное предприятие и желание бухг. (или фин. директора), то необходимо:
1. Сделать настраиваемый график (спец. таблицы, хранящая границы периодов)
2. Сделать в данной таблице возможность задания нескольких графиков с произвольным числом периодов
3. В диалоге отчета дать возможность пользователю выбирать по какому графику разбивать задолженность клиента (дебиторку) (или поставщика)
4. В отчете использовать только стандартные Аксаптовские методы, чтобы в случае превышения возможной ширины отчет автоматически масштабировался и умещался на листе.

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

[mazzy]

как скажете.

[Delfins]

na schet - ispolzovat ili net takoj podhod (addControl) - to u menja pohozee bilo delo - raspechatka tarifnogo plana (record = {period,ref,price} ).. taze gruppirofka po ref-group... to est tot zhe samij OLAP.. no bilo legche samomu dobovljat kontroli na otchet - ne tak to eto i tjazhelo...

PS: ja za metod "prosche i legche", a ne "tankom po muravjam"