![]() |
#11 |
Участник
|
Цитата:
Сообщение от Андре
![]() Я этот прогресс-бар стандартный использую в сотне мест в своем модуле и отказываться от него не собираюсь. Еще я мерял траффик - в разных конфигурациях. Мне бы было спокойнее если бы я нашел проблемы с моим прогресс баром, но я их не обнаружил. Поэтому если ты видишь конкретные ляпы в такой реализации - буду рад услышать.
Наоборот, огромное спасибо. Я только хотел сказать, что стоит сначала разобраться в стандартном функционале. Про ляпы ниже. Цитата:
Сообщение от Андре
![]() Кстати, на мой взгляд, стандартный функционал с прогресс барами в количестве > 3 уже воспринимается с усилием. И это у меня, человека, который большое количество времени использует различные гаджеты. Поэтому делать форму состоящую из 5 прогресс баров, скачущих "хаотичным образом" одновременно для среднестатистического бух-ра я никогда рекомендовать не буду.
Заполняй первый, потом второй потом третий. Заполненные бары означают полностью выполненную работу. Просто вместо процентов будет зеленая полоска. ![]() Теперь ляпы. Форма всегда выполняется на клиенте. Т.е. будет гарантированный трафик между клиентом и сервером при каждом обращении к самодельному прогресс-бару. Форма не создается в режимах: BenchmarkTool, веб-сессия, нет GUI (COM-коннектор, .NET-коннектор). Самодельный в этих режимах выдаст ошибки. см. SysOperationProgress.allowFormSetup() // не забудь посмотреть в родителя И вообще стоит подумать на тему, почему стандартный прогресс-бар сделали классом, а не формой. А они всегда выполняются на клиенте ![]() Цитата:
Сообщение от Андре
![]() Метод отображающий прогресс операции:
X++: 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()); } } Отвечаем. В гребанном стандартном прогресс-баре отделена логика и представление. В стандартном сами хранимые числа получаются в одном месте, а отображаются они в другом. В самодельном конечно же все проще. Просто в самодельном прогресс-баре бизнес-логика и логика представления/отображения находятся в одном месте. Я не говорю, что это плохо. В каких-то случаях это может быть и хорошо. Но... Рано или поздно самодельный превратится в такой же сложный как и стандартный... А сил на самодельный будет потрачено немало. Самодельный прогресс-бар может быть только один. Если внутри кто-то не знает о внешнем самодельном прогресс-баре, то на экране появится два окошка, три окошка и т.д. Стандартный объединяет все прогресс-бары в одном окне. Внутренний метод НЕ должен знать о внешнем стандартном прогрес-баре. Он просто создает свой, и стандартный код подцепляет его полоску к уже существующим. В самодельном будет несколько окон. Опять же не говорю, что это плохо ![]() Цитата:
Цитата:
Если разные пользователи создают один и тот же отчет, то что они увидят? Цитата:
Сообщение от Андре
![]() X++: 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); // мы сделали третью задачу СУПЕРЛЯП: нет проверки на деление на ноль. Если честно, то больше всего удивляет использование общей таблицы. Неужели у вас никогда не бывает такого, что разные пользователи делают один и тот же отчет? |
|
|
За это сообщение автора поблагодарили: Андре (5). |