nesco писал(а):
На будущее, событие onExec происходит в другом потоке приложения, и выполнение его цепи событий никак не совпадает с очередью сообщений главного приложения, те отсутствует синхронизация. Вот почему, запущенная цепь событий другого потока не влияет на очередь сообщений приложения, и приложение не тормозит, если других потоков не сотня, конечно. Чтобы синхронизироваться с очередью сообщений приложения и существует событие onSyncExec. И если таймер дополнительного потока выставил итерацию на точке onExec, то на точке onSyncExec событие появится только тогда, когда закончится вся цепь событий точки onExec, управление будет передано системе, и очередь дойдет до обслуживания очереди сообщений приложения. Все это говорит о том, что событие onSyncExec выполняется синхронно с очередью сообщений приложения, тк обрабатывается именно в этой очереди. Кстати, уничтожать поток крайне желательно именно из точки onSyncExec, если установлено выполнение потока только один раз (FastStop=True), тк поток не уничтожится, а просто остановится, занимаяя ресурсы процессорного времени.Применение элемента Thread ничем практически не отличается от применения элемента MMTimer (в первом случае поток создается приложением, во втором случае -- системой), если только не надо что-то обработать в приложении строго по окончанию действия цепи событий таймерной итерации (к примеру, дать команду на перерисовку формы), но это обязательно будет через некоторое время, необходимое на передачу управления обработчику очереди сообщений приложения, и это время может отличаться от итерации к итерации, те никак не обеспечит точности выдачи итерацийОткуда следует, что давать какое-либо событие визуальному контролу с точки onExec крайне нежелательно (также, как и с точки onTimer MMTimer-a), тк эти точки работают из другого потока, а отрисовка происходит в основном. В момент подачи события, приложение может отрисовываться, что приведет к крэшу программы, что мы, кстати, часто и наблюдаем в некоторых схемах