DAX09: некорректное отображение полоски ProgressBar

[Perc]

Цитата:

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

И первый вызов progress.incCount() увеличивает его до 2 (а это 50% из 4-х).

Да нуу. Не может быть.. Если у меня тотал 4, то чтобы проити весь прогресс, я должен всего 3 incCount сделать? Ломаете мне мир) нужна проверка)

[sukhanchik]

Цитата:

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

Да нуу. Не может быть.. Если у меня тотал 4, то чтобы проити весь прогресс, я должен всего 3 incCount сделать? Ломаете мне мир) нужна проверка)

Судя по скриншотам - это так. И поэтому собственно "зависание" на 100%-ах

[Perc]

Цитата:

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

Судя по скриншотам - это так. И поэтому собственно "зависание" на 100%-ах

Эти скриншоты могу сравнить с надписями на заборе) Всем верить чтоле?
Я открыл код которых мильён с прогрессом. И там все норм - с ноля начинается. Тотал - 4, и значит надо 4 итерации чтобы заполнить прогресс.
А что случилось у автора темы не понятно.. толи он нам чего-то не договаривает между точек толи... Ну можем сойтись на том, у него то как раз RunbaseProgress начинается с единицы.. кастомизация)

[oleggy]

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

У меня 4 итерации. Начиная с 1 по 4 включительно. Нумерация в цикле с 1 по 4 включительно. Я же код не зря предьявил.
Вопрос почему на первой итерации уже было 50% прогресса?

[mazzy]

Цитата:

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

Вопрос почему на первой итерации уже было 50% прогресса?

вам уже ответили:

Цитата:

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

Ответ-то вроде лежит на поверхности. Судя по индикатору (если не исследовать внутренности кода) - внутренний счетчик прогресс-бара начинается с 1 (а если полезть изучать код, то это можно будет увидеть). И первый вызов progress.incCount() увеличивает его до 2 (а это 50% из 4-х).

если так хотите вручную управлять прогрессом, то воспользуйтесь методом progress.setCount()

а чтобы увидеть значение счетчика внутри прогресса - методом progress.getCount_RU()

[Perc]

Цитата:

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

У меня 4 итерации. Начиная с 1 по 4 включительно. Нумерация в цикле с 1 по 4 включительно. Я же код не зря предьявил.
Вопрос почему на первой итерации уже было 50% прогресса?

Я скопировал ваш код к себе в джоб Акс4. Добавил sleep(1000) и update(true). И картинка была идеальная на клиенте. 1 - 25%, 2 - 50% и тд.
Воспользуйтесь отладчиком, посмотрите.

[oleggy]

Перевел весь свой код в просто джоб. Что бы предметно дебажить.

    Counter             countRows, numRows;
    Counter             strFrom = 1, strTo = 4;
    RunbaseProgress     progress = new RunbaseProgress();
    #AviFiles

    void progressUpdate(Counter _curr, Counter _num)
    {
        str percent = strFmt("%1%", decRound((_curr / _num) * 100, 2));

        progress.setText(strfmt("@SYS66083", _curr, _num, percent));
        progress.incCount();
        //progress.update(true);
    }
    ;

    progress.setCaption("Импорт");
    progress.setAnimation(#AviUpdate);

    numRows = strTo - strFrom + 1;
    progress.setTotal(numRows);

    startLengthyOperation();

    for (countRows = 1; countRows <= numRows; countRows++)
    {
        progressUpdate(countRows, numRows);
        sleep(2000);
    }

    endLengthyOperation();
}

Цитата:

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

вам уже ответили:
а чтобы увидеть значение счетчика внутри прогресса - методом progress.getCount_RU()

К сожалению нет такого метода (DAX2009).
Поэтому смотрел через дебаг. Нумерация у меня идет с нуля.
Перед первым выполнением progress.incCount() значение progress.oprProgress.lapProgress равно 0.
Как вы видете после запуска джоба я вижу только три изменения окна прогресс бара. ТРИ.

Но если я раскомменчу progress.update(true) отображает корректно ЧЕТЫРЕ окна. Четыре итерации.
Т.е. 1 - 25%, 2 - 50%, 3 - 75%, 4 - 100%.

Я почему тему поднял, просто хотелось понять:
1. почему ТАК криво отображается прогресс бар?
2. после какого оператора происходит обновление окна Импорт? Какой метод это делает? Или после какого метода это происходит?

