Какие проблемы у SysOperationProgress?

[AndyD]

Сергей, при таком большом количестве вызовов уже вступает в действие общая тормознутость пользовательского кода. На фоне сотни тысяч вызовов методов setText() и incCount() несколько десятков раз обновление формы просто теряется.
updateInterval() тут уже не поможет.

Можно написать дополнительный метод, который объединяет в себе изменение текста и кол-ва шагов - получим выигрышь около 50%.
А можно перенести функциональность метода update() в свой код - т.е. вызывать обновление только по истечение интервала времени - в этом случае торможения практически не будет

[mazzy]

Цитата:

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

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

Понял. Спасибо.

Так каков вывод? этим классом нужно/можно/нельзя пользоваться?

[mazzy]

Запустил у себя тест:

#Define.LoopCount(100000)
static void Job6(Args _args)
{
    SysOperationProgress pBar = new SysOperationProgress();
    int time = timeNow();
    int i, j;
    ;
    pBar.setCaption("Обработка");
    pBar.setTotal(#LoopCount);
    //pBar.updateInterval(100);
    for (i = 0; i < #LoopCount; i++)
    {
        pBar.setText(strfmt("Операция № %1", i));
        //pBar.incCount();
        j++;
    }
    info(strfmt("Прошло: %1 сек.", timeNow() - time));
}

Со всеми методами: 14 сек
если выключить один из методов: 6 сек.
если выключить все методы: 0 сек.

В данном случае длительность updateInterval(100) не влияет.
Просто если его устанавливать, то окошко не показывается.

[ivas]

Цитата:

Так каков вывод? этим классом нужно/можно/нельзя пользоваться?

конечно нужно
а есть варианты?

[ivas]

Цитата:

В данном случае длительность updateInterval(100) не влияет

имхо она вообще не влияет на скорость работы ну может +-1%

[mazzy]

Цитата:

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

имхо она вообще не влияет на скорость работы ну может +-1%

Блин, сделайте нормальную обработку: Изменяйте что нибудь в базе и сравните.
Или сделайте вместо куцего ++j паузу хотя бы на 200 милисекунд sleep(200);
Сравните.

[mazzy]

Цитата:

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

конечно нужно
а есть варианты?

Варианты конечно есть.
Хорошо. Нужно. Идем дальше.

Какие у этого класса проблемы (помимо "общей тормознутости пользовательского кода")?

здесь прозвучало очень интересное сообщение о проблемах при переключении между компаниями?
Такое действительно у кого-нибудь было?

Какие еще проблемы есть?

[slava]

Цитата:

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

здесь прозвучало очень интересное сообщение о проблемах при переключении между компаниями?

Мое предположение, у меня и было. Ситуация: создание нескольких сотен заказов, создание закупки по ним (это все в компании 1), и создание продажи по ним (в компании 2). Обработка по продажам и закупкам счетов на оплату. Для перехода между компаниями - changecompany. Дык вот через раз Аксапта "путалась" в какой компании она разносит. Причем путалась на ровном месте (то есть в различных частях кода). Пока не "отключил" прогресс в классах обработки именно для этой операции. После этого - ни одной ошибки. Так что претензии не к самому прогрессу, а к связке его работы в рамках нескольких компаний.

[Logger]

Цитата:

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

Мое предположение, у меня и было. Ситуация: создание нескольких сотен заказов, создание закупки по ним (это все в компании 1), и создание продажи по ним (в компании 2). Обработка по продажам и закупкам счетов на оплату. Для перехода между компаниями - changecompany. Дык вот через раз Аксапта "путалась" в какой компании она разносит. Причем путалась на ровном месте (то есть в различных частях кода). Пока не "отключил" прогресс в классах обработки именно для этой операции. После этого - ни одной ошибки. Так что претензии не к самому прогрессу, а к связке его работы в рамках нескольких компаний.

Именно так !

У нас тоже была такая фигня. Причем глюк вносил прогресс в SalesFormLetter - PurchFormletter

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