Не прорисовывается окно

← →
Sphinx © (2004-02-16 20:20) [0]

На время выполнения длительного расчета сделал маленькое окошко, где имеется только Panel, на ней label с надписью:
"Подождите, идет расчет"
и TGaude для отображения выполнения.
BorderStyle формы bsNone, расположена по центру экрана.

Так вот, при выполнении Gaude заполняется как и положено, то есть от 0 до 100%, а вот остальная форма не видна!!! Просто серый квадрат. Если же вывести ее отдельно, а не в процессе расчета, то все нормально.
Помогите кто сталкивался, я в тупике.

← →
jel © (2004-02-16 20:21) [1]

В процедуре расчета периодически вызывать Application.ProcessMessages.

← →
Sphinx © (2004-02-16 20:50) [2]

Помогло, но только так как расчет в цикле, то если в каждом цикле выполнять Application.ProcessMessages то время расчета увеличивается раза в два (по субъективным ощущениям).

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

← →
TUser © (2004-02-16 21:41) [3]

Единовременно - это перед циклом. Но если надо обновлять какой-нибудь прогрессбар, то непрокатит. Надо обновлять, допустим, в каждой 50-й итерации. А время жрут не расчеты, а перерисовка.

← →
XTRudeR (2004-02-16 22:38) [4]

попробуй после решулярно form.repaint или update что нить типа ..

← →
Юрий Зотов © (2004-02-16 22:50) [5]

> Sphinx © (16.02.04 20:50) [2]

> Может как-нибудь единовременно можно прорисовать окно?

Можно. Но что произойдет, если юзер прикроет его другим окном, а потом снова закроет прикрывающее окно?

> То есть в свойствах чего изменить, что бы оно само себя
> прорисовывало?

Все окна и так прорисовывают сами себя. Когда система обнаруживает, что окну (или его части) требуется перерисовка, она посылает этому окну нужные сообщения. Окно принимает их и перерисовывается.

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

Чтобы все было ОК, создайте второй поток (см. TThread) и выполняйте расчет в нем. Тогда два потока будут работать параллельно и Вы получите максимально возможную скорость расчета при нормальной перерисовке.

← →
Defunct © (2004-02-17 00:21) [6]

> Чтобы все было ОК, создайте второй поток (см. TThread) и выполняйте расчет в нем. Тогда два потока будут работать параллельно и Вы получите максимально возможную скорость расчета при нормальной перерисовке.

Сомневаюсь, что на одном процессоре от такого распараллеливания ускорится рассчет.

> Можно сделать, например, чтобы выводилось каждый пятый цикл, но мне кажется это не выход.

... где-то в цикле:
If CyclePos mod Priority = 0 Then Application.ProcessMessages;

Меняя значение Priority - регулируете что Вам важнее, расчет или перерисовка.

← →
Alex Konshin © (2004-02-17 00:34) [7]

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

← →
Defunct © (2004-02-17 00:57) [8]

>Он ускорится потому, что главная нить будет практически все время ждать.

ставим Thread.Prority := tpTimeCritical, так действительно главная нить будет практически все время ждать.
И наблюдаем такой же эффект как и был в самом начале (окна практически не прорисовываются).

IMHO здесь нет надобности в организации отдельного потока. Процессор один, задачи всего две (обслуживание очереди и расчет), можно прекрасно обойтись одним только ProcessMessages.

← →
Defunct © (2004-02-17 01:02) [9]

> будет практически все время ждать

И вообще фраза загадочная, что Вы понимаете по термином ждать, В моем понимании "ЖДАТЬ" значит откладывать исполнение событий в пользу другого процесса.

← →
Alex Konshin © (2004-02-17 01:44) [10]

В моем понимании (думаю, что оно общепринятое) ждать - это ждать событий. Когда thread ждет, то оно не использует процессорное время совсем. В вашем варианте вы бесполезно тратите процессорное время на проверку наличия сообщений в очереди событий. Обратите еще внимание на то, что сообщения приходят редко.
Разница ясна или дальше разжевать?