[Perc]

Цитата:

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

2. после какого оператора происходит обновление окна Импорт? Какой метод это делает? Или после какого метода это происходит?

Очень забавно получилось) перевернули местами incCount и setText и картинка перевернулась)
Видимо необходимость в перерисовке окна вычисляется каким то алгоритмом инициируемым при вызове любой из этих функций. От чего этот момент зависит точно - надо дотошно код смотреть. Но фокус получился в том что перерисовка произошла после первой функции в итерации. А на вызове второй алгоритм сказал - к черту, только что обновляли.
Как сделать чтобы текст и движок корректно синхронизировались даже сходу не скажу. Update(true) в общем случае не рекомендуется, если случай большого количества мелких итерации.

[mazzy]

Цитата:

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

Уже весь извелся. Одни маты остались.

бедняжка

Цитата:

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

К сожалению нет такого метода (DAX2009).

добавьте

//mazzy 13.12.2019: по образцу getTotal()
public int64 getCount(int _idx = 1)
{
    if (oprProgress)
        return oprProgress.getCount_RU(_idx);
    else if (oprProgressEmbedded )
        return oprProgressEmbedded.getCount_RU(_idx);
    else if ( oprProgressServer )
        return oprProgressServer.getCount(_idx);
    else
        return 0;
}

Цитата:

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

Поэтому смотрел через дебаг.

Серьезно? Не, это не спортивно.

Цитата:

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

Нумерация у меня идет с нуля.
Перед первым выполнением progress.incCount() значение progress.oprProgress.lapProgress равно 0.
Как вы видете после запуска джоба я вижу только три изменения окна прогресс бара. ТРИ.

Но если я раскомменчу progress.update(true) отображает корректно ЧЕТЫРЕ окна.

как у меня на скриншотах ниже. так?

Цитата:

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

Я почему тему поднял, просто хотелось понять:
1. почему ТАК криво отображается прогресс бар?
2. после какого оператора происходит обновление окна Импорт? Какой метод это делает? Или после какого метода это происходит?

Хорошие вопросы. И хорошая настойчивость. Спасибо.

Заглянул внутрь. Вспомнил.
Заодно вспомнил про тему (Не)перерисовка окна клиента AX 2009 при длительных операциях - вариант решения
Поностальгировал.

Вернемся к вопросам.

Прогресс-бар - это GUI-форма.
Обновление GUI-формы - дело относительно не быстрое.
Даже перерисовка консольного прогресс бара занимает время.
Нормальные прогресс-бары не отрисовывают КАЖДОЕ изменение прогресса, а обновляют по таймеру, чтобы отрисовка не выполнялась дольше, чем полезная работа.

Вот и в Аксапте у метода update есть параметр force:
если сказать force=true, то update перерисует форму в обязательном порядке
если сказать force=false, то update будет перерисовывать только когда пройдет некоторое время с предыдущей отрисовки.



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




ГЛАВНОЕ: метод update(false) НЕ перерисовывает окно при каждом изменении.

теперь собственно что происходит:
1.
методы setText() и incCount() унутре себя вызывают update(false)
следовательно возможна ситуация, когда на первом методе окно будет перерисовно, а на втором - не будет.

так и получается рассогласованное изображение окна.
но вполне согласованое состояние внутри.

2.
когда вы явно вызываете update(true), то окно будет принудительно перерисовано. И каким бы оно ни было нарисовано в предыдущих строках, здесь оно будет нарисовано в согласованном состоянии.

3.
попробуйте тест на очень много значений с принудительной отрисовкой и с отрисовкой по умолчанию.
замерьте время выполнения.
скорее всего вы удивитесь как много времени уходит на отрисовку прогрессБара.
мало того, и на обслуживание этой счетчиков тоже тратится время и дополнительно напрягается сборщик мусора.

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

4.
что делать:
не ориентироваться на точные значения прогресс-бара.
выводить текст для того, чтобы примерно представлять где мы находимся (даты обрабатываемых проводок, код товаров в алфавитном порядке и тп)
увеличивать updateInterval (рекомендую 5-10 секунд)

5.
что можно улучшить:
в стандартной аксапте катастрофически не хватает метода, который меняет одновременно и текст, и счетчик.
такой метод обычно и добавляют на проектах.