|
![]() |
#1 |
Участник
|
Сергей, при таком большом количестве вызовов уже вступает в действие общая тормознутость пользовательского кода. На фоне сотни тысяч вызовов методов setText() и incCount() несколько десятков раз обновление формы просто теряется.
updateInterval() тут уже не поможет. Можно написать дополнительный метод, который объединяет в себе изменение текста и кол-ва шагов - получим выигрышь около 50%. А можно перенести функциональность метода update() в свой код - т.е. вызывать обновление только по истечение интервала времени - в этом случае торможения практически не будет
__________________
Axapta v.3.0 sp5 kr2 |
|
|
За это сообщение автора поблагодарили: mazzy (5). |
![]() |
#2 |
Участник
|
Цитата:
Так каков вывод? этим классом нужно/можно/нельзя пользоваться? |
|
![]() |
#3 |
Участник
|
Запустил у себя тест:
X++: #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)); } если выключить один из методов: 6 сек. если выключить все методы: 0 сек. В данном случае длительность updateInterval(100) не влияет. Просто если его устанавливать, то окошко не показывается. |
|
![]() |
#4 |
Участник
|
Цитата:
Так каков вывод? этим классом нужно/можно/нельзя пользоваться?
а есть варианты? |
|
![]() |
#5 |
Участник
|
Цитата:
В данном случае длительность updateInterval(100) не влияет
|
|
![]() |
#6 |
Участник
|
Блин, сделайте нормальную обработку: Изменяйте что нибудь в базе и сравните.
Или сделайте вместо куцего ++j паузу хотя бы на 200 милисекунд sleep(200); Сравните. |
|
![]() |
#7 |
Участник
|
Варианты конечно есть.
Хорошо. Нужно. Идем дальше. Какие у этого класса проблемы (помимо "общей тормознутости пользовательского кода")? здесь прозвучало очень интересное сообщение о проблемах при переключении между компаниями? Такое действительно у кого-нибудь было? Какие еще проблемы есть? |
|
![]() |
#8 |
сибиряк
|
Мое предположение, у меня и было. Ситуация: создание нескольких сотен заказов, создание закупки по ним (это все в компании 1), и создание продажи по ним (в компании 2). Обработка по продажам и закупкам счетов на оплату. Для перехода между компаниями - changecompany. Дык вот через раз Аксапта "путалась" в какой компании она разносит. Причем путалась на ровном месте (то есть в различных частях кода). Пока не "отключил" прогресс в классах обработки именно для этой операции. После этого - ни одной ошибки. Так что претензии не к самому прогрессу, а к связке его работы в рамках нескольких компаний.
__________________
С уважением, Вячеслав. |
|
![]() |
#9 |
Участник
|
Цитата:
Сообщение от slava
![]() Мое предположение, у меня и было. Ситуация: создание нескольких сотен заказов, создание закупки по ним (это все в компании 1), и создание продажи по ним (в компании 2). Обработка по продажам и закупкам счетов на оплату. Для перехода между компаниями - changecompany. Дык вот через раз Аксапта "путалась" в какой компании она разносит. Причем путалась на ровном месте (то есть в различных частях кода). Пока не "отключил" прогресс в классах обработки именно для этой операции. После этого - ни одной ошибки. Так что претензии не к самому прогрессу, а к связке его работы в рамках нескольких компаний.
У нас тоже была такая фигня. Причем глюк вносил прогресс в SalesFormLetter - PurchFormletter Пришлось добавлять параметр, который позволял его отключать. |
|
Теги |
progress bar, sysoperationprogress, баг, бегунок, законченный пример, полезное, смена компании |
|
Опции темы | Поиск в этой теме |
Опции просмотра | |
|