← →
Defunct © (2004-02-17 02:48) [11]

> В моем понимании (думаю, что оно общепринятое) ждать - это ждать событий.
;)
смею заверить, для многозадачных ОС общепринятым все же считается понятие ждать - откладывать исполнение событий данного процесса(процессов) в пользу другого процесса(процессов). То что Вы трактуете как "ждать" называтся "состояние ожидания процесса".

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

процесс в состоянии ожидании: все ресурсы свободны, но сообщений для процесса нет, работает System Idle.

> Когда thread ждет, то оно не использует процессорное время совсем.
Естественно, когда процесс в состоянии ожидании, работает в основном SystemIdle или другой процесс.

> В вашем варианте вы бесполезно тратите процессорное время на проверку наличия сообщений в очереди событий.

В моем варианте, все процессорное время тратится на вычисления, и при крайней необходимости, дается возможность отработать System Idle, причем успевают обработаться далеко не все события из очереди.

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

> Разница ясна или дальше разжевать?
Думаю разжевывать нечего.

← →
Alex Konshin © (2004-02-17 03:01) [12]

Нет, ждать - это ждать событий. Это уже другой вопрос, когда этому thread будет предоставлена возможность обработать это событие. Конкретно в нашем случае речь идет про MsgWaitForMultipleObjects.

И мы говорим о threads, а не processes, о каком-таком
состоянии ожидания процесса может идти речь.

Извините, но у Вас каша в голове. Вроде и слышали звон, но...

← →
Германн © (2004-02-17 03:33) [13]

Увы, после известного поста ЮЗ в "Потрепаться", Defunct © будет нервно реагировать на все появления ЮЗ.

Имхо, Defunct"у стоит остыть, а всем прочим учесть сей факт.

← →
Германн © (2004-02-17 03:34) [14]

← →
Alex Konshin © (2004-02-17 03:38) [15]

То есть, дать ему возможность смущать неокрепшие умы новичков?

← →
Defunct © (2004-02-17 03:50) [16]

> Это уже другой вопрос, когда этому thread будет предоставлена возможность обработать это событие.
А разве не System Idle отвечает за доставку сообщений и предоставление ресурсов на обработку событий?

> Конкретно в нашем случае речь идет про MsgWaitForMultipleObjects.
Вот об этом как раз речи нет. Сообщения уже в очереди, только System Idle не отрабатывает, т.к. у Application приоритет максимальный. Выполняя цикл без ProcessMessages, SysIdle управления не получает, соответственно ни одно событие не обрабатывается и программа визуально как буд-то "подвисает".

> И мы говорим о threads, а не processes, о каком-таком
состоянии ожидания процесса может идти речь.
Интересно, а чем же Thread так сильно отличается от Process, что даже термины меняют свое значение. Все тот же Prioriry, тот же Suspend, тот же Terminate.

> Извините, но у Вас каша в голове. Вроде и слышали звон, но...
Знакомая фраза, где-то я ее уже видел.
Даю знакомый Вам ответ, нет у меня никакой каши.

← →
Defunct © (2004-02-17 04:01) [17]

> Германн © (17.02.04 03:34) [14]
> Увы, после известного поста ЮЗ в "Потрепаться", Defunct © будет нервно реагировать на все появления ЮЗ
Спросил приватно, да только жаль у Германа анкета пуста.
Что за пост? не читал. Можно здесь, можно по мыло (в анкете), привести ссылку на пост?. А на ЮЗ я не буду нервно реагировать в любом случае.

← →
Unax © (2004-02-17 04:06) [18]

Дело в том что Process никогда не получает процессорное время, а его получает только Thread.

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

Причем тут SysIdle, сообщения выгребает твой поток.

← →
Defunct © (2004-02-17 05:06) [19]

