Отображение статуса и ProcessMessage

[tria]

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

[Снег Север]

Запретить закрываться вспомогательным формам (в CloseQuery) до тех пор, как выполнится то, что вам надо.

[MysticCoder]

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

[olegy123]

Если не делать ProcessMessage - программа "виснет".

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

Существует ли какое-либо решение?

задействовать многопоточность (TThread).

[zub]

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

[olegy123]

ты с дуба упал? какая многопоточность?

Зуб, нормальная прога никогда использовать Application.ProcessMessages, чтобы оживить программу, не будет. Длительные вычисления лучше переложить в другой поток.

[Снег Север]

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

[serbod]

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

[Снег Север]

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

[zub]

>>нормальная прога никогда использовать Application.ProcessMessages,
Нормальная прога использует то что уместно для конкретной задачи. В данном случае это ProcessMessages
Многопоточность в данной постановке принесет только геморой, ибо в гуишном потоке ничего не изменится - ты также будешь сидеть и дисаблить кнопочки и прочие свистелки

>>>>нормальная прога никогда использовать Application.ProcessMessages,
Нука расскажи какие будут проблемы если я при висе на 10 сек двадцать раз вызову Application.ProcessMessages?

[wadman]

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

С формой наиболее логичный и простой вариант. Не стоит бояться потоков, они не кусаются.

[tria]

Спасибо всем отозвавшимся.
Добавлю информацию о проекте. Что-то похожее на 1С. Количество окон произвольное - сколько захотел открыть пользователь, столько и открылось.
Часть из них владельцем главное, часть - уже открытые.
Я заранее не знаю, долго ли или быстро будут выполняться операции, мелькать каждый раз модальным окошком с ProgressBar некрасиво.
Ваять отдельный поток при проведении документа - это вообще не туда. Всего лишь нужно, чтобы пользователь дождался выполнения действий и видел прогресс выполнения.

Пока что идея такая - перед началом действий для всех окон сделать enable=false, по окончанию - true. В процессе - ProcessMessage.
Из проблематики:
- при старте нужно для всех окон рекурсивно перебрать компоненты, чтобы получить список всех открытых окон (может быть долго)
- при каком-то неотслеженном сбое вся программа останется залоченной.

[wadman]

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

Как раз "туда". Поток и убрать можно почти без проблем.
Думаю, что моя обертка-компонент над потоком вполне может пригодиться: https://github.com/wadman/wthread

[tria]

Как раз "туда". Поток и убрать можно почти без проблем.

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

[wadman]

Предположить и отловить заранее все возможные глюки - как минимум рисковано.

Ну вот и аргумент за модальное окно на время выполнения задачи.