[SCrat.ORS]

Есть главная форма, на ней ListBox в котором вручную (onDrawItem) отрисовываются итемы, используя какую-то информацию для заполнения.
Есть функция, назовём её RefreshInform, которая собирает эту информацию, и в конце запускает ListBox.repaint, чтобы onDrawItem нарисовал итемы.
При запуске главной формы, через отдельный юнит, запускается бесконечный поток, суть которого - через каждые 100 мс запускать Synchronize(MainForm.RefreshInform).
И вот тут меня ждала проблема. Через 5-10 минут работы, всё зависает и падает, а отладчик пишет "out of system resources" несколько раз, а затем "Stack overflow" и стек забит WM_PAINT.
Ну логично - забило, только вот почему? Сделал у функции RefreshInform некий глобальный флаг, который в начале устанавливается в False, а по окончанию в True, и, соответсвенно, в потоке перед вызовом RefreshInform стоит проверка этого флага. - Всё-равно падает.
Начал читать гугл, нашёл некую информацию, что repaint - виртуальный метод или что-то типа этого, мол используйте refresh он сделан для совместимости. Ок, сделал, запускаю - не помогло, такая же проблема. Читаю дальше, нахожу, что repaint и refresh делают принудительную перерисовку, а чтобы перерисовка была в порядке очереди, - используйте Invalidate, ок делаем так. Теперь проблема уменьшилась до одного сообщения "out of system resources", но так же всё зависает сначала, потом ошибка и всё падает.
Знаю что проблема именно в потоке из-за запуска функции RefreshInform в которой запускается выполнение перерисовки, - получается эдакая постоянная перерисовка. А если поставить условие, что например если в listbox изменился count, тогда запускать RefreshInform - все работает стабильно. Нужна помощь.
Суть всей этой балды, что бы в ListBox всегда была актуальная информация из-за постоянного обновления в потоке. Использовать банальное ListBox.String[i]:='Бла-бла-бла' - не получится, т.к. ListBox у меня является не более чем "контейнер" для строк, а содержимое строк рисуется из массива, поэтому реальные строки ListBox остаются пустыми, не содержат текста.

[M.A.D.M.A.N.]

Зачем поток? Почему не обычный таймер?

[SCrat.ORS]

Ну там такой фокус, что если количество итемов увеличелось, то выводится сообщение. Всё это нужно чтобы управление главной формой не останавливалось при показе сообщения. Да и таймер как-то слишком скучно, да и лишняя приблуда на форме.
__________________________________________
А вообще, ты прав. Суть ошибки заключается в том, что как-бы оно не было, поток кидает сообщение на перерисовку, а потом уже главная форма смотрит флаги и запускает перерисовку, но очередь сообщений из-за потока продолжает увеличиваться... Поэтому ставь флаги или не ставь, - сообщение от потока в очередь один хрен уходит, и по этому стек заполняется хочешь ты того или нет. И что бы вся эта шляпа заработала, единственный выход - это ставить на главную форму таймер, и посылать сообщения через него, причем в начале процедуры таймера - его выключать, после выполнения - включать, А поскольку сообщения кидает таймер - он зависит от главной формы, и в нём уже те самые флаги можно смотреть сразу, выставлять условие - посылать сообщение на перерисовку или нет... И всё стало работать.

[lmikle]

Посмотри, можно ли переписать так, что бы обновление вызывалось только тогда, когда добавляется новый итем. Кстати, если форма с ListBox нормальная (т.е. созданная в нормальном потоке со ссылкой на Application), то при добавлении итема он сам перерисуется. Только делать это надо правильно. Добавлять итем надо из главного потока (VCL), вызывая соотв. код из вторичных потоков через Synchronize. Если у тебя несколько потоков добавляют итимы, то этот код надо вызывать в критической секции.

[SCrat.ORS]

С добавлением проблем как-раз нету, дело в том, что содержимое итема может меняться "из вне". Поэтому и стоит постоянная перерисовка.

[NumLock]

не нужно постоянно перерисовывать

[lmikle]

Сообщение от SCrat.ORS

С добавлением проблем как-раз нету, дело в том, что содержимое итема может меняться "из вне". Поэтому и стоит постоянная перерисовка.

Ну, значит, перерисовывать только в случае изменения. Более того, еще в отрисовщике проверять - видим ли итем, который надо перерисовать.