> Дело в том что Process никогда не получает процессорное время, а его получает только Thread.
Гхм, а разве потоки не входят в состав процесса? Завершая процесс убиваются все потоки. Может мы разной волне, конечно.

> Сделай два потока одного приоритета. Пока один занимается расчетами, второй будет спать если в очереди нет сообщений, а если они появятся винда его разбудит. Никаких тормозов не будет, уверяю.

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

Речь только об одном потоке вычислений на одном процессоре (при изменяется ProgressBar или что-то еще), разве недостаточно изредка (например, при выполнении ProgressBar.StepBy()) вызывать Application.ProcessMessages. Разве нет?

> Причем тут SysIdle, сообщения выгребает твой поток.А кто дает возможность моему потоку выгрести сообщения?

← →
Suntechnic © (2004-02-17 05:51) [20]

>Defunct ©

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

Гхм, а разве потоки не входят в состав процесса? Завершая процесс убиваются все потоки.

Только если убить процесс через TerminateProcess. Во всех остальных случаях как раз таки процесс умирает тогда, когда умирает последний поток.

Речь только об одном потоке вычислений на одном процессоре (при изменяется ProgressBar или что-то еще), разве недостаточно изредка (например, при выполнении ProgressBar.StepBy()) вызывать Application.ProcessMessages. Разве нет?

Достаточно, только смотря для чего... Вам об этом твердят с начала данной ветки. У любого процесса есть т.н. основной поток. Основной поток, это, как правило, поток GUI. Поток GUI, как правило, дополнительными вычислениями никто не перегружает потому как его основное предназначение это взаимодействие с пользователем и отображение результатов, а если он будет вместо того, чтобы взаимодействовать с полозователем ещё чего то там считать, то мы либо получим "зависание" GUI, либо увеличение времени расчётов. Вот для того чтобы это избежать и создают доп. потоки.

А кто дает возможность моему потоку выгрести сообщения?

Уж никак не System Idle.

← →
Unax © (2004-02-17 05:52) [21]

>Гхм, а разве потоки не входят в состав процесса?

Потоки входят в состав процесса и именно они получают процессорное время и выполняют код, но никак не сам процесс!!!

>Речь только об одном потоке вычислений на одном процессоре (при изменяется ProgressBar или что-то еще), разве недостаточно изредка (например, при выполнении ProgressBar.StepBy()) вызывать Application.ProcessMessages. Разве нет?

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

Отзывчивость пользовательского интерфейса важнее вычислений.

>>А кто дает возможность моему потоку выгрести сообщения?
Винда дает, ты сам даже сказал "моему потоку". Процессорное время выделяет Windows, и SysIdle тут непричём!

← →
Defunct © (2004-02-17 08:21) [22]

Unax © (17.02.04 05:52) [21]
Suntechnic © (17.02.04 05:51) [20]

Спасибо
Все что вы говорите правильно, за исключением некоторых спорных моментов:
> Потоки входят в состав процесса и именно они получают процессорное время и выполняют код, но никак не сам процесс!!!
Это напоминает такое утверждение: Колеса входят в состав Автомобиля, но едут только колеса, сам автомобиль стоит!!!
Где логика?

> Винда дает, ты сам даже сказал "моему потоку". Процессорное время выделяет Windows, и SysIdle тут непричём!
Мне раньше казалось, чем больше времени занимает Idle тем быстрее реакция на то или иное событие. Не задавались вопросом что же такое SystemIdle и почему он ~20kb.

>>Речь только об одном потоке вычислений на одном процессоре (при изменяется ProgressBar или что-то еще), разве недостаточно изредка (например, при выполнении ProgressBar.StepBy()) вызывать Application.ProcessMessages. Разве нет?
> Достаточно, только смотря для чего...
Для перерисовки собственных окон приложения.

Все-таки, призываю просто логически подумать:
есть задача1 вычисление чего-либо,
и задача2 перерисовка интерфейса. Глобальная задача - переключение между задачей1 и задачей2. А теперь скажите какая разница и как это повлияет на скорость:

вариант1: задача1 обладает всеми ресурсами и периодически сообщает системе о перерыве. (Application.ProcessMessages)
вариант2: система переключает их на свое усмотрение. (Threads)

Ну и где ускорение? Процессор-то один.

← →
Alex Konshin © (2004-02-17 08:33) [23]

Да ты, холоп, все не уймешься! (c) "Иван васильевич меняет профессию".

периодически сообщает системе о перерыве
Вот на это периодически у тебя время-то и уходит, причем впустую и бесполезно, так как сообщения приходят редко.

← →
Defunct © (2004-02-17 08:42) [24]

Alex Konshin © (17.02.04 08:33) [23]
>>периодически сообщает системе о перерыве
>Вот на это периодически у тебя время-то и уходит, причем впустую и бесполезно, так как сообщения приходят редко.

Эээ, брат да ты не прав (C) АО МММ Леня Голубков.
>> разве недостаточно изредка ( например, при выполнении ProgressBar.StepBy()) вызывать Application.ProcessMessages. Разве нет?
Цикл вычислений рано или поздно закончится, а вызываем ровно стока раз сколько надо.
А вот "на усмотрение" системы, зависит от системы.

← →
Alex Konshin © (2004-02-17 08:56) [25]

Вот именно так ты и получишь тормоза на отрисовке.
Потому как помимо прогресс бара нужно еще отвечать на мышинные сообщения и на сообщения формы (например, при перемещении или изменении размеров). Как ты понимаешь, предсказать момент, когда они придут, ты не можешь, а не обработаешь вовремя - будут видны тормоза. Т.е. нужно проверять чаще, и опять-таки обычно бестолку.

Ну теперь понятно? Или и дальше будешь упорствовать?

← →
KSergey © (2004-02-17 09:06) [26]

Автору:
1.читаем форум перед задаванием вопроса - много интересного узнать можно.
2.Конкретно по этому вопросу буквально вчера-позавчера было по крайней мере 2 обсуждения

http://delphimaster.net/view/1-1076671800/
http://delphimaster.net/view/1-1076671800/

← →
Юрий Зотов © (2004-02-17 09:08) [27]

> Defunct © (17.02.04 08:21) [22]

Сорри, но у Вас в голове действительно каша. То есть, неточные и обрывочные знания, неполноту которых Вы пытаетесь восполнить логическими умопостроениями, не всегда верными.

Понимаете, Windows работает так, как ее сделали, а не так, как Вы себе это представляете. И незачем выдумывать доморощенные теории о ее работе, если существуют документация и книги. Пресловутый Рихтер, например. Очень рекомендую.

И еще - подумайте, а что же все таки означает фраза, к которой Вы прицепились: "максимально возможная скорость расчета при нормальной перерисовке". Означает ли она то же самое, что "максимальная скорость расчета", или нет?

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

А ведь именно этот вариант и есть РЕАЛЬНЫЙ. И для расчета он заметно быстрее, чем использование ProcessMessages - потому что нет никаких лишних вызовов и никаких лишних проверок очереди. Вот почему было сказано: "максимально возможная скорость расчета при нормальной перерисовке".

Читайте все же Рихтера.

← →
Sphinx © (2004-02-17 09:13) [28]

> Чтобы все было ОК, создайте второй поток (см. TThread) и
> выполняйте расчет в нем.

