Свой progressBar

[mazzy]

Цитата:

Сообщение от Андре

Есть последовательность длительных невложенных операций, которые выполняются при запуске пользователем некой периодической операции. Стандартный прогресс бар мне не понравился и где-то за 20 минут было сделано примерно следующее:

Сравни со стандартным


Но стандартный гарантировано работает в любой конфигурации.
Зато свой самописный завсегда кажется более крсивым/удобным...

[glibs]

Может ты и прав. Так всегда. Кажется, что новое лучше. Не зря же говорят, что лучшее — враг хорошего.

[Андре]

glibs,

Цитата:

прогресс-бар в плане времени врет, и не может не врать

Именно поэтому на моей картинке нет времени. Есть процент количества обработанных ячеек, есть процент обработанных записей и т.д.

[Андре]

mazzy,

Цитата:

Оценка времени делается в стандартном баре по первому прогресс-бару.
Первый прогресс-бар обычно отображает число выполненных задач
Второй и последующие показывают прогресс каждой задачи.

ОК. Конкретный пример.
Операция состоит из двух действий:
1) Открыть excel файл
2) Обработать на ней определенные ячейки (n штук).

Как я понимаю, ты предлагаешь вариант с двумя прогресс барами. Верхний состоит из 2 шагов, нижний из 0 и n на соответсвующих шагах.
Чем мне это не нравится:

1) На шаге 1 - нижний прогресс бар не играет своей роли, поскольку там всего один шаг. Был документ закрыт - стал открыт.
2) Открытие документа - 5 секунд, обработка (шаг 2) - 5 минут. После первого шага верхний прогресс бар покажет 50% хотя работа только началась

[Андре]

Цитата:

А вообще говоря советую посмотреть и тщательно проанализировать форму tutorial_progress. Особенно трехуровневые

Mazzy, я смотрел. Я этот прогресс-бар стандартный использую в сотне мест в своем модуле и отказываться от него не собираюсь. Еще я мерял траффик - в разных конфигурациях. Мне бы было спокойнее если бы я нашел проблемы с моим прогресс баром, но я их не обнаружил. Поэтому если ты видишь конкретные ляпы в такой реализации - буду рад услышать.

[Андре]

Цитата:

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

Сравни со стандартным
Вложение 2860

Но стандартный гарантировано работает в любой конфигурации.
Зато свой самописный завсегда кажется более крсивым/удобным...

Кстати, на мой взгляд, стандартный функционал с прогресс барами в количестве > 3 уже воспринимается с усилием. И это у меня, человека, который большое количество времени использует различные гаджеты. Поэтому делать форму состоящую из 5 прогресс баров, скачущих "хаотичным образом" одновременно для среднестатистического бух-ра я никогда рекомендовать не буду.

[glibs]

Т.е. исходной проблемой было таки вывести процент вместо времени? Я не пробовал, но верю в Аксапту. Думаю, что это на несколько минут работы.

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

Можно не устанавливать итог. А в тексте иногда можно написать что-то типа

Удаление записей в любимой таблице. Запись 39284 из 5847847.

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

[belugin]

я обычно, если проуесс состоит из нескольких фаз делаю два прогресс бара:

вверху по перечню фаз, внизу по обработке данных.

[glibs]

Цитата:

Сообщение от Андре

...
скачущих "хаотичным образом" одновременно
...

Ну зачем же? Я уже писал про программистов.

У меня сейчас "перед глазами" процесс импорта данных. Там два прогресс-бара. Верхний общий. Снизу идет уточняющий.

В первом отображается прогресс по всему процессу импорта. Во втором — по импорту записей конкретной таблицы. Первый медленно но уверенно ползет вперед. Второй постоянно дергается.

Кажется, есть еще примеры.

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

[Андре]

Цитата:

Т.е. исходной проблемой было таки вывести процент вместо времени?

Исходной задачей было usability - форма прогресса, которую будут адекватно воспринимать пользователи. Вывести процент вместо времени не проблема.

Цитата:

вверху по перечню фаз, внизу по обработке данных.

Я же вот здесь (Свой progressBar) пытался объяснить, что данный способ плох, когда длительность стадий различна.

[Lucky13]

