Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

ProgreessBar, подвисание проги [D7, XP]

Страницы: < 1 2 3 >
timekiller © (2010-03-12 10:39:00)
Уважаемые знатоки! У меня проблема такая:
Есть форма, на ней Progressbar (Gauge, как его назвали)...
Но толк от него пропадает, когда программа попросту занята 15минутным выполнением задачи (разбор гигабайтного XLS, например) - В заголовке появляется некое (Не отвечает), форма перекрашивается в белый цвет и всё приехали.....

Вопрос такой, для тех кто сталкивался: Как оживить Progressbar во время выполнения программы?
Алгоритм растет, что будет когда программа будет выполнятся 2 часа, допустим?....

Демо (2010-03-13 17:48:00) [21]

> Игорь Шевченко © (13.03.10 17:14) [20]
> > 3. Пользователь запускает длительные расчёты и идёт спать.
> > Результаты расчёта понадобятся только на следующий день.
> > Самый правильный вариант

Согласен. Самый быстрый ;)

> Anatoly Podgoretsky © (13.03.10 17:25) [21]
> > Демо (13.03.2010 16:57:15) [15]Возможность есть, значение
> известно, но количество иттераций или по другому нужное
> на них время настолько большое, что прогресс почти не двигается
> и в этом случае теряется прямое назначение. Но тут помогает
> двигающая полоска

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

Anatoly Podgoretsky (2010-03-13 17:25:00) [22]
> Демо (13.03.2010 16:57:15) [15]

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

Игорь Шевченко (2010-03-13 17:14:00) [23]

> 3. Пользователь запускает длительные расчёты и идёт спать.
> Результаты расчёта понадобятся только на следующий день.
>

Самый правильный вариант

Демо (2010-03-13 17:04:00) [24]

> > 2. Расчёты выполняются в отдельном потоке. Нет необходимости
> > использовать Application.ProcessMessages.За тебя этот
> квант система отдаёт.

Но отдаёт только тогда, когда это действительно необходимо.

> Ega23 © (13.03.10 17:00) [18]
> > Ну это если нет возможности получить точное максимальное
> > значение для ProgressBar.в 95% случаев - нельзя.

Без разницы. В одном случае можно определить, в другом нельзя.
Подход разный.

Ega23 (2010-03-13 17:00:00) [25]

> Ну это если нет возможности получить точное максимальное
> значение для ProgressBar.

в 95% случаев - нельзя.

Ega23 (2010-03-13 16:59:00) [26]

> 2. Расчёты выполняются в отдельном потоке. Нет необходимости
> использовать Application.ProcessMessages.

За тебя этот квант система отдаёт.

Демо (2010-03-13 16:58:00) [27]

> Ega23 © (13.03.10 16:57) [14]
> > Демо © (13.03.10 16:27) [12]> Это уже детали.Фигасе,
> "детали". Сначала мы заявляем, что > Это кажущееся улучшение.
> > Application.ProcessMessages нужно использовать как можно
> реже., а потом оказывается, что это "детали".Слишком смело,
> сударь.

Конечно смело. Потому что в таких простых вопросах вряд ли стоит путаться. Не так ли?

Демо (2010-03-13 16:57:00) [28]

> Anatoly Podgoretsky © (13.03.10 16:42) [13]
> > Демо (13.03.2010 16:27:12) [12]Если расчеты длительные,
> то ProgreessBar не очень пожзодит, лучше что то вращающая,
> возможно совместно с прогресс баром, для общей оченки.

Ну это если нет возможности получить точное максимальное значение для ProgressBar.

Ega23 (2010-03-13 16:57:00) [29]

> Демо © (13.03.10 16:27) [12]
> Это уже детали.

Фигасе, "детали". Сначала мы заявляем, что

> Это кажущееся улучшение.
> Application.ProcessMessages нужноиспользовать как можно реже.

, а потом оказывается, что это "детали".

Слишком смело, сударь.

Anatoly Podgoretsky (2010-03-13 16:42:00) [30]
> Демо (13.03.2010 16:27:12) [12]

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

Демо (2010-03-13 16:27:00) [31]

> KSergey © (12.03.10 17:51) [10]

Application.ProcessMessages нужно использовать как можно реже<> нельзя использовать.

> Ega23 © (12.03.10 17:48) [9]
>На каждом - не имеет. А на каждом сотом или тысячном
> - вполне.

Это уже детали.

> Игорь Шевченко © (12.03.10 17:36) [8]

> А я не вижу смысла менять логику приложения, если можно
> обойтись периодическим опросом пользовательского интерфейса.
> Усложнение - не откровение.

Это и не есть откровение, а лишь предупреждение автору вопроса, чтобы не считал это единственно верным решением.

> dj kondakov (13.03.10 08:39) [11]
> Могу посоветовать использование потоков. Сам одно время
> с такой проблемой мучался, когда было нужно копировать гиговый
> файл с диска на диск. Перенес алгоритм копирования в поток
> и индикацию оттуда же сделал. Итог: файл копируется, ПрогрессБар
> показывает прогресс, приложение не "висит".

Есть разные виды задач. Например:

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

1. Расчёты выполняются в основном потоке. Используем Application.ProcessMessages как можно реже. (например - раз в секунду).
2. Расчёты выполняются в отдельном потоке. Нет необходимости использовать Application.ProcessMessages.
3. Расчёты выполняются в основном потоке. никаких дополнительных действий предпринимать не нужно.

dj kondakov (2010-03-13 08:39:00) [32]
Могу посоветовать использование потоков. Сам одно время с такой проблемой мучался, когда было нужно копировать гиговый файл с диска на диск. Перенес алгоритм копирования в поток и индикацию оттуда же сделал. Итог: файл копируется, ПрогрессБар показывает прогресс, приложение не "висит".

KSergey (2010-03-12 17:51:00) [33]
> Демо © (12.03.10 17:28) [7]
> Если это цикл из десятка миллионов итераций, то переключаться
> на каждом шаге цикла в обработку сообщений просто не имеет смысла.

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

Ega23 (2010-03-12 17:48:00) [34]

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

На каждом - не имеет. А на каждом сотом или тысячном - вполне.

Игорь Шевченко (2010-03-12 17:36:00) [35]
Демо © (12.03.10 17:26) [6]

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

Усложнение - не откровение.

Демо (2010-03-12 17:28:00) [36]
При этом нужно учитывать ещё и алгоритм, во время которого выполняется Application.ProcessMessages.

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

Демо (2010-03-12 17:26:00) [37]

> > Application.ProcessMessages нужно использовать как можно
> > реже.Это смелое утверждение. А почему ?

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

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

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

Игорь Шевченко (2010-03-12 17:13:00) [38]

> Application.ProcessMessages нужно использовать как можно
> реже.

Это смелое утверждение. А почему ?

Демо (2010-03-12 17:01:00) [39]

> timekiller © (12.03.10 11:15) [3]
> Application.ProcessMessages(); здорово помог!

Это кажущееся улучшение.
Application.ProcessMessages нужно использовать как можно реже.

> Алгоритм растет, что будет когда программа будет выполнятся
> 2 часа, допустим?....

Толтько за счёт неаккуратного использования этого метода выполнение алгоритма может замедлиться в несколько раз.

timekiller (2010-03-12 11:15:00) [40]
Application.ProcessMessages(); здорово помог!

Страницы: < 1 2 3 >

Наверх

	« предыдущая ветвь \| форум \| следующая ветвь »