Зависание функции из модуля.

← →
Profi © (2005-10-24 19:46) [0]

Есть модуль, есть программа, в которую мы его подключаем. В модуле есть функция с циклом. При обработке большого количества данных программа, ясное дело зависает. Если бы цикл был в модуле формы, то не проблема, вставил Application.ProgressMessage в цикл и все. А как тут быть? Знаю, что можно сделать как-то, но не нашел как. Заранее спасибо.

← →
Sergey Masloff (2005-10-24 20:33) [1]

Модуль это UNIT? Тогда Application.ProcessMessages можно использовать спокойно.

Если модуль это внешний бинарник - например DLL то нужно по другому.

← →
Profi © (2005-10-24 22:47) [2]

Sergey Masloff (24.10.05 20:33) [1]
Модуль это UNIT? Тогда Application.ProcessMessages можно использовать спокойно

Да, но это значит, что надо в функцию передовать TApplication, а не хотелось бы!

← →
Игорь Шевченко © (2005-10-24 22:52) [3]

Profi © (24.10.05 22:47) [2]

Application вообще-то глобальная переменная, зачем ее куда-то передавать ?

← →
SamProf © (2005-10-24 23:13) [4]

подключи в том модуле модуль forms и пиши там application.progressmesages;
Вот!

← →
Kolan © (2005-10-25 00:17) [5]

Ну и второй способ - цикл сагнать в поток...

← →
Германн © (2005-10-25 02:16) [6]

Не люблю потоки. Имхо, не видел до сих пор реальной необходимости их пользовать!

← →
Джо © (2005-10-25 02:29) [7]

> [6] Германн © (25.10.05 02:16)
> Не люблю потоки. Имхо, не видел до сих пор реальной необходимости
> их пользовать!

Например, одновременная обработка любых входящих запросов. Или "прослушивание" портов. Много применений, много.

← →
Германн © (2005-10-25 03:03) [8]

2 Джо © (25.10.05 02:29) [7]

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

> [8] Германн © (25.10.05 03:03)
> Но "одновременная обработка любых входящих запросов", имхо
> - невозможна. Всёравно придется их обработать последовательно,
> один за другим.

Имеем ситуацию.
В главном потоке имеется менеджер потоков, ожидающий, пока вызовут некий его метод, принимающий исходные данные для расчетов. Получив входные данные, менеджер запускает отдельный поток, выполняющий некую работу над этими данными. И так поступает с каждой новой приходящей порцией данных. Если не использовать потоки, вариантов 3:
1. Не получаем следующую порцию данных, не обработав предыдущий запрос. Недостатки - висим :(
2. Запускать для каждого задания отдельный процесс. Недостатки: Лишние накладные расходы, сложность синхронизации.
3. Делать свой механизм замораживания, переключение и возобновления работы между заданиями для создания иллюзии одновременной работы. Недостаток: велосипед.

Понятно, что слова "одновременная работа" в отношении потоков это абстракция. Но, абстракция полезная.

2 Джо © (25.10.05 03:22) [9]
Пока что все равно не согласен. Имхо.
Детально завтра, если понадобится. Сейчас иду спать, извини.

> Имхо, не видел до сих пор реальной необходимости их пользовать!

Вот тут у тебя одна из таких ситуаций - выполнение некоторой работы без зависания интерфейса.

> Германн © (25.10.05 02:16) [6]

Например, всегда, когда нужно чего-то дождаться (или что-то сделать) в фоновом режиме.

Например, надо дождаться завершения запущенной внешней программы. Простой вызов WaitForXXX приведет к зависанию интерфейса и ругани юзера, а тот же самый вызов из второго потока - не приведет.

Зависание функции из модуля. Найти похожие ветки