По-моему у варианта, предложенного Андре есть преимущество, которого нет у стандартного прогресса - это не просто ход выполнения, но и протокол завершенных/незавершенных операций. Если операции независимые, то, в случае неудачи, можно установить вместо зеленой галочки красный крест и продолжить выполнение. После того как пользователь вернется, то увидит, что не прошла такая-то операция и ее надо повторить.

[Андре]

Цитата:

Ну зачем же? Я уже писал про программистов.

У меня сейчас "перед глазами" процесс импорта данных. Там два прогресс-бара. Верхний общий. Снизу идет уточняющий.

Я писал про 5 прогресс бара, а не про 2. Я сейчас открыл тот самый tutorial_progress и запустил вариант, который на скриншоте показал mazzy. Как я вижу ничего не изменилось и измениться не могло - проблема не в том, что стандартный прогресс бар работает не корректно - проблема в том, что человек устроен так, существует предел до которого он еще способен воспринимать вложенные процессы, отображаемые в таком виде. На цифре 5 предел, по моим наблюдениям, уже пройден.

[mazzy]

Цитата:

Сообщение от Андре

Я этот прогресс-бар стандартный использую в сотне мест в своем модуле и отказываться от него не собираюсь. Еще я мерял траффик - в разных конфигурациях. Мне бы было спокойнее если бы я нашел проблемы с моим прогресс баром, но я их не обнаружил. Поэтому если ты видишь конкретные ляпы в такой реализации - буду рад услышать.

Дык, я против что ли?
Наоборот, огромное спасибо.
Я только хотел сказать, что стоит сначала разобраться в стандартном функционале.

Про ляпы ниже.

Цитата:

Сообщение от Андре

Кстати, на мой взгляд, стандартный функционал с прогресс барами в количестве > 3 уже воспринимается с усилием. И это у меня, человека, который большое количество времени использует различные гаджеты. Поэтому делать форму состоящую из 5 прогресс баров, скачущих "хаотичным образом" одновременно для среднестатистического бух-ра я никогда рекомендовать не буду.

А зачем заставлять их скакать хаотичным образом?
Заполняй первый, потом второй потом третий. Заполненные бары означают полностью выполненную работу. Просто вместо процентов будет зеленая полоска.


Теперь ляпы.

Цитата:

Сообщение от Андре

1. Создаем форму

Форма всегда выполняется на клиенте. Т.е. будет гарантированный трафик между клиентом и сервером при каждом обращении к самодельному прогресс-бару.

Форма не создается в режимах: BenchmarkTool, веб-сессия, нет GUI (COM-коннектор, .NET-коннектор). Самодельный в этих режимах выдаст ошибки.

см. SysOperationProgress.allowFormSetup() // не забудь посмотреть в родителя
И вообще стоит подумать на тему, почему стандартный прогресс-бар сделали классом, а не формой.

Цитата:

Сообщение от Андре

2. На форме создаем методы:

А они всегда выполняются на клиенте

Цитата:

Сообщение от Андре

Метод отображающий прогресс операции:

void setPercent(int _idx, str _percent)
{
    FormListItem    item;
    ;
    item = listCtrl.getItem(_idx);


    if (WinApi::getTickCount() - timer > 500)
    {
        if (pulse)
            item.image(1);
        else
            item.image(2);

        pulse = !pulse;
        timer = WinApi::getTickCount();

       listCtrl.setItem(item);
       listCtrl.setText(item.idx(), _percent, 1);
       WinApi::updateWindow(element.hWnd());
    }

 
}

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

Отвечаем. В гребанном стандартном прогресс-баре отделена логика и представление. В стандартном сами хранимые числа получаются в одном месте, а отображаются они в другом. В самодельном конечно же все проще. Просто в самодельном прогресс-баре бизнес-логика и логика представления/отображения находятся в одном месте.

Я не говорю, что это плохо. В каких-то случаях это может быть и хорошо.
Но... Рано или поздно самодельный превратится в такой же сложный как и стандартный... А сил на самодельный будет потрачено немало.

Цитата:

Сообщение от Андре

Передали номер задачи + текст (сколько то там процентов).

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

Стандартный объединяет все прогресс-бары в одном окне.
Внутренний метод НЕ должен знать о внешнем стандартном прогрес-баре.
Он просто создает свой, и стандартный код подцепляет его полоску к уже существующим.

В самодельном будет несколько окон.
Опять же не говорю, что это плохо

Цитата:

Сообщение от Андре

Примерный способ использования:

