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

Методом тыка додумался, как сделать так чтобы программа не вылетала при закрытии - останавливать все потоки событием OnСlose c формы. Я просто подумал, наверное процесс в потоке пытается обратиться к каким-то данным, а так как часть схемы уже закрылась, их нету и он вываливает ошибку. Верный ход мысли? Прога вроде перестала падать при закрытии, но там хитрый глюк, то появляется то нет. Но вроде исчез.

Aziz, вы с самого начала проектирования программы использовали потоки?

CriDos, нет, скорее в процессе добавлял. Главный критерий их использования - когда интерфейс начинал "задумываться" и "тормозить" при загрузке данных из инета в разных частях программы. Или какой-то парсер когда обрабатывал данные. Тогда я запускал тормозящий модуль через поток. Столько потоков развел.. Жуть.) А без них сплошные тормоза.
------------ Дoбавленo в 15.31:
Все-таки одно из преимуществ невизуального традиционного программирования ДЛЯ МЕНЯ в том что, там есть главная часть программы, которая вызывает все подпрограммы. И в ее тело можно внедрить множество меток-обращений к подпрограмме ведения лога. И тогда будет видно, после какой подпрограммы и когда произошел обвал. А в Хиасме я не знаю как это реализовать - последовательность "распараллеливается"..

Aziz, я после долгих страданий в особо крупных проектах с использованием потоков (как основная фишка), нашёл отличную стратегию создания крупных мультипоточных приложений (более 500+ потоков в реалтайм):
1) Построить GUI + логику (ни одного отдельного потока! только основной).
2) Оптимизация+рефакторинг+отладка не обращая внимания на задержки интерфейса.
3) Шаг за шагом распараллеливаем необходимые этапы программы, каждый этап отлаживаем.
Если же проект старый, с кучей потоков и постоянно сыпятся варнинги, берём и убираем все потоки, и начинаем со 2 пункта

С тех пор проблем с потоками у меня не было

CriDos, благодарю за совет, но как быть если глюк появляется только когда потоки работают параллельно? И причем появляется нестабильно, то есть, то нет. Ну запущу я схему без потоков, она будет нормально работать. Верну на место один поток, второй и тд. - все будет нормально работать, пока схеме не вздумается опять глюкнуть.)) Как быть в этих случаях трудноуловимых багов? Но мне кажется гордиев узел разрублен - просто надо все потоки при закрытии программы закрывать принудительно методом doStop. сейчас я вам покажу своего монстра с потоками. Тут и шифрование кода не нужно, сам черт ногу сломит ничего не разберет

------------ Дoбавленo в 16.08:
Это только половина схемы, и много потоков сидят в контейнерах и их не видно.)
------------ Дoбавленo в 16.12:
Когда нужно что-то изменить в схеме - приходится вспоминать для чего тот или иной элемент, отслеживать откуда идет линк и что он делает, потому что запомнить нереально. Хорошо хоть контейнеры подписаны.. Но ничего. Даже прикольно, и чувствуешь себя победителем, нет, даже Воином Кода (кстати, мой второй ник - я сражаюсь с Кодом и с помощью Кода ) когда монстр начинает слушаться команд.))
------------ Дoбавленo в 16.28:
Я понял в чем причина путаницы и как навести порядок. Нужно просто всю логику строить через 2 длинных хаба. Первый - передает событие onCreate формы, второй - OnClose. Чтоб модули запускались строго последовательно. А не как сейчас - результаты работы одной части схемы или модуля - запускают другую часть схемы или модуль, что в сочетании с потоками - наверное ужасный стиль программирования и хаос.

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

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

Aziz, тут нужен системный подход с самого начала зарождения проекта...
Вот часть проекта который создавался почти 3 года назад и без единого сбоя работает до сих пор!
Правда пару раз производил рефакторинг и упрощение с учётом полученных знаний за прошедший период времени.
Вся программа построена на динамических GUI элементах + работа с сетью и всё это отлично "распараллелино".

Согласен.. Просто никогда не знаешь заранее что проект из простенькой утилиты разрастется до софт-студии.. А когда это осознаешь - уже поздно. Поэтому надо приучать себя даже самые простые утилиты писать системно.)

Черт, рано обрадовался. Опять ошибка экспшен при закрытии вылезла. И вроде все потоки останавливаю. Или не все? Надо поискать.. Или может вместо doStop потока использовать его флаг остановки?
Иначе придется в инструкции рассказать об этом баге, выдать его за фичу не выйдет..))