Каюсь, даже не подумал об этом :(

Огромное всем спасибо, попробую поэксперементировать с нитями (TThread), может чего и получится.

Alex Konshin © (17.02.04 08:56) [25]
Пойми, я не противник Thread, просто для всего одной задачи он IMHO будет лишним. Опрадывает ли цель средства? Описывая свой Thread прийдется довольно сильно изменить уже работающую программу.

Я понимаю, организовать 2 или более потоков вычислений без исп. TThread не всем под силу, ну и когда есть хотя бы 2 процессора, ОС распределяет кого куда. Но один поток, можно обойтись без Thread и сделать так чтоб не тормозила прорисовка.

Или и дальше будем доказывать насколько хорошо исп. отдельный поток?

Не, я вижу, что тут случай тяжелый и надо сразу в морг.

> Defunct © (17.02.04 09:20) [29]

> Но один поток, можно обойтись без Thread и сделать так чтоб не
> тормозила прорисовка.

Что ж, сделайте это раз Вы так считаете. И прямо здесь же приведите код. Который производил бы достаточно длинные вычисления (ну, скажем, секунд на 5-10), одновременно перерисовывая при этом окно. И все это в одном потоке, и все это без задержек. Вот тогда и поговорим.

> Defunct © (17.02.04 09:20) [29]

> разве потоки не входят в состав процесса?

нет, не "входят"

они, кодовые потоки, работают в контексте процесса, ибо сами по себе, т.е. без существования процесса как объекта ОС кодовые потоки (опять же как объекты ОС) быть созданными системой и существовать не могут.

> Или и дальше будем доказывать насколько хорошо исп. отдельный
> поток?

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

впрочем, если тебе так уж приспичило реализовать всю свою логику "в одном флаконе" (т.е. в одном-единственном основном кодовом потоке), то никто не заставляет тебя пользовать именно Application.ProcessMessage для обработки событий изменения граф.интерфейса и событий ввода/вывода ... ты можешь самостоятельно реализовать упрощенный цикл выборки, который будет фильтровать только нужные сообщения, диспетчеризуя их по необходимости

Юрий Зотов © (17.02.04 09:08) [27]
И еще - подумайте, а что же все таки означает фраза, к которой Вы прицепились: "максимально возможная скорость расчета при нормальной перерисовке". Означает ли она то же самое, что "максимальная скорость расчета", или нет?

Вообще-то я "прицепился" не к приведенной фразе, а к этой:
Юрий Зотов © (16.02.04 22:50) [5]
> Чтобы все было ОК, создайте второй поток (см. TThread) и выполняйте расчет в нем. Тогда два потока будут работать параллельно и Вы получите максимально возможную скорость расчета при нормальной перерисовке.

"Параллельно" на одном процессоре работает только блок MMX/SSE и.т.п., больше ни о каком "параллельно", особенно двух (потоков/процессов от названия смысл не меняется) на однопроцессорных системах мечтать не приходится.

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

Неужели этот вариант не покрывается вариантом2:
>> вариант2: система переключает их на свое усмотрение. (Threads)

И опять же повторюсь:
Опрадывает ли цель средства? Описывая свой Thread прийдется довольно сильно изменить уже работающую программу.

> Читайте все же Рихтера.
Спасибо, читаю

> можно обойтись без Thread и сделать так чтоб не тормозила
> прорисовка

И как это выглядит, если знаешь приведи код :)

Нитям вообще по моему по барабану сколько процессоров на борту у компьютера. Не скажу что это точно, но на сколько я помню лекции по "Вычислительным системам" ОС выполняет процессы по очереди, в соответствии с их приоритетом (то есть некоторые высокоприоритетные процессы могут выполяться чаще чем другие). В остальное время она на процессоре крутит свое ядро.
То есть если я создам отдельную Нить на расчет она будет выполняться в теле моей процедуры, параллельно с отрисовкой окна, а не ожидая пока оно нарисуется.
Тем более, что расчет хоть и циклический, но процессор он занимает не более чем на 60% (до диспетчеру задач; при использовании Application.ProcessMessages - 100% из них 40%-время ядра), вывод: у меня остается 40% процессорного ресурса на отрисовку окна.

И еще цитирую тот же диспетчер задач:
Процессов: 37
Потоков: 430 (они же Нити, они же Thread)
один процессор.
Зачем тогда МС придумала технологию Нитей, если не для увеличения производительности???