// Показ формы
void run()
{
 progressBar = this.initProgressBar(['  Сохранение документа','  Захват значений', '  Учет настроек HQ консолидации','  Составление списка ячеек', '  Удаление старых значений', '  Открытие файла']);

Пробелы не спроста?

Цитата:

Сообщение от Андре

    this.openDocument();
    progressBar.setFinalStatus(0); // мы сделали первую задачу

    delete_from values where values.ReportId == report.ReportId;
    progressBar.setFinalStatus(1); // мы сделали вторую задачу

Общая таблица?
Если разные пользователи создают один и тот же отчет, то что они увидят?

Цитата:

Сообщение от Андре

    num =  this.total();
    cnt = 0;
    while select valuesSetup where valuesSetup.ReportType == report.ReportType
    {
        this.processCellSetup(valuesSetup.SheetName, valuesSetup.ExcelLabel);
        cnt++;
        progressBar.setPercent(2, strfmt('%1', cnt/num * 100) + '%');  // отображаем процесс длиетльной операции
    }
    progressBar.setFinalStatus(2);  // мы сделали третью задачу

Т.е. вызывающий метод должен считать проценты самостоятельно?
СУПЕРЛЯП: нет проверки на деление на ноль.

Цитата:

Сообщение от Андре

p.s. Я показал 99% полезного кода. 1% - если что-то забыл.

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

[Андре]

Цитата:

По-моему у варианта, предложенного Андре есть преимущество, которого нет у стандартного прогресса - это не просто ход выполнения, но и протокол завершенных/незавершенных операций.

Информацию о проблемных стадиях можно скидывать в инфолог. One more time - все можно сделать и стандартным функционалом. Все. Но бывают случаи, когда сложность задачи, решаемой пользователем становится очень большой и тогда, на первое место выходит юзабилити - задача предоставления пользователю сложной информации в простой и понятной для него форме. Настролько простой, чтобы ему не приходилось отвлекаться на мелочи, не относящиеся к основной задаче. Вот тогда данное решение может быть и поможет. И отображений неудачной операции прямо в списке (а не в инфологе) упростит пользователю жизнь. И надпись рядом - сделайте то-то, чтобы решить проблему. И кнопка, проблему решающую.
Согласен с тем, что в Аксапте таких задач менее 1%.

[mazzy]

Цитата:

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

По-моему у варианта, предложенного Андре есть преимущество, которого нет у стандартного прогресса - это не просто ход выполнения, но и протокол завершенных/незавершенных операций.

Т.е. и стандартный infolog в топку?

[Lucky13]

Цитата:

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

Т.е. и стандартный infolog в топку?

Так то два окна - progress и infolog, а то одно

[mazzy]

Цитата:

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

Так то два окна - progress и infolog, а то одно

И в самом деле...


И все-таки меня удивляют две вещи:
1. это конечно же общие таблицы.
2. то, что вы так настойчиво хотите сделать ОДНО окно.

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

Если будет ОДНО окно, то нужно протаскивать ссылку на него до самых внутренних методов и сторонних классов. А стандарт здорово облегчает жизнь. Достаточно создать новый прогресс, а стандарт сам прилепит к существующему окошку.

Неужели никогда не делали?
Ну, что-нибудь в виде

static void Job1(Args _args)
{
    SysOperationProgress progress1;
    SysOperationProgress progress2;
    int i;
    int total
;
    progress1 = SysOperationProgress::newGeneral('','',100);
    progress1.setText('Задача 1');
    progress1.update(true); // принудительно заставляем показать окно
    sleep(1000); // происходит какая-то длительная операция
    progress1.setCount(100); // 100% :)
    progress1.update(true); // принудительно заставляем показать окно

    total = 100000;
    progress2 = SysOperationProgress::newGeneral('','',total);
    progress2.setText('Задача 2');
    progress2.update(true); // принудительно заставляем показать окно
    for(i=0; i<total; ++i)
    {
        progress2.incCount();
    }
    progress2.update(true); // принудительно заставляем показать окно
    pause;
}

Только progress1 и progress2 находятся в разных методах и совершенно ничего не знают друг о друге...

[Андре]

Ура. Наконец то, конструктив.
mazzy, без обид, но я постоянно подчеркивал, что данная форма решение 1-2 частных задач. Это не универсальное решение. Это не замена стандартному прогресс бару. Это я к тому, что часть твоих справедливых замечаний, я не буду считать недостатком данного решения. Это не универсальный молоток и не серебрянная пуля.

Цитата:

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

Согласен. Это самый приемлимый для моего случая вариант. Если мой не заработает - так и сделаю.

Цитата:

Форма всегда выполняется на клиенте. Т.е. будет гарантированный трафик между клиентом и сервером при каждом обращении к самодельному прогресс-бару.

Знаю, мерил, дополнительного трафика не обнаружил. kashperuk хотел поиграться с данной идеей - может у него будут другие результаты.

Цитата:

Форма не создается в режимах: BenchmarkTool, веб-сессия, нет GUI (COM-коннектор, .NET-коннектор). Самодельный в этих режимах выдаст ошибки.

+1. Согласен, не красиво. Оправдываю себя тем, что функционал не работает не в web, ни через COM. Хотя, насчет того, что некрасиво, согласен.

Цитата:

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

Нет. Меня напрягает то, что он проблемно воспринимается пользователями, а не то, что он сложно устроен внутри. Давай разделять usability и внутреннюю реализацию. Последнее пользователя не волнует.

Цитата:

А сил на самодельный будет потрачено немало.

Согласен.

Цитата:

Стандартный объединяет все прогресс-бары в одном окне.

Действительно? Не знал. Спасибо, посмотрю.

Цитата:

Пробелы не спроста?

Просто реализация - quick and dirty. Быстрый способ разлепить строки и иконки.

Цитата:

Общая таблица?
Если разные пользователи создают один и тот же отчет, то что они увидят?

Это не отчет. Пользователи вообще ничего не увидят. На вход поступают Excel документы, в соответсвии с настроенными правилами(в том числе в самих excel-ях) из этих документов будут браться определенные ячейки, будут порождаться новые excel-ы.... Это не отчет. Это самописный аналог biztalk заточенный на обработку больших excel-документов (100Мб и более).

Цитата:

Т.е. вызывающий метод должен считать проценты самостоятельно?

Да. Писал, что форма не умная. Сама за меня ничего не делает. Это идея, а не решение.

Цитата:

СУПЕРЛЯП: нет проверки на деление на ноль.

Согласен, не красиво. Ошибки не будет - при num=0 цикл while select не выполнится ни разу. Хотя, согласен, что код выглядит неопрятно.

Цитата:

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

Еще раз, это не отчет. Для построения отчета достаточно одного прогресс бара - сколько осталось ждать - без деталировки по операциям. Пользователям эта информация все равно не интересна.

[Андре]

Цитата:

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

Честно? Стараюсь не делать. Сам расчет прогресс бара не требует. Пользователю, в 99% случаев достаточно одной полоски - сколько осталось.
Потребность во вложенных прогресс-барах возникает тогда, когда разработчик не уверен, что его операция доползет до "счастливого конца" и хочет получить информацию о том, на какой стадии все завалилось. Но для решения этой задачи есть другие механизмы(например, логирование) - демонстрировать кишки своего механизма пользователю необязательно.

[mazzy]

Цитата:

Сообщение от Андре

Если мой не заработает - так и сделаю.

А он еще и не работает?
А как же 20 минут?

Цитата:

Сообщение от Андре

Знаю, мерил, дополнительного трафика не обнаружил. kashperuk хотел поиграться с данной идеей - может у него будут другие результаты.

Угу. Особенно на большом числе итераций.

Цитата:

Сообщение от Андре

+1. Согласен, не красиво. Оправдываю себя тем, что функционал не работает не в web, ни через COM. Хотя, насчет того, что некрасиво, согласен.

Угу. И в пакетном режиме тоже не работает

Цитата:

Сообщение от Андре

Нет. Меня напрягает то, что он проблемно воспринимается пользователями, а не то, что он сложно устроен внутри. Давай разделять usability и внутреннюю реализацию. Последнее пользователя не волнует.

Вложение 2861
Только вместо ListView несколько контролов...
А если, как говорил glibs, Total не устанавливать, то останется только текст.

Цитата:

Сообщение от Андре

Это не отчет. Пользователи вообще ничего не увидят.

Вот так всегда...
На самом интересном месте выясняется, что не Иван Иванович, а Петр Петрович
не в среду, а в понедельник,
и не продал, а купил...

Какого черта беспокоится о юзабилити, если "Пользователи вообще ничего не увидят"?

Либо я полный тормоз.