Почему в отчетах не делают progress bar-ов?

[IKA]

В AOT-е только 3 стандартных отчета, использующих progress bar(ax2009). Почему в отчетах не делают progress bar-ов? Предполагается, что вся логика выполняется в классе, где собственно и должен быть градусник, а отчет сам по себе быстро выводит данные, поэтому progress тут не нужен?(хотя, это далеко не всегда так)

[EVGL]

Потому что для ускорения (?) ядро AX не делает запроса на число записей перед тем, как начать выводить их на экран.

[ddadream]

Если логика в классах, то все немного сложнее чем озвучено выше.

[mazzy]

Цитата:

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

Потому что для ускорения (?) ядро AX не делает запроса на число записей перед тем, как начать выводить их на экран.

готов согласиться с EVGL...
нет не только прогресс-бара, нет и общего числа страниц. (в отчете нельзя вывести "2 страница, всего 32").

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

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

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

[S.Kuskov]

Цитата:

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

нет не только прогресс-бара, нет и общего числа страниц. (в отчете нельзя вывести "2 страница, всего 32").

Справедливости ради. Для отображения количества страниц можно использовать встроенный display-метод pagesTotal(). Оговорюсь только, что посчитать количество страниц заранее (до отображения отчёта на экране) с помощью него действительно нельзя. Видимо, также для повышения производительности.

[George Nordic]

Цитата:

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

Видимо, также для повышения производительности.

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

С Уважением,
Георгий

[PavelX]

Цитата:

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

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

К сожалению по всей видимости так было только до АХ2009 (о которой говорит автор). В 2009 отчет целиком сперва строится а потом по вызову метода print() выводится на экран или принтер... И на момент отображения число страниц уже известно.

Например отчет CustTransList (Customer transactions) в AX2009 строится секунд 30 на демо данных пока не отобразится на экране, зато отобразившись он сразу позволяет перейти на последнюю 195-ю страницу.

[mazzy]

Цитата:

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

К сожалению по всей видимости так было только до АХ2009 (о которой говорит автор). В 2009 отчет целиком сперва строится а потом по вызову метода print() выводится на экран или принтер... И на момент отображения число страниц уже известно.

о, блин... точно!
испортили Аксапточку...

тогда Progress Bar нужен.

Цитата:

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

о, блин... точно!
испортили Аксапточку...

тогда Progress Bar нужен.

хочу напомнить, что в версии AX2011 больше нет встроенных отчетов (все отчеты только через Reporting services)
так что глядите вперед и не тратьте много время на архаизмы

[kornix]

Цитата:

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

В AOT-е только 3 стандартных отчета, использующих progress bar(ax2009). Почему в отчетах не делают progress bar-ов? Предполагается, что вся логика выполняется в классе, где собственно и должен быть градусник, а отчет сам по себе быстро выводит данные, поэтому progress тут не нужен?(хотя, это далеко не всегда так)

Мне кажется тут все дело в архитектуре: чтобы создать программную обработку для Report нужно создать класс-наследник от RunBaseReport, который наследник RunBaseBatch'а:

public abstract class RunBaseReport extends RunBaseBatch
{
    SysReportRun        reportRun;
    SysQueryRun         queryRun;
    Args                callerArgs;
    ...
}

RunBaseBatch наследник от RunBase:

public abstract class RunBaseBatch extends RunBase implements Batchable

а у RunBase в classDeclaration уже есть progress:

public abstract class Runbase extends Object implements SysSaveable, SysRunable
{
    boolean                 getLastCalled;
    boolean                 inGetSaveLast;
    boolean                 inCheckClose;
    boolean                 inPrompt;
    boolean                 isSwappedFromServer;
    boolean                 dialogCanceled;
    boolean                 inPromptUnpack;

    RunBaseDialogModify     dialogModify;
    RunbaseProgress         progress;

    SysSign                 sysSign;

    #macrolib.AviFiles

#if.never
    #define.CurrentVersion(1)
    #define.version1(1)
    #localmacro.CurrentList
    #endmacro
#endif
}

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

[George Nordic]

Дело в архитектуре, Вы правы. Пусть АОС шуршит с данными, а на клиента передаются результаты. Не думаю, что стоит добавлять синхронизацию этих процессов, чтобы побыстрее у АОСа запросить "ну что там, скоро еще"?

Хотя, если отчет на клиенте, это приемлемо... Не сильно затормозит создание отчета.

С Уважением,
Георгий

[George Nordic]

Progress Bug...