Я имел ввиду регулярную выдачу события onExec с задержкой между итерациями, обеспеченной внутренней командой Sleep().

[size=-2]------ Добавлено в 11:01
Я так подумал, что проще будет нарезать компонент, типа MMTimer, не зависящий от аппликаций, специально для работы в сервисах.

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

Кстати, компонент Sleep на 100% использует процессор, чтобы как можно точнее отмерять промежуток времени. Но вот надо ли такое использовать - вопрос.

tsdima, да не нужна мне такая точность. Мне нужно несколько таймеров с приблизительной точность. Например: первый 10..20 ms, второй 250..500, третий 1..1,5 sec. Так как событие у сервиса одно, то его придется делителями выгонять на самое большое значение, естественно, что по каждому из счетчиков будет торможение на выполение сторонних операций, и в результате на выходе последнего делителя получится не ~1 sec, а ~3..4 sec. И нафиг он мне такой нужен? Не в сервисных приложениях необходимая точность достигается применением нескольких таймеров и они дают, тем больше точность, чем длиннее итерация -- там 1 sec, это почти одна секунда.

В таком случае позволю себе заметить, что это:

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

Сторонние операции можно делать в отдельном потоке (незабывая блокировать повторный пуск)

Может быть, я не исключаю. Но, все же, один единствееный Thread, имеющий задержку в 3 ms, о каком распределении данных может быть речь? Но я сделал собственный компонент по аналогии со схемой, где убрал Sleep, бага (а может и не бага) с высыпанием пропала. Я ни коим разом не утверждал, что это именно бага, просто констатировал обнаруженный факт.

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

Не хочешь - да на здоровье, но не надо "констатировать", и тем более употреблять термины "обнаруженный факт"

Или тебе очень нравится стиль Tad-а: прокукарекал, а там хоть не рассветай

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

[size=-2]------ Добавлено в 13:11
Для тех, кому интересен независимый таймер для сервисов, вот, потестируйте. Полный аналог обычного, но является независимым Особо много таких таймеров применять не следует, тк

-- Удален с выходом исправленного релиза -- Ссылка на новый релиз http://www.hiasm.com/xf//getfile/6923

Ну и как ты собираешься работать с разными потоками не имея возможности синхронизации
Десяти-пальцевым методом

Ты подробнее объяснить можешь? И какие предложения с твоей стороны? И про что вообще разговор, про MMTаймер, чтоли?

Будем считать, что ответ на этот вопрос:
- мы получили

я опять не понял: к точкам элемента ничего не было подключено? Сосбтвенно спор считаю бесполезным поскольку в рабочем цикле элемента Thread никаких баг нет и быть не может по той простой причине, что там всего три строки кода => бага в программе(которую мы не видели кстате).


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

[size=-2]------ Добавлено в 14:22

согласен

Galkov, я всеравно поймаю откуда оно лезет, не сегодня, так завтра. С ММТаймером тоже надо быть осторожным. Я уже нарвался на уничтожение динамических мультиков при работающем ММТаймере, но решилось очень просто -- сначало останавливаем ММТаймер, затем по событию onStop уничтожаем мультики. Создается все в обратном порядке, сначала создаем мультики, затем включаем ММТаймер.

[size=-2]------ Добавлено в 14:31

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

есть такое дело. С обычным таймером тоже самое будет. И с удалением из самого себя.

Пордон, а что, деструктор некого элемента MMTimer остановки не делает

[size=-2]------ Добавлено в 15:43

Увлекательное занятие: заложить гранату, а потом искать от чего она взрывается