В Caption "(не отвечает), Progress Bar не перерисовывается. Как исправить?

Старое однопоточное приложение, Delphi 7, исходник есть.
В нём Progress Bar, показывающий процент выполнения вывода по USB. Процесс занимает секунд 20-40.
Примерно 50 на 50, примерно посередине времени выполнения процесса, система (Windows 7) замораживает форму, скачком чуть смещает её вправо и вниз на десяток пикселей, в её Caption система добавляет "(не отвечает)", перерисовки Progress Bar естественно нет. Причём программа прекрасно продолжает правильно работать, после завершения функции вывода по USB, форма "размораживается", и программа продолжает дальше работать.

Можно ли исправить такое "поведение" каким-нибудь простым "костылём"? Очень уж не хочется всю эту программу переписывать под потоки.

Видимо с этим уже пытались бороться, - есть Application.Process_Messages в местах смены значения Progress Bar.

0

Методология "херакс-херакс и в продакшн" в действии.

0

Сообщение от Rius Методология "херакс-херакс и в продакшн" в действии.

У меня и такая картинка есть.
[censored]

	Комментарий модератора
	Мат запрещен в любой, даже завуалированной, форме

1

Способ с двойным вызовом цикла обработки сообщений лишь увеличивает время, чтобы перерисовать форму и тп. Гарантии, что подвисать не будет - нет. Тогда 3 раза вызывать?

0

Можно я выскажусь свежим взглядом?

Во-первых, если уж вы пишете в основном потоке некий разумный код, то какого фига, вы вместо того, чтобы использовать .Repaint() пытаетесь использовать .ProcessMessages()? Вы понимаете, что он не просто перерисует вам форму, а пройдёт по всем событиям, а соответственно - нажатия кнопок, события клавиатуры, всё это будет обработано.

Во-вторых, что сложного написать поток и одну процедуру обработки аля procedure ... (var Message: TMessage); message WM_USER + 1? А из потока отправляйте любые данные через PostMessage. Вы получите полностью независимые потоки исполнения, которые никаким образом не затормозят друг друга.

Ну, и в-третьих, а вы подумали о конечных пользователях? У вас-то на машинке это может работать с двумя ProcessMessages, а там может и с пятью не заработать, потому что заср..но офисными игрушками, трижды переставленными офисами и ещё чем только нет ещё

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

Простите, если кого-то обидела, но наболело %) Я с таким вот уже сталкивалась, и мне, как админу, было жутко стыдно объяснять почему плагины отчётов виснут и никак это не поправить...

2

Сообщение от Hiori Можно я выскажусь свежим взглядом?

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

0

Таб + энтер Простите

0

Сообщение от Hiori Таб + энтер

Понятненько

0

1) Через таймер, кинуть его на форму, интервал задать 500 мс. Вкл и выкл вручную. Универсальное решение.
2) Критичные операции чтения надо дробить на циклы, например чтение по 1 Мб, тогда заморозки не будет. После каждого цикла пнуть ПрогрессБар

0

Сообщение от Hiori было жутко стыдно объяснять почему плагины отчётов виснут и никак это не поправить...

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

Сообщение от 119zero Универсальное решение.

Универсальный говнокод это.
Длительные операции, подвешивающие поток UI (выполняющиеся более нескольких миллисекунд), следует выносить в отдельные потоки. Никакие таймеры от этого не спасут, так они они оправляют запрос на выполнение кода в тот же самый поток UI.

0

Сообщение от Rius следует выносить в отдельные потоки.

Угу, потом долго тестить потоки, чтобы не глючили. И все равно глюкнет потом, код надо переписывать.
Таймер не замораживает Винду, это главное и точно не заглючит.

Сообщение от i8085 вывода по USB. Процесс занимает секунд 20-40

Сообщение от i8085 Можно ли исправить такое "поведение" каким-нибудь простым "костылём

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

0

Сообщение от 119zero Угу, потом долго тестить потоки, чтобы не глючили.

Тестировать надо всё. Глюки ProcessMessages() известны более 20 лет, и всё равно этот костыль пихают где не надо.

Сообщение от 119zero И все равно глюкнет потом, код надо переписывать.

Это от малого опыта. Учиться надо.

Сообщение от 119zero Таймер не замораживает Винду, это главное и точно не заглючит.

Вызываемый через него долговыполняющийся код заморозит UI.

0

Сообщение от Rius Тестировать надо всё

Я же цитаты автора привел выше. Специально.
Человеку надо проще, без переписывания кода, простейший костыль требуется. Не надо его толкать к яме, там и погибнет.

0

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

0

Сообщение от Rius Проблемы же предлагаемых вами костылей

Нет там проблем.
За 40 сек скачать дамп человеку надо. Пусть будет 40+1 сек с таймером.
Еще раз цитата. Именно про ПОТОКИ

Сообщение от i8085 Можно ли исправить такое "поведение" каким-нибудь простым "костылём"? Очень уж не хочется всю эту программу переписывать под потоки.

0

Сообщение от 119zero Нет там проблем.

Да канеш, нету! Запись так и так шла успешно, можно было оставить как есть, даже с NOT RESPONDING она бы выполнилась.
Следуя методологии херакс-херакс-и-в-продакшн, можно было "исправить" ещё проще: перед запуском процесса нарисовать на форме текст "Если программа покажется зависшей, просто подождите, всё нормально!"
Никаких потоков и даже таймеров.

1

Rius,
Все равно тема некропост, автор уже забыл что спрашивал.
Лучше частями качать, чтобы не думать и не искать потом ошибки, потом пнуть что нужно и заново цикл, это на 200% надежнее

0

Странные споры. Потоки (нити) - самое правильное, простое и безопасное решение. Программист должен это освоить, ибо там нет никаких адских премудростей. При чём, в отдельном (не главном) потоке можно запускать не только долгую операцию, но и форму с ProgressBar. Главное разнести исполнение так, чтобы многозадачная ОС сама позаботилась о том, чтобы разный код не тормозил друг друга.

0

Сообщение от Sinferno Странные споры. Потоки (нити)

Автор написал, что не надо потоки, почему все не умеют читать?

Сообщение от Sinferno в отдельном (не главном) потоке можно запускать не только долгую операцию, но и форму с ProgressBar

Сообщение от Sinferno Главное разнести исполнение

Сам же указываешь про сложность написания. Тут написать правильно, там подумать... И тестить обязательно.
Проще завернуть в цикл и тестить не надо, по коду видно, где накосячил.
Изначально понятно, что если просто отдать управление Винде, это может не сработать. А 2-3 раза подряд это делать, это уже глупость.
Вот с таймером конечно засада, может не сработать, но это быстро решается. Так что только цикл. Или таймер, выбрать что больше нравится.

0

Сообщение от 119zero Автор написал, что не надо потоки, почему все не умеют читать?

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

0

Сообщение от Rius только запуск отдельного потока или процесса - правильный.

Неа, это выбор решения проблемы. Уже 3 варианта есть.
Недавно запустил игрушку, она начала грузить текстуры, сижу жду. Надпись ждите и все. Надоело, снял задачу и удалил игрушку. Типичное неуважение к юзеру, запустил поток и тишина, прогресса загрузки нет, на клаву нет реакции.
Так что потоки надо контролить, а это уже цикл. Вот как прыгнуть из потока? Никак, пока сам не остановится. Что делать в ситуации, когда вроде прога зависла и комп не реагирует. Сиди и думай, зависло или прогер правильный запустил поток правильно... или неправильно.
Цикл спасет !

0