Вот мой код:
Stoping:=False; repeat z3:=(x-bb1*z2-bb2*z1-bb3*z)/bb0; z2:=z2+z3*dt; z1:=z1+z2*dt; z:=z+z1*dt; y:=aa0*z2+aa1*z1+aa2*z; ChartingForm.chXY.SeriesList[0].AddXY(Ti,y); Ti:=Ti+dt; Progrr:=Round((Ti-TBegin)*100/(TEnd-TBegin)); ProgressForm.Gauge1.Progress:=Progrr; Application.ProcessMessages; if (Ti-dt)>Tend then Stoping:=True; until Stoping;

С Нитями пока не делел, но поробую вечером (сейчас по местному 12.00)
Прошу Defunct © (17.02.04 09:20) [29] попробуйте сделать вычисления и отрисовку одновременно с приемлемой скоростью. :)

P.S. Переменные Tend=75, dt=0.0001 для моего примера так что сами считайте сколько это занимает по времени. На моем Цел600 примерно 1.5 секунды без Application.ProcessMessages и секунды 4 с ним.

Если не ошибаюсь, где то читал, то два процессора (CPU), не всегда означает, что выполнение двух разных потоков будет происходить на двух разных процессорах. ИМХО это зависит от ОС. Если не хватает мощностей одному, то тогда подключается второй CPU.

repeat

z3:=(x-bb1*z2-bb2*z1-bb3*z)/bb0;
z2:=z2+z3*dt;
z1:=z1+z2*dt;
z:=z+z1*dt;

y:=aa0*z2+aa1*z1+aa2*z;
ChartingForm.chXY.SeriesList[0].AddXY(Ti,y);

Ti:=Ti+dt;
If Frac(Ti)<dt Then // может быть dt*10 (не знаю чему равен Ti изначально
begin
Progrr:=Round((Ti-TBegin)*100/(TEnd-TBegin));
ProgressForm.Gauge1.Progress:=Progrr;
For TempIdx:=1 To 5 Do Application.ProcessMessages;
End;
if (Ti-dt)>Tend then Stoping:=True;

until Stoping;

В любом случае сократится на три порядка число вызовов App.ProcessMessages.

Вот кстати для большей наглядности, сравнил работу Thread и App.ProcessMessages, запускай проверяйте, по скорости работает одинаково.

TMyThread = class(TThread) private { Private declarations } protected Public ProgressBar : TProgressBar; procedure Execute; override; end; TForm1 = class(TForm) ProgressBar1: TProgressBar; ProgressBar2: TProgressBar; Button1: TButton; Button2: TButton; procedure Button1Click(Sender: TObject); procedure Button2Click(Sender: TObject); private { Private declarations } public { Public declarations } end; //... //FormCreate: // ProgressBar1/2.Max := 10000; // Расчет без Thread (~20 sec) procedure TForm1.Button1Click(Sender: TObject); Var I,J,K:Integer; R1,R2:Real; begin For J:=1 To 10000 Do Begin For I:=1 To 10000 Do Begin R1:= 98*Cos(R2); R2:= Sin(R1)*R1; End; ProgressBar1.StepBy(1); For K:=1 To 5 Do Application.ProcessMessages; End; ShowMessage("Done"); end; // Расчет со Thread (~20 sec) procedure TForm1.Button2Click(Sender: TObject); Var T : TMyThread; begin T := TMyThread.Create( False ); T.ProgressBar := ProgressBar2; T.Execute; end; procedure TMyThread.Execute; Var I,J:Integer; R1,R2:Real; begin For J:=1 To 10000 Do Begin For I:=1 To 10000 Do Begin R1:= 98*Cos(R2); R2:= Sin(R1)*R1; End; ProgressBar.StepBy(1); End; ShowMessage("Done"); end;

> For TempIdx:=1 To 5 Do Application.ProcessMessages;

Это опечатка или шутка?

Что это просто ошибка - не верю. Потому что человек, рассуждающий о потоках, процессах, квантах, приоритетах и пр. ТАК ошибаться не может.

Не прорисовывается окно Найти похожие ветки