Доброго времени суток, уважаемые:
от слов к коду.
есть поток:


В обработчике таймера:


Периодически (пользуюсь MadExcept) "наружу" вылезает исключение EArgumentOutOfRangeException, т.е. на экране появляется окошко MadExcept-ов с кнопочками "продолжить, перезапустить..."

Вопрос:
почему оно, это окошко, вылезает? Ведь обработка WM_TIMER обернута в try-except, соответственно - исключение должно записаться в лог и уйти на следующий виток while.
Чего я не понимаю и что делаю не так?

Вылезает всегда или только во время работы из-под IDE?

Вылезает не всегда (имеется ввиду - не на каждом вызове события таймера), но при работе из-под IDE, как ни старался, отловить не удалось.
P.S. Используется стандартный TTimer.
Причину возникновения EArgumentOutOfRangeException я уже отловил и устранил, но - с чего оно вылезло за except-блок?

UPD. Нашел, в чем дело. Исходный код оконной процедуры Ttimer:


Это сообщение отредактировал(а) kami - 14.10.2013, 12:40

По твоему коду непонятно, где именно.
Если окно с сообщением об исключении вываливается при работе аппликации из-под IDE (отладчика), то это нормально.

Если вываливается сообщение самого IDE (там, где есть чекбокс "игнорировать в будущем") - да, это нормально. Но оно останавливает работу потока в "боевом" режиме, не из-под IDE.



Я привел не полный код? Вроде, весь, относящийся к делу (пост №1):
в потоке создана очередь сообщений, которые вылавливаются в цикле. Каждая итерация цикла заключена в try-except. 
Приходит сообщение WM_TIMER, оно через DispatchMessage и оконную процедуру таймера попадает в обработчик OnTimer, там возбуждается исключение, но оно не "гасится" в except-блоке цикла обработки сообщений, хотя - должно.

В принципе, причина выяснена - оконная процедура TTimer самостоятельно вызывает Application.HandleException (кто б ее об этом еще просил).
Осталось выяснить - как с этим бороться. Единственное, что приходит в голову - каждый обработчик OnTimer нужно заключать в try-except, что мне совсем не улыбается.

Кстати, в этом случае получается, что я не могу передать возбужденное в OnTimer исключение "вверх" на уровень... Плохо...

Upd.
Либо - хватать Application.OnException и там... - re-raise что ли, но это вообще не нескафе...

Это сообщение отредактировал(а) kami - 14.10.2013, 20:26

  Делфя старается перехватывать все исключения в главном потоке. TTimer это компонент. Как известно, в делфях предполагается, что компоненты работают в главном потоке. В данном случае проще свой класс таймера написать. Тем более что там 3.5 строчки кода.

Этот ответ добавлен с нового Винграда - http://vingrad.com

Создай поток с событием, в котором будет срабатывать процедура через определённые интервалы времени.

Если что, у меня есть готовый пример.

Это понятно. Однако, исключение и так будет перехвачено в Application.Run, в цикле обработки сообщений (да, в предыдущих сообщениях неправильно написал - ProcessMessages, по крайней мере в D2010, не ограждено try-except). На кой нужен прямой вызов HandleException из оконной процедуры таймера - так и не понял.
В общем и целом - вопрос решен:




Было бы неплохо, т.к. не понимаю, как это - 

где-нибудь в приложении, например,  в главной форме 



если нужно вызвать thread.execute принудительно, не дожидаясь, пока таймер сработает, можно вызвать в любой момент:

https://www.google.com/search?q=thread+Wait...tbs=lr:lang_1ru

Понятно. Мне больше бы подошло RegisterWaitForSingleObject, с которым так и недопереразобрался. Тормозить очередь сообщений на WaitFor - не комильфо.
Спасибо.

не понял

Добавлено через 23 секунды
А я думал, что это самый правильный подход.

Добавлено через 1 минуту и 13 секунд
вот ещё посмотри http://www.sql.ru/forum/1050286/shablon-kl...-wthread-thread

Если (как, допустим, в примере) ставить в WaitFor dwMilliseconds = 1000, то получается, что ни одно окно (из числа созданных в этом потоке) целую секунду не сможет получить ни одного сообщения.

так тебе говорят про отдельный поток, в котором нет гуя

При чем здесь гуй?
У меня в сабжевом потоке крутятся:
- окно таймера
- окно, к которому привязан IWebBrowser (да и сам IWB кучу всего похоже создает)
- окно обслуживания синхронизации данных между потоками (что-то типа коллбаков хуков в Винде).
И ничего из этого не является GUI. Но всем этим окнам нужно обрабатывать сообщения (особенно - второму и третьему).

Добавлено через 1 минуту и 50 секунд

Только сейчас дошло: спасибо было сказано безо всякого подтекста - действительно за напоминание такой возможности.

ну понятно, но речь идет об отдельном потоке-таймере. если не хочешь - RegisterWaitForSingleObject
в чем проблема я не пойму?

ну для ком-тредов есть CoWaitForMultipleHandles

Изначально речь шла о не-джентльменском поведении стандартного TTimer в потоке  
А потом уже Akella привел код потока-таймера. Я же (наверное, некорректно) написал, что такой подход не совсем вписывается в задачу моего потока.



Да проблемы-то уже и нет, она решена


Просто было интересен код, который предложил Akella 
Вот беседа немножко и подзатянулась.

Обычно в потоке выполняют работу безо всяких окон.
Это отдельный поток.
У меня в отдельном потоке таким образом выполняется процедура экспорта в XML и отправка данных на хостинг.
В другом приложении программа в отдельном потоке раз в минуту выполняет (образно говоря) idHttp.Get(...), при этом, пользователь спокойно работает с программой, даже не замечая, что выполняется что-то в отдельном потоке раз в минуту.

или я тебя не понял?

Да вроде всё правильно.
Тем не более, я не согласен с утверждением  У меня редко когда получается без них обойтись.
Под "окнами в потоках" я понимаю всё созданное через AllocateHWND и/или CreateWindow[Ex]...

у меня чаще получается чем не получается, но у тебя же webbrowser control живёт в этом треде, а com-объекты требуют обработки сообщений в своём apartment-треде, тут ничего не сделаешь. смотри в сторону CoWaitForMultipleHandles или обрабатывай WM_TIMER руками